On Sat, 12 Jul 2003 09:01:11 +0200, "Lidor Wyssocky"
>> > Thus, the article suggest formal code reviews.
>> Seems like a good idea but in twenty years I've never seen it done.
>The fact that it isn't common, doesn't suggest it is not necessary....
It _does_ suggest that it is not _necessary_, although it may well be
a good idea. I was just about to start such a procedure, on a project
I was on a year or so ago, because too many people were turning in
crap, and I wanted a social mechanism to focus their attention on
quality. But that's code review as an instructional and social trick,
not technical. Plus, it never happened -- project was, um, reorganized
preparatory to cancellation.
>> My favorite approaches to code verification include assertions,
>> invariants, and extensive error handling. And coding conventions and
>> design rules. Only somewhere south of that do we get to formal code
>> reviews, and somewhere south of THAT do we find formal proofs of
>I never claimed functionality is not the first thing that should be
>verified. I merely suggest it is not enough.
I agree that more can and should be done, as I say above.
Quote:>When you work alone it might be good enough. But the code you write today
>will have to be maintained by others, don't you want to be sure those other
>won't have a hard time dealing with? Who gets to ensure that every developer
>involved in the product indeed used the coding standards? Who gets to verify
>that the correct design rules were applied? Functional tests can't do that!
If it passes the functional tests, I'm willing to let the next guy in
to do maintenance, note of the code was written to spec. That, and a
few informal inspections by the project lead, are enough to turn up
problems before they go very far.
Quote:>Didn't you ever had to maintain a piece of code you didn't write and just
>knew that no one apart from the person who wrote it ever checked how this
>code was written (and even this person himself won't easily understand this
I've seen it all.
Quote:>Now, some people will say: if you are a good developer there is no code you
>can't eventually follow and understand. That might be true, but why making
>life harder than it is? Why take a chance of missing something in the code?
>Wouldn't it be easier to verify that the code is clean, clear,
>understandable and well designed *before* releasing the product? (In
>addition to functional tests of course...)
If all a code review does is check adherence to standards, it is not
worth the time to get an entire group together. If it has to actually
review the logic in detail, it is far too slow a process. 90%+ of code
is just cloning a skeleton and filling in details, there shouldn't
really be anything to review. The other 10% tends to be one-time
code, and the purpose of the review should be to look for gross
errors, not fine points. And review is very expensive. Yeah, errors
are even more expensive, I know, but the temptation to skip the
process and get lucky, is obviously very strong.
Hey, I just about convinced myself of something here, sorry if it's in
the opposite direction you were trying to go.