Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Here is a not so comprehensive list:</p> <ul> <li>Adherence to standards and guidelines (This means you should have coding standards set for your project)</li> <li>Documenatation. All good code must be documented cleanly.</li> <li>repetitive code (candidate for refactoring)</li> <li>meaningful variable names</li> <li>variable and method scopes (private vs public)</li> <li>Use of good design patterns (if possible)</li> <li>Good test cases associated with the code. Preferably automated test cases.(it is not easy to automate all test cases, though it is desirable. If such is the case, it should document how to test the given functionality)</li> </ul> <p>In addition since you spoke about Java, there are many tools available allow you to analyze the code and check for style and code cleanliness and even potential issues.</p> <ul> <li>PMD (<a href="http://pmd.sourceforge.net/" rel="noreferrer">http://pmd.sourceforge.net/</a>)</li> <li>Checkstyle (<a href="http://checkstyle.sourceforge.net/" rel="noreferrer">http://checkstyle.sourceforge.net/</a>)</li> <li>FindBugs (<a href="http://findbugs.sourceforge.net/" rel="noreferrer">http://findbugs.sourceforge.net/</a>)</li> </ul> <p>All of these can be configured with an automated build/continuous integration process and check for issues even before you go through a manual code review. I used PMD and Checkstyle at my last project and I was pleasantly surprised that how many issues were we able to discover and fix even before we sat down for a code review.</p> <p>Here is an article that I always share with my team for code reviews. This just outlines the general guidelines surrounding code reviews. <a href="http://www.developer.com/java/other/article.php/3579756" rel="noreferrer">http://www.developer.com/java/other/article.php/3579756</a></p> <p>One thing to note though, is One on one code reviews are not very effective. I personally like to use code reviews as a learning mechanism for other team members to even understand what each person on the team is working on. It should always be a team exercise. It allows junior members some exposure to some good practices.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload