Thoughts to keep in mind for Code Review

[Ian Booth]

-1 on annotations. If you need to annotate to make it clearer then that should
be done as code comments so the next poor soul who reads the code has a clue of
what's been done

On 25/06/14 14:20, John Meinel wrote:
> An interesting article from IBM:
> http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/
> 
> There is a pretty strong bias for "we found these results and look at how
> our tool makes it easier to follow these guidelines", but the core results
> are actually pretty good.
> 
> I certainly recommend reading it and keeping some of it in mind while
> you're both coding and reviewing. (Particularly how long should code review
> take, and how much code should be put up for review at a time.)
> Another trick that we haven't made much use of is to annotate the code we
> put up for review. We have the summary description, but you can certainly
> put some inline comments on your own proposal if you want to highlight
> areas more clearly.
> 
> John
> =:->
> 
> 
>