I agree that the code needs to be self-explanatory enough to not require annotations, but annotations can be useful - especially for larger changes. Suggesting the order for code to be reviewed is certainly useful if you're reviewing code in a part of the system you aren't familiar with
On Wed, Jun 25, 2014 at 10:25 AM, Jeroen Vermeulen < [email protected]> wrote: > On 2014-06-25 09:43, roger peppe wrote: > > About pre-review annotations, I agree with Ian that the code should be >> documented >> well enough that someone coming to it from scratch can understand it, but >> I also wonder if there is a room for review-specific comments, talking >> about >> reasons for the changes themselves in the specific context of that review. >> > > There is, I think. But should it be quite so close to the code, where it > competes against commenting for the coder's time? > > Don't know if there's a definite answer, because either way we assume a > human process to complement the technical solution. But if a coder starts > by reviewing their own code, perhaps they should also turn these notes into > a single coherent "cover letter" and, in explaining, perhaps spot > structural flaws or anticipate questions. > > > Jeroen > > > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
