[Chicago] code review tools

[sheila miguez]

On 7/24/07, Brian Ray <bray at sent.com> wrote:
>
> On Jul 23, 2007, at 10:30 PM, Tim Ottinger wrote:
>
> > How about pair programming? It's a very nice tool that makes
> > reviews almost transparent. :-)
> > Not even 1/2 kidding.
>
> What defines a code review tool.  In Mondrian's case, it could be
> done with parallel programming. But even though you are looking at
> DIFF from a pre-commit (facilitated from Perforce), the review is not
> simultaneous.
>
> In the case of simultaneous parallel programming code review, Adium
> could be considered a code review tool.  Not so long ago we used GNU
> Screen to connect a team of people to a single session to do code
> review through VIM or Emacs (its politically correct to mention them
> both, but it was VIM I was really using at the time).

Has anyone seen papers with a two-factor analysis on it? varying the
conditions of pair/non-pair and review/non-review.

(or have anecodotal accounts?)

I don't trust someone's serious snarky comment that pair-programming
supplants code reviews.

> Although, when I first thought of code review, I was thinking of some
> automatic code review like a LINT or analyzer.

I was not.

> It would help if we could define the requirements of the code review
> prior to recommending tools.

Don't you guys do code reviews?

I'm talking anywhere from incredibly formal Fagen types of things to
light-weight asynchronous things. Do I need to define this?


-- 
sheila