Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-04-01T03:13:18Z

Mjain2: /* Implementation */

== Background ==
There are three different review strategies in Expertiza.
#Auto Selected
#Student Selected
#Instructor Selected
In auto-selected reviewing, a reviewer picks the topic to review on, but not the individual submission.
Student-selected allows the reviewer to pick from a list of submissions, not topics.
Instructor-selected is where the instructor/TA assigns submissions to reviewers.
In the case of auto-selected and student-selected reviewing, the student is not allowed to pick from any topic or submission, but only to choose among those that have received the fewest reviews so far. But this strategy may be modified by selecting a non-zero threshold k as follows.
A topic is review able if the minimum number of reviews already done for the submissions on that topic is within k of the minimum number of reviews done on the least-reviewed submission on any topic.
==Motivation==
The goal of Expertiza is to support student-generated content through peer review and teamwork. It is a peer-review system that allows students to select a topic to work on, then submit their work and review their peers' submissions. As mentioned above there are different strategies available for reviewing other student;s work. However these strategies do not work as expected. It allowed students to choose many topics without submitting them. In some cases this causes exceeding the maximum limit for the assignment. Also allowing only the topic/submission with the minimum reviews to be allowed for review, did not allow users to select a topic which has a little more reviews than the minimum but has not crossed the maximum threshold. Certain changes in the algorithm for making a topic/submission allowable for review can help us overcome these problem.

==Design==
There were few faulty designs in the project which we have improvised.
#The the view - _set_self_review was related to student review technique. However its name was confusing and misleading. We have refactored and replaced it with _set_student_review.
#Ability to set maximum threshold for review for an assignment should be available for Auto Review and Student Review and not for Instructor Review. The existing design was faulty and we have made the required change so that this field is available only for student review and auto review. Appropriate changes are done in the jQuery method to implement this design change.
#If no submission was available, still the topic was made available to the user and on selection of the topic, he was provided the message that no submission is available to review. The user then had to go back and select some other topic if available. This process was time consuming. We have replaced this design using Javascript and make it work faster. If the topic had no submissions for review, the topic was not presented to the user.
#If the assignment was such that it had no topics, the user was directed to a page with a single button which further directed him to the page which listed available submissions for review. Although there is nothing wrong in this approach, the intermediate page was redundant and not performing any task. Thus we have replaced this design and the the intermediate page is bypassed.
#The existing design had no restriction on the number of reviews the student is allowed to begin without submitting. This design had a lot of problem. One problem was as mentioned before it would evade the maximum number of reviews. Another problem it caused was some students were unable to perform reviews as others performed too many reviews. We have devise an improved strategy which overcomes these drawbacks.

==Implementation==

===Objective 1===
Update code in for Student Selected Reviewing to cycle through submissions and not topics.

>

===Objective 2===
Make the ‘threshold box’ on the Edit /Create assignment - Review Strategy tab to appear only when Auto-selected or Student-selected reviewing is chosen and not when Instructor-selected is chosen.

> The Maximum Threshold Box was getting shown using JQuery. However the logic used to display was not proper. We modified the code in the jQuery so that the required implementation ie to show the box for Auto Selected and Student Selected and not for Instructor Selected
//code

===Objective 3===
Allowing a student to choose any number of reviews to do, without submitting any of them, allows a student to work on multiple reviews at the same time, but it also allows students to evade the limit on number of reviews that can be done. Devise a strategy to introduce certain threshold so that the student does not evades this limit.

> We implemented the following strategy in out implementation. Introduction of a fixed threshold value - '3' which limits the number of reviews the user can begin without submitting previously selected reviews. Although this value can be made dynamic depending on the instructor or the assignment, we chose to have it static because it is not dependent on any assignment and would be a good practice for restricting the user at a static value for every assignment.
We have introduced this condition in the controller action - //on page - //. This will help in limiting the evasion of maximum threshold.
//code
Also we have introduced code to reject users own submission and and submissions already reviewed by user at proper place so that user has right choice of submission to review at every time.
//code

===Objective 4===
If there are no topics, Auto-selected reviewing should still work, but it should select one of the submissions that has the fewest reviews so far. Perform Testing for this.

> Successfully tested with threshold zero and it works as expected.

===Objective 5===
If the reviewer selects his own submission for review, he is not allowed to perform the review and presented with message saying “ There are no more submissions to review on that topic.” Instead it would be better not to allow him to select his own submission for review. Also, if the user has reviewed the submission/topic with the least reviews, he should be allowed to perform review on other topics which have not reached their maximum threshold.
===Objective 6===
Provide a comprehensive suite of tests so that we can be sure that all review strategies are working.

==Issues==
===Initial Setup===
There were many issues faced in the process of fixing the review strategies. The issues are as follos:
*Unsuccessful bundler install
We faced the issue of raspell.c, which is the dictionary for auto-completing the English words. This was resolved by commenting out the following gems from the gem file
gem 'automated_metareview', github: 'expertiza/automated_metareview'
gem 'raspell'
*Databases for Expertiza project
We initially had to set up several databases like student, instructor, assignments, review rubrics. This was resolved with the help of 'expertiza_scrubbed' versions provided by the instructor and TA.
*Troubleshooting the Expertiza project.
We had troubles to run the database dump. Constantly rake db:migrate was failing, tree display was not working and we were always prompted with "No_method" error. This was again resolved by completely replacing the existing database-dump
===Core tasks===
*Permission setting for review strategy
Fistly, we tried to understand the working of the present code. We created a new assignment with 5 topics. We logged in as a student to select the topics, but we were prompted with the 'Permission Denied to sign_up_sheet#add_signup_topics'. This was resolved by changing the ation_allowed method of sign_up_sheet_controller
*Missing partials
There were some of the partials missing in the given project code like the submitted_content/_self_review.html.
*Missing table attributes
There were missing some table attributes in the given database which resulted in "No_Method" error.We had to create a few attributes like created_at and updated_at in the ResponseMap table.
*Tweaking the code
There were some of the non-existing/irrelevant attributes accessed to perform the required action. These minor issues were resolved by tweaking the code and accessing the right attributes. The corresponding action were tested for correctness.
*Incomplete views
The student_review/_response.html view had incomplete condition code. We fixed the code manually by understanding and testing the code flow.
*Duplicate methods
There were present multiple definitions for the same function (e.g., new,edit) in response controller. We had to discard the method that was not referenced.

==Testing==
Testing was done with the Unit tests. Test cases were written for the corresponding models. The following commands were performed before writing the test cases: 
rake db:test:clone 
rake db:test:clone_structure 
rake db:test:load 
rake db:test:prepare 
rake db:test:purge 
Generally one can write test cases to check the following:
*Web request successful
*User redirected to the right page
*Successfully authenticated the user/object
*Correct object stored in response
*Appropriate message displayed for the user. 
The following test cases were written for the review_strategies:
;test_candidate_topics_to_review
:A test case was written to test if candidate_topics_to_review returns nil if there are no topics to the assignment submission.
;test_signup_topics
:A test case was written to test if the existing signup_topic method in the expertiza code. The functionality of signup_topic method was tested: 
:signup_topics return non-empty set of values if it has topics for the assignment.
:signup_topics returns a empty set of values if it has no topics for the assignment. 

;tests for candidate_topics_to_review
:We re-factored the candiate_topics_to_review method in the assignment.rb model. contributor set is build according to a set of conditions. The modified candiate_topics_to_review is more modular and clean. 
Test cases are written for each of the method that describes each condition.

==ScreenShots/ScreenCapture==
==Future Work==
* Fix control flow of student-selected reviewing similar/through auto-selected reviewing. Currently, student-selected reviewing calls review_assignment() method in DynamicReviewAssignmentHelper which filters topics/submissions similar to auto-selected but not as efficiently. As per Professor's comments, student-selected reviewing process is the same as auto-selected except steps 3 and 5 are not needed, and in step 2, the check is only for whether they have submitted. Steps are as follows:
** A contributor set is initialized with all of the teams participating in the assignment.
** Contributors are removed if they have not selected a topic or not submitted.
** Contributors are removed if their topic is not reviewable at the current time.
** Contributors are removed if they have “too many” reviews (as determined by the review threshold).
** Then we cycle through the remaining contributors, adding their topics to candidate_topics set.
* Logic to filter candidates is repeated in candidate_topics_to_review() and contributor_to_review() methods. We could skip filtering in the contributor_to_review() method.
* For student-selected assignments with no topics, a single button is displayed to proceed to submission-selection page. We have currently implemented it using JavaScript to call the click() function of this button. This could be implemented in a better way by calling the next controller action if no topics are present.
* The view views/student_review/_response.html.erb contains a lot of procedural code. This should ideally be moved from view to controller.

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-04-01T00:31:08Z

Mjain2:

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-04-01T00:30:39Z

Mjain2:

== Background ==
There are three different review strategies in Expertiza.
#Auto Selected
#Student Selected
#Instructor Selected
 In auto-selected reviewing, a reviewer picks the topic to review on, but not the individual submission.
Student-selected allows the reviewer to pick from a list of submissions, not topics.
Instructor-selected is where the instructor/TA assigns submissions to reviewers.
In the case of auto-selected and student-selected reviewing, the student is not allowed to pick from any topic or submission, but only to choose among those that have received the fewest reviews so far. But this strategy may be modified by selecting a non-zero threshold k as follows.
A topic is review able if the minimum number of reviews already done for the submissions on that topic is within k of the minimum number of reviews done on the least-reviewed submission on any topic.
==Motivation==
The goal of Expertiza is to support student-generated content through peer review and teamwork. It is a peer-review system that allows students to select a topic to work on, then submit their work and review their peers' submissions. As mentioned above there are different strategies available for reviewing other student;s work. However these strategies do not work as expected. It allowed students to choose many topics without submitting them. In some cases this causes exceeding the maximum limit for the assignment. Also allowing only the topic/submission with the minimum reviews to be allowed for review, did not allow users to select a topic which has a little more reviews than the minimum but has not crossed the maximum threshold. Certain changes in the algorithm for making a topic/submission allowable for review can help us overcome these problem.

==Design==
There were few faulty designs in the project which we have improvised.
#The the view - _set_self_review was related to student review technique. However its name was confusing and misleading. We have refactored and replaced it with _set_student_review.
#Ability to set maximum threshold for review for an assignment should be available for Auto Review and Student Review and not for Instructor Review. The existing design was faulty and we have made the required change so that this field is available only for student review and auto review. Appropriate changes are done in the jQuery method to implement this design change.
#If no submission was available, still the topic was made available to the user and on selection of the topic, he was provided the message that no submission is available to review. The user then had to go back and select some other topic if available. This process was time consuming. We have replaced this design using Javascript and make it work faster. If the topic had no submissions for review, the topic was not presented to the user.
#If the assignment was such that it had no topics, the user was directed to a page with a single button which further directed him to the page which listed available submissions for review. Although there is nothing wrong in this approach, the intermediate page was redundant and not performing any task. Thus we have replaced this design and the the intermediate page is bypassed.
#The existing design had no restriction on the number of reviews the student is allowed to begin without submitting. This design had a lot of problem. One problem was as mentioned before it would evade the maximum number of reviews. Another problem it caused was some students were unable to perform reviews as others performed too many reviews. We have devise an improved strategy which overcomes these drawbacks.

==Implementation==

===Objective 1===
Update code in for Student Selected Reviewing to cycle through submissions and not topics.
===Objective 2===
Make the ‘threshold box’ on the Edit /Create assignment - Review Strategy tab to appear only when Auto-selected or Student-selected reviewing is chosen and not when Instructor-selected is chosen.
===Objective 3===
Allowing a student to choose any number of reviews to do, without submitting any of them, allows a student to work on multiple reviews at the same time, but it also allows students to evade the limit on number of reviews that can be done. Devise a strategy to introduce certain threshold so that the student does not evades this limit.
===Objective 4===
If there are no topics, Auto-selected reviewing should still work, but it should select one of the submissions that has the fewest reviews so far. Perform Testing for this.
===Objective 5===
If the reviewer selects his own submission for review, he is not allowed to perform the review and presented with message saying “ There are no more submissions to review on that topic.” Instead it would be better not to allow him to select his own submission for review. Also, if the user has reviewed the submission/topic with the least reviews, he should be allowed to perform review on other topics which have not reached their maximum threshold.
===Objective 6===
Provide a comprehensive suite of tests so that we can be sure that all review strategies are working.

==Issues==
==Testing==
==ScreenShots/ScreenCapture==
==Future Work==

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-04-01T00:29:52Z

Mjain2:

== Background ==
There are three different review strategies in Expertiza.
 Auto Selected
 Student Selected
 Instructor Selected
 In auto-selected reviewing, a reviewer picks the topic to review on, but not the individual submission.
Student-selected allows the reviewer to pick from a list of submissions, not topics.
Instructor-selected is where the instructor/TA assigns submissions to reviewers.
In the case of auto-selected and student-selected reviewing, the student is not allowed to pick from any topic or submission, but only to choose among those that have received the fewest reviews so far. But this strategy may be modified by selecting a non-zero threshold k as follows.
A topic is review able if the minimum number of reviews already done for the submissions on that topic is within k of the minimum number of reviews done on the least-reviewed submission on any topic.
==Motivation==
The goal of Expertiza is to support student-generated content through peer review and teamwork. It is a peer-review system that allows students to select a topic to work on, then submit their work and review their peers' submissions. As mentioned above there are different strategies available for reviewing other student;s work. However these strategies do not work as expected. It allowed students to choose many topics without submitting them. In some cases this causes exceeding the maximum limit for the assignment. Also allowing only the topic/submission with the minimum reviews to be allowed for review, did not allow users to select a topic which has a little more reviews than the minimum but has not crossed the maximum threshold. Certain changes in the algorithm for making a topic/submission allowable for review can help us overcome these problem.

==Design==
There were few faulty designs in the project which we have improvised.
#The the view - _set_self_review was related to student review technique. However its name was confusing and misleading. We have refactored and replaced it with _set_student_review.
#Ability to set maximum threshold for review for an assignment should be available for Auto Review and Student Review and not for Instructor Review. The existing design was faulty and we have made the required change so that this field is available only for student review and auto review. Appropriate changes are done in the jQuery method to implement this design change.
#If no submission was available, still the topic was made available to the user and on selection of the topic, he was provided the message that no submission is available to review. The user then had to go back and select some other topic if available. This process was time consuming. We have replaced this design using Javascript and make it work faster. If the topic had no submissions for review, the topic was not presented to the user.
#If the assignment was such that it had no topics, the user was directed to a page with a single button which further directed him to the page which listed available submissions for review. Although there is nothing wrong in this approach, the intermediate page was redundant and not performing any task. Thus we have replaced this design and the the intermediate page is bypassed.
#The existing design had no restriction on the number of reviews the student is allowed to begin without submitting. This design had a lot of problem. One problem was as mentioned before it would evade the maximum number of reviews. Another problem it caused was some students were unable to perform reviews as others performed too many reviews. We have devise an improved strategy which overcomes these drawbacks.

==Implementation==

===Objective 1===
Update code in for Student Selected Reviewing to cycle through submissions and not topics.
===Objective 2===
Make the ‘threshold box’ on the Edit /Create assignment - Review Strategy tab to appear only when Auto-selected or Student-selected reviewing is chosen and not when Instructor-selected is chosen.
===Objective 3===
Allowing a student to choose any number of reviews to do, without submitting any of them, allows a student to work on multiple reviews at the same time, but it also allows students to evade the limit on number of reviews that can be done. Devise a strategy to introduce certain threshold so that the student does not evades this limit.
===Objective 4===
If there are no topics, Auto-selected reviewing should still work, but it should select one of the submissions that has the fewest reviews so far. Perform Testing for this.
===Objective 5===
If the reviewer selects his own submission for review, he is not allowed to perform the review and presented with message saying “ There are no more submissions to review on that topic.” Instead it would be better not to allow him to select his own submission for review. Also, if the user has reviewed the submission/topic with the least reviews, he should be allowed to perform review on other topics which have not reached their maximum threshold.
===Objective 6===
Provide a comprehensive suite of tests so that we can be sure that all review strategies are working.

==Issues==
==Testing==
==ScreenShots/ScreenCapture==
==Future Work==

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-04-01T00:29:02Z

Mjain2:

== Background ==
There are three different review strategies in Expertiza.
 Auto Selected
 Student Selected
 Instructor Selected
 In auto-selected reviewing, a reviewer picks the topic to review on, but not the individual submission.
Student-selected allows the reviewer to pick from a list of submissions, not topics.
Instructor-selected is where the instructor/TA assigns submissions to reviewers.
In the case of auto-selected and student-selected reviewing, the student is not allowed to pick from any topic or submission, but only to choose among those that have received the fewest reviews so far. But this strategy may be modified by selecting a non-zero threshold k as follows.
A topic is review able if the minimum number of reviews already done for the submissions on that topic is within k of the minimum number of reviews done on the least-reviewed submission on any topic.
==Motivation==
The goal of Expertiza is to support student-generated content through peer review and teamwork. It is a peer-review system that allows students to select a topic to work on, then submit their work and review their peers' submissions.

==Design==
There were few faulty designs in the project which we have improvised.
#The the view - _set_self_review was related to student review technique. However its name was confusing and misleading. We have refactored and replaced it with _set_student_review.
#Ability to set maximum threshold for review for an assignment should be available for Auto Review and Student Review and not for Instructor Review. The existing design was faulty and we have made the required change so that this field is available only for student review and auto review. Appropriate changes are done in the jQuery method to implement this design change.
#If no submission was available, still the topic was made available to the user and on selection of the topic, he was provided the message that no submission is available to review. The user then had to go back and select some other topic if available. This process was time consuming. We have replaced this design using Javascript and make it work faster. If the topic had no submissions for review, the topic was not presented to the user.
#If the assignment was such that it had no topics, the user was directed to a page with a single button which further directed him to the page which listed available submissions for review. Although there is nothing wrong in this approach, the intermediate page was redundant and not performing any task. Thus we have replaced this design and the the intermediate page is bypassed.
#The existing design had no restriction on the number of reviews the student is allowed to begin without submitting. This design had a lot of problem. One problem was as mentioned before it would evade the maximum number of reviews. Another problem it caused was some students were unable to perform reviews as others performed too many reviews. We have devise an improved strategy which overcomes these drawbacks.

==Implementation==

===Objective 1===
Update code in for Student Selected Reviewing to cycle through submissions and not topics.
===Objective 2===
Make the ‘threshold box’ on the Edit /Create assignment - Review Strategy tab to appear only when Auto-selected or Student-selected reviewing is chosen and not when Instructor-selected is chosen.
===Objective 3===
Allowing a student to choose any number of reviews to do, without submitting any of them, allows a student to work on multiple reviews at the same time, but it also allows students to evade the limit on number of reviews that can be done. Devise a strategy to introduce certain threshold so that the student does not evades this limit.
===Objective 4===
If there are no topics, Auto-selected reviewing should still work, but it should select one of the submissions that has the fewest reviews so far. Perform Testing for this.
===Objective 5===
If the reviewer selects his own submission for review, he is not allowed to perform the review and presented with message saying “ There are no more submissions to review on that topic.” Instead it would be better not to allow him to select his own submission for review. Also, if the user has reviewed the submission/topic with the least reviews, he should be allowed to perform review on other topics which have not reached their maximum threshold.
===Objective 6===
Provide a comprehensive suite of tests so that we can be sure that all review strategies are working.

==Issues==
==Testing==
==ScreenShots/ScreenCapture==
==Future Work==

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-04-01T00:22:49Z

Mjain2:

== Background ==
There are three different review strategies in Expertiza.
 Auto Selected
 Student Selected
 Instructor Selected
 In auto-selected reviewing, a reviewer picks the topic to review on, but not the individual submission.
Student-selected allows the reviewer to pick from a list of submissions, not topics.
Instructor-selected is where the instructor/TA assigns submissions to reviewers.
In the case of auto-selected and student-selected reviewing, the student is not allowed to pick from any topic or submission, but only to choose among those that have received the fewest reviews so far. But this strategy may be modified by selecting a non-zero threshold k as follows.
A topic is review able if the minimum number of reviews already done for the submissions on that topic is within k of the minimum number of reviews done on the least-reviewed submission on any topic.
==Motivation==
The goal of Expertiza is to support student-generated content through peer review and teamwork. It is a peer-review system that allows students to select a topic to work on, then submit their work and review their peers' submissions.

==Design==
There were few faulty designs in the project which we have improvised.

#1. The the view - _set_self_review was related to student review technique. However its name was confusing and misleading. We have refactored and replaced it with _set_student_review.

#2. Ability to set maximum threshold for review for an assignment should be available for Auto Review and Student Review and not for Instructor Review. The existing design was faulty and we have made the required change so that this field is available only for student review and auto review. Appropriate changes are done in the jQuery method to implement this design change.

If no submission was available, still the topic was made available to the user and on selection of the topic, he was provided the message that no submission is available to review. The user then had to go back and select some other topic if available. This process was time consuming. We have replaced this design using Javascript and make it work faster. If the topic had no submissions for review, the topic was not presented to the user.

If the assignment was such that it had no topics, the user was directed to a page with a single button which further directed him to the page which listed available submissions for review. Although there is nothing wrong in this approach, the intermediate page was redundant and not performing any task. Thus we have replaced this design and the the intermediate page is bypassed.

The existing design had no restriction on the number of reviews the student is allowed to begin without submitting. This design had a lot of problem. One problem was as mentioned before it would evade the maximum number of reviews. Another problem it caused was some students were unable to perform reviews as others performed too many reviews. We have devise an improved strategy which overcomes these drawbacks.

==Implementation==

===Objective 1===
Update code in for Student Selected Reviewing to cycle through submissions and not topics.
===Objective 2===
Make the ‘threshold box’ on the Edit /Create assignment - Review Strategy tab to appear only when Auto-selected or Student-selected reviewing is chosen and not when Instructor-selected is chosen.
===Objective 3===
Allowing a student to choose any number of reviews to do, without submitting any of them, allows a student to work on multiple reviews at the same time, but it also allows students to evade the limit on number of reviews that can be done. Devise a strategy to introduce certain threshold so that the student does not evades this limit.
===Objective 4===
If there are no topics, Auto-selected reviewing should still work, but it should select one of the submissions that has the fewest reviews so far. Perform Testing for this.
===Objective 5===
If the reviewer selects his own submission for review, he is not allowed to perform the review and presented with message saying “ There are no more submissions to review on that topic.” Instead it would be better not to allow him to select his own submission for review. Also, if the user has reviewed the submission/topic with the least reviews, he should be allowed to perform review on other topics which have not reached their maximum threshold.
===Objective 6===
Provide a comprehensive suite of tests so that we can be sure that all review strategies are working.

==Issues==
==Testing==
==ScreenShots/ScreenCapture==
==Future Work==

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-04-01T00:19:16Z

Mjain2:

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-04-01T00:16:05Z

Mjain2:

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-03-31T20:50:36Z

Mjain2: /* Motivation */

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-03-31T19:34:33Z

Mjain2: /* Background */

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-03-31T19:33:54Z

Mjain2: /* Background */

== Background ==
There are three different review strategies in Expertiza.
 Auto Selected
Student Selected
Instructor Selected
In auto-selected reviewing, a reviewer picks the topic to review on, but not the individual submission.
Student-selected allows the reviewer to pick from a list of submissions, not topics.
Instructor-selected is where the instructor/TA assigns submissions to reviewers.
In the case of auto-selected and student-selected reviewing, the student is not allowed to pick from any topic or submission, but only to choose among those that have received the fewest reviews so far. But this strategy may be modified by selecting a non-zero threshold k as follows.
A topic is review able if the minimum number of reviews already done for the submissions on that topic is within k of the minimum number of reviews done on the least-reviewed submission on any topic.

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-03-31T19:33:11Z

Mjain2: /* Background */

== Background ==
There are three different review strategies in Expertiza.
Auto Selected
Student Selected
Instructor Selected
In auto-selected reviewing, a reviewer picks the topic to review on, but not the individual submission.
Student-selected allows the reviewer to pick from a list of submissions, not topics.
Instructor-selected is where the instructor/TA assigns submissions to reviewers.
In the case of auto-selected and student-selected reviewing, the student is not allowed to pick from any topic or submission, but only to choose among those that have received the fewest reviews so far. But this strategy may be modified by selecting a non-zero threshold k as follows.
A topic is review able if the minimum number of reviews already done for the submissions on that topic is within k of the minimum number of reviews done on the least-reviewed submission on any topic.

CSC/ECE 517 Spring 2014/oss E1402 mmb

2014-03-31T19:31:02Z

Mjain2: Created page with " == Background == There are three different review strategies in Expertiza. ==== Auto Selected ==== ==== Student Selected ==== ==== Instructor Selected ==== In auto-selected revi..."

== Background ==
There are three different review strategies in Expertiza.
==== Auto Selected ====
==== Student Selected ====
==== Instructor Selected ====
In auto-selected reviewing, a reviewer picks the topic to review on, but not the individual submission.
Student-selected allows the reviewer to pick from a list of submissions, not topics.
Instructor-selected is where the instructor/TA assigns submissions to reviewers.
In the case of auto-selected and student-selected reviewing, the student is not allowed to pick from any topic or submission, but only to choose among those that have received the fewest reviews so far. But this strategy may be modified by selecting a non-zero threshold k as follows.
A topic is review able if the minimum number of reviews already done for the submissions on that topic is within k of the minimum number of reviews done on the least-reviewed submission on any topic.

CSC/ECE 517 Spring 2014

2014-03-30T19:51:29Z

Mjain2:

*[[CSC/ECE_517_Fall_2012/example_page]]
*[[CSC/ECE 517 Spring 2014/ch1a 1e rm]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1h jg ]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1b np]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1f mj]]
*[[CSC/ECE 517 Spring 2014/ch1a 1d mm]]
*[[CSC/ECE 517 Spring 2014/ch1a 1c yj]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1l m]]
*[[CSC/ECE 517 Spring 2014/ch1 1w1m bm]]
*[[CSC/ECE 517 Spring 2014/ch1a 1p fy]]
*[[CSC/ECE 517 Spring 2014/oss E1404 mnp]]
*[[CSC/ECE 517 Spring 2014/oss E1402 mmb]]

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-24T00:32:34Z

Mjain2:

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.<ref>http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf</ref>

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools<ref>http://getbarkeep.org/</ref>. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction.<ref>https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools</ref> Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time<ref>http://getbarkeep.org/</ref>.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity], which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the cyclomatic complexity at a low number is very essential, it ensures your code is simple to test and debug.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis.<ref>http://blog.8thcolor.com/2013/09/pullreview-reach-your-ruby-code-skill-walhalla/</ref> It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.<ref>http://blog.martyandrews.net/2008/09/roodi-checkstyle-for-ruby.html</ref>

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code<ref>http://en.wikipedia.org/wiki/Crucible_(software)</ref>. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles<ref>https://www.atlassian.com/software/crucible/overview </ref>. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review<ref>https://confluence.atlassian.com/display/CRUCIBLE/The+Crucible+workflow</ref>.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool.<ref>http://code.google.com/p/jupiter-eclipse-plugin/wiki/UserGuide</ref> It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews.<ref>http://www.reviewboard.org/</ref> It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4<ref>http://www.reviewboard.org/docs/manual/dev/users/getting-started/workflow/</ref>.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service.<ref>https://developers.google.com/appengine/articles/rietveld?hl=zh-cn</ref> It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= See Also =

* [http://en.wikipedia.org/wiki/Code_review Code Review]

* [http://en.wikipedia.org/wiki/Static_program_analysis Static program analysis]

* [http://en.wikipedia.org/wiki/Software_inspection Software inspection]

* [http://en.wikipedia.org/wiki/Debugging Debugging]

* [http://en.wikipedia.org/wiki/Ruby_gems Ruby Gems]

* [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T04:30:56Z

Mjain2:

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.<ref>http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf</ref>

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools<ref>http://getbarkeep.org/</ref>. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction.<ref>https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools</ref> Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time<ref>http://getbarkeep.org/</ref>.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis.<ref>http://blog.8thcolor.com/2013/09/pullreview-reach-your-ruby-code-skill-walhalla/</ref> It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.<ref>http://blog.martyandrews.net/2008/09/roodi-checkstyle-for-ruby.html</ref>

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code<ref>http://en.wikipedia.org/wiki/Crucible_(software)</ref>. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles<ref>https://www.atlassian.com/software/crucible/overview </ref>. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review<ref>https://confluence.atlassian.com/display/CRUCIBLE/The+Crucible+workflow</ref>.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool.<ref>http://code.google.com/p/jupiter-eclipse-plugin/wiki/UserGuide</ref> It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews.<ref>http://www.reviewboard.org/</ref> It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4<ref>http://www.reviewboard.org/docs/manual/dev/users/getting-started/workflow/</ref>.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service.<ref>https://developers.google.com/appengine/articles/rietveld?hl=zh-cn</ref> It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= See Also =

* [http://en.wikipedia.org/wiki/Code_review Code Review]

* [http://en.wikipedia.org/wiki/Static_program_analysis Static program analysis]

* [http://en.wikipedia.org/wiki/Software_inspection Software inspection]

* [http://en.wikipedia.org/wiki/Debugging Debugging]

* [http://en.wikipedia.org/wiki/Ruby_gems Ruby Gems]

* [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby]

* [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails]

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T04:13:50Z

Mjain2: /* Barkeep */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.<ref>http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf</ref>

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools<ref>http://getbarkeep.org/</ref>. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction.<ref>https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools</ref> Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time<ref>http://getbarkeep.org/</ref>.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis.<ref>http://blog.8thcolor.com/2013/09/pullreview-reach-your-ruby-code-skill-walhalla/</ref> It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.<ref>http://blog.martyandrews.net/2008/09/roodi-checkstyle-for-ruby.html</ref>

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code<ref>http://en.wikipedia.org/wiki/Crucible_(software)</ref>. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles<ref>https://www.atlassian.com/software/crucible/overview </ref>. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review<ref>https://confluence.atlassian.com/display/CRUCIBLE/The+Crucible+workflow</ref>.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool.<ref>http://code.google.com/p/jupiter-eclipse-plugin/wiki/UserGuide</ref> It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews.<ref>http://www.reviewboard.org/</ref> It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4<ref>http://www.reviewboard.org/docs/manual/dev/users/getting-started/workflow/</ref>.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service.<ref>https://developers.google.com/appengine/articles/rietveld?hl=zh-cn</ref> It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T04:11:39Z

Mjain2: /* Review Board */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.<ref>http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf</ref>

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction.<ref>https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools</ref> Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time<ref>http://getbarkeep.org/</ref>.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.<ref>http://www.sitepoint.com/code-metrics-and-you/</ref>

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis.<ref>http://blog.8thcolor.com/2013/09/pullreview-reach-your-ruby-code-skill-walhalla/</ref> It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.<ref>http://blog.martyandrews.net/2008/09/roodi-checkstyle-for-ruby.html</ref>

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code<ref>http://en.wikipedia.org/wiki/Crucible_(software)</ref>. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles<ref>https://www.atlassian.com/software/crucible/overview </ref>. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review<ref>https://confluence.atlassian.com/display/CRUCIBLE/The+Crucible+workflow</ref>.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool.<ref>http://code.google.com/p/jupiter-eclipse-plugin/wiki/UserGuide</ref> It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews.<ref>http://www.reviewboard.org/</ref> It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4<ref>http://www.reviewboard.org/docs/manual/dev/users/getting-started/workflow/</ref>.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service.<ref>https://developers.google.com/appengine/articles/rietveld?hl=zh-cn</ref> It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T04:06:24Z

Mjain2: /* Barkeep */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.<ref>http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf</ref>

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction.<ref>https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools</ref> Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time<ref>http://getbarkeep.org/</ref>.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis.<ref>http://blog.8thcolor.com/2013/09/pullreview-reach-your-ruby-code-skill-walhalla/</ref> It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.<ref>http://blog.martyandrews.net/2008/09/roodi-checkstyle-for-ruby.html</ref>

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code<ref>http://en.wikipedia.org/wiki/Crucible_(software)</ref>. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles<ref>https://www.atlassian.com/software/crucible/overview </ref>. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review<ref>https://confluence.atlassian.com/display/CRUCIBLE/The+Crucible+workflow</ref>.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool.<ref>http://code.google.com/p/jupiter-eclipse-plugin/wiki/UserGuide</ref> It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews.<ref>http://www.reviewboard.org/</ref> It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service.<ref>https://developers.google.com/appengine/articles/rietveld?hl=zh-cn</ref> It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T04:03:49Z

Mjain2: /* Barkeep */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.<ref>http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf</ref>

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time<ref>http://getbarkeep.org/</ref>.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code<ref>http://en.wikipedia.org/wiki/Crucible_(software)</ref>. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles<ref>https://www.atlassian.com/software/crucible/overview </ref>. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review<ref>https://confluence.atlassian.com/display/CRUCIBLE/The+Crucible+workflow</ref>.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool.<ref>http://code.google.com/p/jupiter-eclipse-plugin/wiki/UserGuide</ref> It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews.<ref>http://www.reviewboard.org/</ref> It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service.<ref>https://developers.google.com/appengine/articles/rietveld?hl=zh-cn</ref> It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T04:01:33Z

Mjain2: /* Crucible */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.<ref>http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf</ref>

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code<ref>http://en.wikipedia.org/wiki/Crucible_(software)</ref>. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles<ref>https://www.atlassian.com/software/crucible/overview </ref>. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review<ref>https://confluence.atlassian.com/display/CRUCIBLE/The+Crucible+workflow</ref>.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews.<ref>http://www.reviewboard.org/</ref> It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service.<ref>https://developers.google.com/appengine/articles/rietveld?hl=zh-cn</ref> It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:58:53Z

Mjain2: /* Lightweight code review */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.<ref>http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf</ref>

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:56:10Z

Mjain2: /* Brakeman */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues.<ref>http://brakemanscanner.org/ </ref> Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.<ref>http://whiteboxqa.com/StudentMaterial/Books/IP-WBT-01-JavaPowerTools.pdf</ref>

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:49:23Z

Mjain2: /* Jupiter */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an [http://en.wikipedia.org/wiki/Xml XML] file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| MIT || Open Source || Ruby || Ruby Gem || Free
|-
! Flog
| Ruby Sadists || Open Source || Ruby || Ruby Gem || Free
|-
! Saikuro
| Ubit || Open Source || Ruby || Ruby Gem || Free
|-
! PullReview
| Brussels || Open Source || Ruby || Desktop Client || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:48:00Z

Mjain2: /* Roodi */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It [http://en.wikipedia.org/wiki/Parsing parses] the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks, etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that the shipped checks can also be easily configured with a [http://en.wikipedia.org/wiki/Yaml YAML] file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| SmartBear || Proprietary || || Desktop Client || Paid
|-
! Flog
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Saikuro
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Dust
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:46:25Z

Mjain2: /* PullReview */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It parses the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks,etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that The shipped checks can also be easily configured with a YAML file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| SmartBear || Proprietary || || Desktop Client || Paid
|-
! Flog
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Saikuro
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Dust
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:41:40Z

Mjain2: /* PullReview */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like [[Brakeman]], Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It parses the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks,etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that The shipped checks can also be easily configured with a YAML file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Roodi
| SmartBear || Proprietary || || Desktop Client || Paid
|-
! Flog
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Saikuro
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Dust
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:38:50Z

Mjain2: /* Barkeep */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It parses the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks,etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that The shipped checks can also be easily configured with a YAML file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Collaborator
| SmartBear || Proprietary || || Desktop Client || Paid
|-
! Code Striker
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Gerrit
| code.google.com || Open Source || Java || Web Application || Free
|-
! Groogle
| groogle.sourceforge.net || Open Source || PHP || Web Application || Free
|-
! JCR
| jcodereview.sourceforge.net || Open Source || Java || Web Application || Free
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Malevich
| malevich.codeplex.com || Open Source || || Web Application || Free
|-
! Perforce
| perforce.com || Proprietary || Multiple || Both || Paid
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:38:20Z

Mjain2: /* Brakeman */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in [http://en.wikipedia.org/wiki/Web_server web server] or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [ http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It parses the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks,etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that The shipped checks can also be easily configured with a YAML file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Collaborator
| SmartBear || Proprietary || || Desktop Client || Paid
|-
! Code Striker
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Gerrit
| code.google.com || Open Source || Java || Web Application || Free
|-
! Groogle
| groogle.sourceforge.net || Open Source || PHP || Web Application || Free
|-
! JCR
| jcodereview.sourceforge.net || Open Source || Java || Web Application || Free
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Malevich
| malevich.codeplex.com || Open Source || || Web Application || Free
|-
! Perforce
| perforce.com || Proprietary || Multiple || Both || Paid
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:37:22Z

Mjain2: /* Brakeman */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source [http://en.wikipedia.org/wiki/Vulnerability_(computing) vulnerability] scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in web server or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [ http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It parses the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks,etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that The shipped checks can also be easily configured with a YAML file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Collaborator
| SmartBear || Proprietary || || Desktop Client || Paid
|-
! Code Striker
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Gerrit
| code.google.com || Open Source || Java || Web Application || Free
|-
! Groogle
| groogle.sourceforge.net || Open Source || PHP || Web Application || Free
|-
! JCR
| jcodereview.sourceforge.net || Open Source || Java || Web Application || Free
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Malevich
| malevich.codeplex.com || Open Source || || Web Application || Free
|-
! Perforce
| perforce.com || Proprietary || Multiple || Both || Paid
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:36:03Z

Mjain2: /* Introduction */

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps [http://en.wikipedia.org/wiki/Quality_assurance quality assurance] (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source vulnerability scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in web server or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [ http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro looks like this:

[[File:Saikuro_1.png]]

* More examples can be viewed [http://saikuro.rubyforge.org/ here].

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It parses the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks,etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that The shipped checks can also be easily configured with a YAML file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

'''Example Usage'''

* Check all ruby files recursively under the current directory:

<pre>
$ roodi
</pre>

* Check all ruby files in a rails app:

<pre>
$ roodi "rails_app/**/*.rb"
</pre>

* Check one controller and one model file in a rails app:

<pre>
$ roodi app/controller/sample_controller.rb app/models/sample.rb
</pre>

* Check all ruby files in a rails app with a custom configuration file:

<pre>
$ roodi -config=my_roodi_config.yml "rails_app/**/*.rb"
</pre>

* For more details, please refer to [https://github.com/roodi/roodi here].

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

==Other Tools==

* [https://code.google.com/p/gerrit/ Gerrit] is a web based code review system, facilitating online code reviews for projects using the Git version control system.

* [http://jcodereview.sourceforge.net/ JCR] is a web application for performing and managing formal code reviews. It can be used for reviews of any type of source code, although it has some special smarts for reviewing Java projects. It has special features to make large-scale reviews not only practical but easy and fast.

* [http://www.sonarqube.org/ Sonar] is an open platform to manage code quality.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== Rietveld ==

Rietveld is a web-based collaborative code review tool for use with Subversion to run on Google’s cloud service. It is written by Guido van Rossum, Python creator. While this web app was primarily written to serve as a showcase for using Django with Google App Engine, the scalable infrastructure for web applications that developer helped build, serves as a useful tool for the open source community, especially the Python community. Rietveld is inspired by Mondrian, which once has been intensively used inside Google to review their code.Part of the Rietveld’s code derived from Mondrian.

'''Workflow'''

The feature sets of Rietveld and Review Board are strikingly similar, which is not surprising as they both used Mondrian as a model. van Rossum originally wanted to turn Mondrian into a free software project, but it was too tied to "proprietary Google infrastructure", so he started over, with Rietveld as the result. Both tools are implemented in Python using the Django framework, but one major difference is that Rietveld is written to use Google App Engine.

'''Advantage'''

* Simplified deployment: For free software projects, where code review is purposely done in the open, Rietveld provides a way to quickly try the application out. They don’t need to find a server and run the application, as which would be required with Review Board.

* Cross platform: It is extremely easy to install Rietveld in a different environment by replacing the App Engine-specific pieces, but that clearly is not where it is targeted.

* Free and open to public: Anyone can browse the system, but only users who have a Google account can add issues, comments, and conduct reviews using the tool.

* Introduction to the Google App Engine interface: While Rietveld does not provide much in the way of additional functionality from Review Board, and in fact it lags Review Board in some areas, Rietveld does provide a very nice introduction to the Google App Engine interface. Developers can use the code as a template for their own ideas once Google makes more App Engine accounts available.

= Comparison =

{| border="1" class="wikitable"
|+ Comparison of code review tools
!
! Maintainer
! License
! Developed In
! Desktop Client vs Web App
! Cost
|-
! Brakeman
| brakemanscanner.org || Open Source || Ruby || Desktop Client || Free
|-
! Barkeep
| Ooyala || Open Source || Ruby || Web Application || Free
|-
! Collaborator
| SmartBear || Proprietary || || Desktop Client || Paid
|-
! Code Striker
| codestriker.sourceforge.net || Open Source || Pearl || Web Application || Free
|-
! Crucible
| Atlassian || Proprietary || Java || Web Application || Paid
|-
! Gerrit
| code.google.com || Open Source || Java || Web Application || Free
|-
! Groogle
| groogle.sourceforge.net || Open Source || PHP || Web Application || Free
|-
! JCR
| jcodereview.sourceforge.net || Open Source || Java || Web Application || Free
|-
! Jupiter
| code.google.com || Open Source || Java || Desktop Client (Eclipse) || Free
|-
! Malevich
| malevich.codeplex.com || Open Source || || Web Application || Free
|-
! Perforce
| perforce.com || Proprietary || Multiple || Both || Paid
|-
! Rietveld
| Google App Engine || Open Source|| Python || Web Application || Free
|-
! Review Board
| reviewboard.org || MIT || Python || Web Application || Free
|}

= References =
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:31:17Z

Mjain2:

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps quality assurance (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source vulnerability scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in web server or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code. Users can attend commits made to any [http://en.wikipedia.org/wiki/Git_(software) Git] repository, see [http://en.wikipedia.org/wiki/Diffs diffs], write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also [ http://en.wikipedia.org/wiki/Script_(computing) script] tools. It comes with a command line client and [http://en.wikipedia.org/wiki/REST REST] APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a [http://githooks.com/ git hook]. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the [http://en.wikipedia.org/wiki/Cyclomatic_complexity cyclomatic complexity] at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro can be viewed [http://saikuro.rubyforge.org/ here].
[[File:Saikuro_1.png]]

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is [http://en.wikipedia.org/wiki/SaaS “SAAS”] solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreview sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It parses the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks,etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that The shipped checks can also be easily configured with a YAML file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company [https://www.atlassian.com/ Atlassian], tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with [http://en.wikipedia.org/wiki/JIRA JIRA] which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse] code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* [http://en.wikipedia.org/wiki/Cross-platform Cross-platform] Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc review comments and the corresponding source code.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like [http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar], [http://en.wikipedia.org/wiki/ClearCase ClearCase], [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], Git, [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Perforce Perforce], and [http://en.wikipedia.org/wiki/Subversion_(software) Subversion]. It can be installed on any server running [http://en.wikipedia.org/wiki/Apache Apache] or [ http://en.wikipedia.org/wiki/Lighttpd lighttpd] and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It provides rich extension framework to add features to Review Board.

== References ==
<references/>
----

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T03:31:03Z

Mjain2: Blanked the page

CSC/ECE 517 Spring 2014/ch1 1w1f mj

2014-02-11T02:51:08Z

Mjain2:

[http://en.wikipedia.org/wiki/Code_review Code review] is the process of evaluation of computer [http://http://en.wikipedia.org/wiki/Source_code source code], with the intention of finding and fixing faults and design errors neglected in the initial development phase. Code review helps in improving the overall quality of software and maintains the consistency in software design and implementation. The reviewer examines the code and reports the findings to the author, which helps in improving the developer’s skill.

= Introduction =

Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps quality assurance (QA) testers get together to review code.<ref>http://searchsoftwarequality.techtarget.com/definition/code-review </ref> It facilitates systematic examination of source code for vulnerabilities such as buffer overflows, race conditions, memory leakage, size violations, and duplicate statements. Code review can also help in looking for security breaches to the software which requires higher security.

= Types of Code review =

Code review practices can be divided into the following categories.

=== Formal inspections===

Formal inspections refers to a heavy process with several participants sitting together to review code. The defects discovered in this process are usually recorded in great detail.

=== Lightweight code review ===

* Over the shoulder: An “over-the-shoulder” review is the most common and informal code review technique where the developer stands over the author’s workstation while the author walks the reviewer through a set of code changes.

* Email pass around: The author bundles up all source code and sends it to reviewers. Reviewers examine the code, communicate with other developers and suggest changes via e-mail.

* Pair Programming: In Pair Programming, two developers write code at the same workstation and there is continuous free-form discussion and review.

* Tool assisted code review: Reviewers use specialized tools in different stages of the code review, which includes collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, etc.

= Code Review Tools for Ruby =

== Brakeman ==

Brakeman is an open source vulnerability scanner tool explicitly designed for Ruby on Rails applications. It can be used at any stage of the development to statically analyze Rails application code and find out the security issues. Brakeman carefully inspects the source code of your application and you do not need to set up your whole application stack to use it. Brakeman scans through the application code and produce a summary of all security issues it has found. Brakeman is extremely suspicious and hence sometimes it provides “false positives.” It does not finds security vulnerabilities in web server or other software as it just scans the source code and not the entire application stack.

'''Advantages'''

* No Configuration Necessary: Brakeman does not require any setup or configuration once it is installed.

* Run It Anytime: As it’s working is based on just the source code, Brakeman can be used at any stage of the development process.

* Ruby Specific: Brakeman is especially built for applications developed in Ruby on Rails, so it can easily check configuration settings for best practices.

* Flexible Testing: Each check performed by Brakeman is independent, so testing can be limited to a subset of all the checks Brakeman comes with.

* Speed: Brakeman is much faster than other “black box” website scanners. Even large applications do not take more than a few minutes to scan.

'''Example'''

Here's one example of warnings Brakeman reports: SQL injection.

* A Rails 3.x code segment looks like this :

<pre>
username = params[:user][:name].downcase
password = params[:user][:password]

User.first.where("username = '" + username + "' AND password = '" + password + "'")
</pre>

* Brakeman would produce a warning like this:

<pre>
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
</pre>

== Barkeep ==

Barkeep is one of the friendly Code Review System which can be used by developers to keep high quality standard of code.Users can attend commits made to any Git repository, see diffs, write comments, and have those comments emailed to your fellow committers. Barkeep is unopinionated. It can be used with pre-commit or post-commit workflows, and also script tools. It comes with a command line client and REST APIs.

Barkeep is a small codebase written in Ruby. It's easy to add new features and APIs as per the requirement.

'''Advantages'''

* Naturally supports post-commit workflows: Barkeep supports post-commit code review workflow. Here, once the part of the code of the developer is ready, he pushes it to the master, so that it becomes available to other developer to begin integrating it. Code review happens when it's conducive for the team (within 1-2 days), and any comments are addressed in future commits.

* Clean User Interface: Barkeep is designed with a basic UI. The general actions, like leaving a quick comment and approving a commit, are low-friction. Also it provides various keyboard shortcuts for ease of use.

* Hackable: The codebase of barkeep is small, obtainable and fun to hack on. It can be easily extended and improved with time.

==Flog==

Flog gives feedback about the quality of Ruby code by scoring using the [http://c2.com/cgi/wiki?AbcMetric ABC metric]: assignments, branches, calls, with particular attention placed on calls. The ABC metric is a neat measurement since it combines a lot of information in a way that we can easily understand. But this leads to one important feature of Flog, that is the score reported is very opinionated. This score is custom built to apply commonly accepted design patterns for Ruby. Therefore, we can think of Flog as a modified ABC measurement.

Flog takes the following branching terms into consideration: and, case, else, if, or, rescue, until, when and while. There are other rules that add to branch total, but these are the most important. Assignments are much more simple, Flog add one to the score per assignment. Calls are defined as any instance method call that takes the flow out of the current scope.

'''Advantages'''

* Keep track of code complexity: Flog reports code complexity of each method. In this way, developer is able to know what code segment in the project is different to follow.

* ABC metric: Flog reports ABC metric which is an easily understood measurement of code complexity.

* Ruby support: It support different version of Ruby including 1.8 and 1.9 syntax.

* Speed: Flog executes quite fast, which makes it perfect for a githook. A pre-commit hook which checks code complexity and returns non-zero for any score higher than 61 works quite well.

'''Example'''

* Original code

<pre>
class Test
def blah
a = eval "1+1"
if a == 2 then
puts "yay"
end
end
end
</pre>

* What we see in Flog

<pre>
class Test
def blah # 11.2 =
a = eval "1+1" # 1.2 + 6.0 +
if a == 2 then # 1.2 + 1.2 + 0.4 +
puts "yay" # 1.2
end
end
end
</pre>

* Report generated

<pre>
Test#blah: (11.2)
6.0: eval
1.2: branch
1.2: ==
1.2: puts
1.2: assignment
0.4: lit_fixnum
</pre>

== Saikuro ==

Saikuro is mainly designed to analyze cyclomatic complexity, which is a graphical measurement to indicate the complexity of a program, on Ruby program. Given a source project, Saikuro will find each instance method in it, calculate its cyclomatic complexity and generate a report listing all the result according to each method found. In addition, Saikuro also counts the number of lines per method as well as the number of tokens on each line, and generate another report on that.

Saikuro measures complexity, but as we all know, Ruby is a tricky language. Saikuro adds a branch when it encounters conditional statements like if, unless, while, until, for, elsif and when, but it also adds a branch if the code uses a block. This is because using a block in Ruby very often changes the control flow. Keeping the cyclomatic complexity at a low number is very essential, it ensures your code is simple to test and debug.

'''Advantages'''

* Cyclomatic complexity: Saikuro calculates cyclomatic complexity in a more 'Ruby' way so that it is more concise on Ruby projects.

* Different kind of targets: Saikuro can be recursively used on a dir or a specific troublesome class.

* Lightweight and quick: It is very similar to the code evaluation tool Flog we covered before. It is a quick reporting tool that can help users understand where they have excess complexity in their projects.

'''Example'''

* A report generated by Saikuro can be viewed [http://saikuro.rubyforge.org/ here].
[[File:Saikuro_1.png]]

== PullReview ==

PullReview is an Automated Code Review Tool for Ruby developers using GitHub. PullReview is “SAAS” solution. It requires no servers to install, no extra software. Setup is very easy - Click the button, link to GitHub, and PullReview can start reviewing your branches. It provides feedback very quickly, without having to sit and wait for a colleague to come and have a look. Another important feature is that it does not keep to static analysis. It aggregates several analysis results, and points out the problems at hand – in order of impact. It also tells you ways to make your code better.

'''Advantages'''

* Telling You Where to Go Next: PullReview make your coding more robust, it improves you as a coder. It tells you why best practices are what they are – and where to apply them. PullReview analyzes your branches using all important metrics. It tells you what you are doing wrong and what the impact is.

* Ruby Specific: Like Brakeman, Roodi is specifically built for Ruby on Rails which helps in checking composition and structure settings for best practices.

* Quick Setup: No setting up of servers or installing a plethora of tools is required. Pullreviews sets up quickly and saves time.

'''Example''' can be viewed [https://www.pullreview.com/site/onboarding here].

== Roodi ==

Roodi stands for Ruby Object Oriented Design Inferometer. It parses the Ruby code and warns about the design issues from the list configured for example Class line count check, for loop check, parameter number check, cyclomatic checks,etc. It helps in breaking down complex and long methods.

'''Advantages'''

* Extendable: One advantage of Roodi is that The shipped checks can also be easily configured with a YAML file, which is easy to manipulate. In that way, users are able to write customized class to add new checks. A checker class registers the types of AST nodes it’s interested and then handle the matched subtrees.

== Other Tools ==

= Code Review Tools for Java =

== Crucible ==

Crucible is a collaborative code review application developed by software company Atlassian, tailored to distributed teams, and facilitates asynchronous review and commenting on code. Crucible also articulates with prominent source control tools, such as Git and Subversion. Crucible is a flexible application that caters for a wide range of team sizes and work styles. Crucible also supports integration with JIRA which is Atlassian's issue tracking and project management application.

'''Workflow '''

1. Creating a Review.

2. Adding content to the review.

3. Performing the review

4. Summarising and closing the review.

''' Advantages '''

* Flexible Code Review: Crucible provides configurable options to track and complete reviews - Defined workflow, Moderator, One or more participants. It also supports in-line code discussions.

* Pre-commit support: It allows code review before check in which ensures that any code going into production has been reviewed. It allows code review from command line.During the pre-commit review process code is re-factored, changed, and updated. Crucible takes this into account and makes sure all files you are reviewing are easily updated and current.

* Traceability: Developers have a unified view that shows all the activity in their code for commits and reviews. It supports creating filters which provides notification of code committed by new team members. The review coverage report provides information about which parts have already been reviewed and which are currently in review.

* Notifications: It provides automatic or manual way of notifying reviewers who have not completed your code reviews. Crucible provides multiple features to help team stay on top of their workload.

== Jupiter==

Jupiter is an open source collaborative Eclipse code review tool. It uses a simple, lightweight code review process that is easy to learn and adopt. The result of a research project by the Collaborative Software Development Laboratory at the University of Hawaii, the Jupiter plug-in stores code reviews in an XML file format and maintains them in the project configuration management system alongside the source code.

'''Workflow'''

The code review process implemented in Jupiter is relatively simple, and it should suffice for most
projects. In Jupiter, you conduct a code review in the following four stages:

Configuration: The reviewer initiator sets up the review, specifies the files to be reviewed and what issues can be raised.

Individual code review: Each reviewer examines the code individually, using a review checklist and raising issues as they encounter them. Jupiter saves the issues you create in XML form directly in the
project directory.

Team review: The review team (including the author) meet to discuss issues and decide on actions to take. This generally involves a face-to-face meeting, using Jupiter to help work through all the review issues.

Rework: The developer goes through the raised issues and fixes them.

Throughout the whole process, the review files are stored and updates in the source code repository, providing a history of raised issues and how they have been corrected.

Jupiter is an innovative and flexible tool that helps automate peer code reviews and track issues. Until
recently, it was quite unique in this domain. Of late, however, it does have a commercial competitor,
Crucible, which we mentioned before.

'''Advantages'''

* Free: It is open source and free. Jupiter uses the CPL License.

* Cross-platform: Jupiter is based upon the Eclipse plug-in architecture. It is available for all platforms supported by Eclipse.

* More simply data reuse and sharing: Jupiter stores data in XML format as well as CM repository. Users of Jupiter share their data ﬁles the same way they share their code using CVS or some other CM repository.

* Sorting and Filtering: Jupiter provides ﬁlters and sorting to facilitate going over the code
review issues.

* File integration: Jupiter has the capability to easily jump back and forth between speciﬁc
review comments and the corresponding source code.

=Code Review Tools for Python=

== Review Board ==

Review Board is a powerful web-based code review tool that offers developers an easy way to handle code reviews. It works well with small projects as well as large companies. Review Board integrates with various version control systems like Bazaar, ClearCase, CVS, Git, Mercurial, Perforce, and Subversion. It can be installed on any server running Apache or lighttpd and is free for both personal and commercial use. There is also an official commercial Review Board hosting service, RBCommons for Review Board.

'''Workflow (pre-commit)'''
1. Make a change to your local source tree.

2. Create a review request for your new change.

3. Publish the review request and wait for your reviewers to see it.

4. Wait for feedback from the reviewers.

5. If they’re ready for it to go in:
: 5.1 Submit your change to the repository.
: 5.2 Click Close ‣ Submitted on the review request action bar.

6. If they’ve requested changes:
: 6.1 Update the code in your tree and generate a new diff.
: 6.2 Upload the new diff, specify the changes in the Change Description box, and publish.
: 6.3 Jump back to step 4.

'''Advantages'''

* Easily track your team's review requests: The dashboard provides an up-to-the-minute overview of all the review requests. Provides easy controls to group/ sort your review requests, and see what's left to review.

* Review all kinds of files: Along with code review, Review Board can also be used to review other files by the team members. You can upload screenshots of your feature, or a file showing log output of a unit test run.

* All history at one place: With Review Board, the entire history of development is in one place. Each change's review request shows the entire development discussion and each iteration of the change that people have reviewed.

* Helpful command-line tools and Extensible: The RBTools command line tools make it easy to quickly create review requests based on the changes in your source tree and to keep them up-to-date. The fully-featured REST and Python API provides automation and integration. It prrovides rich extension framework to add features to Review Board.

== References ==
<references/>
----

File:Saikuro 1.png

2014-02-11T02:49:28Z

Mjain2: saikuro

saikuro

File:One to one review.png

2014-02-11T01:53:49Z

Mjain2: one-to-one review image

one-to-one review image