Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: How should I do (and document) effective semi-formal code review?

by eyepopslikeamosquito (Canon)
on Jun 18, 2008 at 22:09 UTC ( #692810=note: print w/ replies, xml ) Need Help??


in reply to How should I do (and document) effective semi-formal code review?

I've been in charge of code reviews at work for about six months now. A few random points:

  • Before the code review, the code should be pushed through Perl::Tidy and Perl::Critic according to your internal coding standards. This avoids wasting time arguing about code layout and basic style issues. If you find things in a code review that were not detected by Perl::Critic, see if you can tweak your Perl::Critic policies to find them next time.
  • The code review must be in writing. Otherwise, there is no proof it has been performed.
  • Most of the code review work should be done before the code review meeting.
  • Have at least two code reviewers.
  • Take a look a Fagan Inspections. Though probably more formal than you want, you should get some good code review ideas from this well-respected method.

According to Karl Wiegers, the Seven Deadly Sins of Software Reviews are:

  • Participants don't understand the review process.
  • Reviewers critique the producer, not the product.
  • Reviews are not planned.
  • Review meetings drift into problem-solving.
  • Reviewers are not prepared.
  • The wrong people participate.
  • Reviewers focus on style, not substance.

Some useful code review links:

Updated 23-June: Added "Seven Deadly Sins of Software Reviews" and associated links.


Comment on Re: How should I do (and document) effective semi-formal code review?
[OT] Ignoring perltidy changes in sv[nk] annotate
by bsb (Priest) on Jun 21, 2008 at 02:05 UTC

    It's a bit off-topic, but I'd like to know if there's a way to make perltidy alterations transparent to "annotate" in svn/svk. Both support a white-space ignoring mode, but there might be better solutions. Anyone know of one?

    I'm thinking of adding a property to perltidy commits, or maybe reformatting commits in general, then I'd need to find or build an annotate that could ignore it. (Although "ignore" is perhaps not correct, the annotations before this change need to make it over in some sensible way).

    See SVK::Command::Annotate, SVN::Web::Blame

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://692810]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (14)
As of 2014-10-20 18:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (86 votes), past polls