code review practices 
Author Message
 code review practices

Hi All,
     Not a direct C/C++ question, but indvisible from sucessful C/C++
application development, are there any code review practices popular in
C/C++ folklore? practices which help in churning out a more stable code out?
Any books, URL's would be of great help.

TIA,
Prakash
--



Fri, 10 Sep 2004 13:40:51 GMT  
 code review practices

Quote:
> Any books

"A Discipline for Software Engineering", Watts S Humphrey, Addison Wesley 1995
ISBN 0-201-54610-8 has good stuff on using code review to find defects.

Trevor
--



Sat, 11 Sep 2004 03:13:06 GMT  
 code review practices

Quote:

> Hi All,
>      Not a direct C/C++ question, but indvisible from sucessful C/C++
> application development, are there any code review practices popular in
> C/C++ folklore? practices which help in churning out a more stable code out?
> Any books, URL's would be of great help.

We do code reviews before any check-in to the source-code repository.  The
reviewer reads all new code and also checks diffs against the previous
version.  Check-in messages must indicate who did the code review.  We also
review documentation changes in the same manner.  We have not done any formal
measurements, but we feel that this has been well worth the effort.

- Christopher
--



Sat, 11 Sep 2004 03:13:17 GMT  
 code review practices


Quote:
>> Any books

>"A Discipline for Software Engineering", Watts S Humphrey, Addison Wesley 1995
>ISBN 0-201-54610-8 has good stuff on using code review to find defects.

Yes, and have a look at www.accu.org as we have reviewed several other
books that cover aspects of this.

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm
--



Sat, 11 Sep 2004 12:48:17 GMT  
 code review practices

Quote:


> > Hi All,
> >      Not a direct C/C++ question, but indvisible from sucessful C/C++
> > application development, are there any code review practices popular in
> > C/C++ folklore? practices which help in churning out a more stable code out?
> > Any books, URL's would be of great help.

> We do code reviews before any check-in to the source-code repository.  The
> reviewer reads all new code and also checks diffs against the previous
> version.  Check-in messages must indicate who did the code review.  We also
> review documentation changes in the same manner.  We have not done any formal
> measurements, but we feel that this has been well worth the effort.

Better to create a branch for each task and check-in continuously
to that branch.  That way there is never a lot of pending work
in some developers home directory.

Review code as early as possible, because the longer you wait
the more resistance there will be to changing it.  After the code
has been tested and debugged there's great temptation to live with
a poor implementation.  I think the best code quality results from
test-first development and pair programming; that way the code is
reviewed while it's being typed in.
--



Sat, 11 Sep 2004 12:48:28 GMT  
 code review practices

Quote:

> ... We have not done any formal
> measurements, but we feel that this has been well worth the effort.

In BRL's MUVES project, in an attempt to approach closure on the
software development I organized code review meetings, 90 minutes
twice a week.  Before we had gotten very far, new management took
over and fairly soon shut down the code reviews, after which it
was quite a long time before the product was ready for use..  In
an effort to estimate how many undiscovered bugs remained in the
software, especially since the unit testing before checking modules
into the library was the only remaining quality control, I seeded
a copy of the project code with a handful of "typical" bugs (off-
by-one, omitted case, failure to check function success status, etc.)
then measured how many of these the QC mechanism detected.  By use
of simple statistics I then estimated the number of undiscovered
bugs in the unseeded code.  I would have liked to have compared
the effectiveness of unit testing against code walkthrough w.r.t.
bug finding, but didn't have the opportunity.
--



Sat, 11 Sep 2004 12:48:30 GMT  
 code review practices


Quote:
>> Any books

>"A Discipline for Software Engineering", Watts S Humphrey, Addison Wesley
1995
>ISBN 0-201-54610-8 has good stuff on using code review to find defects.

Yes, and have a look at www.accu.org as we have reviewed several other
books that cover aspects of this.

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm


      [ about comp.lang.c++.moderated. First time posters: do this! ]
--



Sun, 12 Sep 2004 01:30:06 GMT  
 code review practices


Quote:
>> Any books

> "A Discipline for Software Engineering", Watts S Humphrey, Addison Wesley 1995
> ISBN 0-201-54610-8 has good stuff on using code review to find defects.

I can heartily recommend the "Handbook of Walkthroughs, Inspections, and
Technical Reviews", Daniel Freedman and Gerald Weinberg, Dorset House,
ISBN 0-932633-19-6

It contains the whole gamut of review techniques, and explains all the effects
you will start seeing once you start doing code reviews.

Robby
--



Sun, 12 Sep 2004 01:31:29 GMT  
 code review practices

Quote:

> Hi All,
>      Not a direct C/C++ question, but indvisible from sucessful C/C++
> application development, are there any code review practices popular in
> C/C++ folklore? practices which help in churning out a more stable code out?
> Any books, URL's would be of great help.

Code reviews happen in real time using collaborative or pair
programming (http://collaboration.csc.ncsu.edu/laurie/research.htm).
Writing unit tests *before* you write code
(http://extremeprogramming.org/rules/testfirst.html) helps to find
bugs in your design/thought process since you're writing code that
uses your new class/function before you write the class/function.  I
find these methods much more effective than reviewing printed code
"after the fact".
--



Sun, 12 Sep 2004 01:31:44 GMT  
 code review practices

Quote:
>In an effort to estimate how many undiscovered bugs remained in the
>software, especially since the unit testing before checking modules
>into the library was the only remaining quality control, I seeded
>a copy of the project code with a handful of "typical" bugs (off-
>by-one, omitted case, failure to check function success status, etc.)
>then measured how many of these the QC mechanism detected.

If you are allowed to say, what were your results like?


--



Sun, 12 Sep 2004 01:33:58 GMT  
 code review practices

Quote:


> > We do code reviews before any check-in to the source-code repository.  The
> > reviewer reads all new code and also checks diffs against the previous
> > version.  Check-in messages must indicate who did the code review.  We
> > also review documentation changes in the same manner.  We have not done
> > any formal measurements, but we feel that this has been well worth the
> > effort.
> Better to create a branch for each task and check-in continuously
> to that branch.

This does not work well for small tasks.

Quote:
> That way there is never a lot of pending work in some developers home
> directory.

We deal with this by encouraging work to be checked in in stages.  This works
for the most part, but sometimes we do need to do a large code review.

Quote:
> Review code as early as possible, because the longer you wait
> the more resistance there will be to changing it.  

Early review is good, but resistance is mostly a function of your development
culture.

Quote:
> After the code has been tested and debugged there's great temptation to live
> with a poor implementation.  I think the best code quality results from
> test-first development and pair programming; that way the code is reviewed
> while it's being typed in.

Obviously, if you are doing pair-programming, an additional check-in review is
not going to be as beneficial.  However, we don't believe that
pair-programming is the most effective way to use our group's abilities.  We
do pair-programming from time to time and consult with each other many times a
day at other times.  This together with our code review policy works well for
us.

Test-first is good too, when you can do it.  Some features are extremely
difficult to write automated test cases for, and it may not always be worth
the effort to develop those test cases before you do the implementation.  The
other danger with test-first is that the potential cost of having to rewrite
your test-suite can discourage prototyping and refactoring.

- Christopher
--



Sun, 12 Sep 2004 03:27:04 GMT  
 code review practices

Quote:



> > >      Not a direct C/C++ question, but indvisible from sucessful
> > > C/C++ application development, are there any code review
> > > practices popular in C/C++ folklore? practices which help in
> > > churning out a more stable code out?  Any books, URL's would be
> > > of great help.
> > We do code reviews before any check-in to the source-code
> > repository.  The reviewer reads all new code and also checks diffs
> > against the previous version.  Check-in messages must indicate who
> > did the code review.  We also review documentation changes in the
> > same manner.  We have not done any formal measurements, but we
> > feel that this has been well worth the effort.
> Better to create a branch for each task and check-in continuously to
> that branch.  That way there is never a lot of pending work in some
> developers home directory.

Agreed.

Quote:
> Review code as early as possible, because the longer you wait the
> more resistance there will be to changing it.  After the code has
> been tested and debugged there's great temptation to live with a
> poor implementation.

My impression is that the code should be reviewed before it is
linked.  The review should also include a review of the unit tests, in
order to ensure that they are relatively complete.

Quote:
> I think the best code quality results from test-first development
> and pair programming; that way the code is reviewed while it's being
> typed in.

Don't confuse pair programming and code reviews.  For a code review to
be really effective, the reviewer needs a certain distance.  Also, if
the reviewer is present as the programmer types it in, and is
receiving an explination, he is less likely to note that some
important points aren't commented.

I'm tempted to say the same thing about test first -- the (external)
review should take place before the code has been linked.  Which means
before any tests have been run.

--

Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique oriente objet
Ziegelhttenweg 17a, 60598 Frankfurt, Germany, Tl.: +49 (0)69 19 86 27
--



Sun, 12 Sep 2004 12:36:00 GMT  
 code review practices


Quote:
>Yes, and have a look at www.accu.org as we have reviewed several other
>books that cover aspects of this.

And lying on my floor waiting for review is Peer Reviews in Software by
Karl Wiegers (0 201 73485 0) Its worth a look.

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm
--



Sun, 12 Sep 2004 12:36:03 GMT  
 code review practices

Quote:



> > > We do code reviews before any check-in to the source-code repository.  The
> > > reviewer reads all new code and also checks diffs against the previous
> > > version.  Check-in messages must indicate who did the code review.  We
> > > also review documentation changes in the same manner.  We have not done
> > > any formal measurements, but we feel that this has been well worth the
> > > effort.

> > Better to create a branch for each task and check-in continuously
> > to that branch.

> This does not work well for small tasks.

Sorry, I should have qualified this advice.
It depends a lot on the difficulty of creating a branch.
With ClearCase it's fast and easy.  That makes it reasonable
to create a branch for almost every task.

Quote:
> > That way there is never a lot of pending work in some developers home
> > directory.

> We deal with this by encouraging work to be checked in in stages.  This works
> for the most part, but sometimes we do need to do a large code review.

> > Review code as early as possible, because the longer you wait
> > the more resistance there will be to changing it.  

> Early review is good, but resistance is mostly a function of your development
> culture.

I think that in any organization there will be resistance
to refactoring tested code, because doing so incurs an
immediate cost but the benefit is delayed.  If not doing pair-programming
interfaces should be reviewed before they
are implemented, and implementations should be reviewed before
they are tested.

Quote:
> Test-first is good too, when you can do it.  Some features are extremely
> difficult to write automated test cases for, and it may not always be worth
> the effort to develop those test cases before you do the implementation.

Are the test cases going to be developed at all?  If so, then
why not now, rather than later?  I find that I am quite unable to
write code until I know how to test it.
--



Sun, 12 Sep 2004 12:36:06 GMT  
 code review practices

Quote:

> > > We do code reviews before any check-in to the source-code
> > > repository.  The reviewer reads all new code and also checks
> > > diffs against the previous version.  Check-in messages must
> > > indicate who did the code review.  We also review documentation
> > > changes in the same manner.  We have not done any formal
> > > measurements, but we feel that this has been well worth the
> > > effort.

> > Better to create a branch for each task and check-in continuously
> > to that branch.

> This does not work well for small tasks.

Something which seems to me to be reasonable compromise: one can
check-in any code which compiles (and even this rule can be in some
rare cases broken). The review, deep testing, etc happens after
commit. The 'mature' version is marked with the tag/label (whatever
term the version control tool uses) - and this is placing the
tag/label what is somehow restricted. Commit is easy.

'Users' of the code (in contrary to the developers working on it)
usually stick with the labeled version. After new tag is placed they
are notified about it (together with information about the changes)
and move.

It works fairly well when the project is divided into rather small
pieces (libraries and programs).

--
( Marcin Kasperski   | Users typically do not know exactly what they want and )
( http://www.mk.w.pl |  are unable to articulate all that they know. (Parnas) )
(---------------------------------------------------------------------------- )
( Jak kupowa? mieszkanie: http://www.kupmieszkanie.w.pl                       )


      [ about comp.lang.c++.moderated. First time posters: do this! ]
--



Sun, 12 Sep 2004 12:36:17 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Code review practices

2. C/C++ Code Reviews and Automatic Coding Standards and Metrics Tool

3. C#and .NET coding practices

4. OT: HUMOR Klingon Coding Practices

5. Safe coding practices (was Re: Bug in users command)

6. Wanted: List of legal but poor coding practices.

7. Is This Bad Coding Practice?

8. C Coding Practice

9. REVIEW: The C and C++ Review prerelease version

10. Is this acceptable coding practice ?

11. rot13 code review

12. A problem with char** and code review.

 

 
Powered by phpBB® Forum Software