-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 > =:-> > > > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
