Re: Will you help me put together a code review checklist?

Discussion in 'C++' started by Ian Collins, Nov 16, 2010.

  1. Ian Collins

    Ian Collins Guest

    On 11/16/10 09:13 AM, James Kanze wrote:
    > On Nov 15, 12:31 am, Ian Collins<> wrote:
    >> On 11/15/10 01:49 AM, James Kanze wrote:

    >>> On Nov 13, 2:49 am, Andrew<> wrote:

    >>>> o Code review is a good thing, so we should do more of it. I
    >>>> reckon pair programming achieves the ideal, where it is being done
    >>>> *all* the time.

    >>> No. Pair programming does not address the issues that code
    >>> review addresses. Good code review requires someone from
    >>> outside to review the code, not someone who is intimely involved
    >>> in it.

    >> True, but coupled with collective code ownership, it does
    >> become a credible alternative to code review.

    > How? One of the most important aspects of code review is that
    > at least one of the reviewers is seeing the code for the first
    > time. And one of the essential elements being reviewed is that
    > he can easily understand it, uniquely from the code and the
    > documentation. How does pair programming address this issue?

    I wrote "coupled with collective code ownership" deliberately. The more
    people who work on the code, the more "fresh eyes" get to read it. As
    Francis mentioned else-thread, pairs are not static so the new person
    joining the developer working on a particular piece of code will be
    seeing it for the first time.

    > And I'm not sure what you mean by "collective code ownership".

    I'm sure you are:

    >>> Globally considered, pair programming is not cost
    >>> efficient (but it can be useful in specific cases, e.g. bringing
    >>> a new hire up to speed in your code).

    >> Care to back that up with some real world data?

    > In what way?
    > First, clearly, the impact of pair programming will vary
    > according to the people involved; having someone looking over my
    > shoulder slows me down most of the time, and reduces quality
    > (since I'm happy if he understands the code, rather than trying
    > to make it understandable to anyone who reads it), but I'm
    > perfectly willing to admit that there are people who work faster
    > and better in such cases.

    A pair will never be looking over your shoulder, he will be working
    along side you.

    > Second, of course, the cost per programmer hour is double that
    > of a single programmer. So unless the effetivity is also
    > double, it's not cost effective. And while some people might
    > work faster and better, I've yet to see or hear of anyone who
    > would work twice as fast.

    Work rate isn't the only measure of productivity. Pairs produce code
    with fewer defects so they spend less time debugging and more time
    writing code. From my experience on C++ projects, pairs are typically
    about 1.5 times faster in raw output and produce code with fewer
    defects. I wouldn't have maintained the practice for over two years if
    I hadn't seen real benefits.

    Ian Collins

    [ See for info about ]
    [ comp.lang.c++.moderated. First time posters: Do this! ]
    Ian Collins, Nov 16, 2010
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sean

    Openmore checklist

    sean, Jan 7, 2004, in forum: VHDL
  2. roni
    Eliyahu Goldin
    Jul 17, 2005
  3. www
  4. Francis Glassborow
    Gene Bushuyev
    Nov 25, 2010
  5. Martin Hansen
    Martin Hansen
    May 6, 2010

Share This Page