Re: automated coding standard validation?

Ian Collins <ian-news@xxxxxxxxxxx> wrote:
Michael Mair wrote:
Ian Collins schrieb:
.....
An XP team doesn't wast any time on code reviews, the practices
(collective code ownership and pair programming) take care of them.


Please use only C related or standard usenet abbreviations.

I assume that you are talking about eXtreme Programming.
As there are no reliable statistics or universal / general
experiences that say "'XP' is always better than the good old
way (whatever this may be, with or without code reviews)", let
us not waste time with an off-topic debate which has nothing
to do with te OP's request.

<OT>
I have never worked on projects using "extreme programming"
techniques, so my opinions are based only on readings on the subject
and other people reports.

Based on my inexperience, I don't accept the premise that pair
programming will have a significant impact on the quality of the code
produced. I can see that "four eyes are better than two" on spotting
logic errors, but I also believe that two people working together may
influence each other into making the same mistakes, and/or the code
may reflect compromises done to keep harmony in the team as opposed to
reflecting what each member though is the best solution for a problem.

A formal code review brings people with more of an "outsider" point
of view, more detachment and more impartiality.

Also there are projects or situations, especially in embedded systems,
(especially in *large* embedded systems,) were the extreme programming
principles of making frequent releases and involving customer feedback
are just impossible to follow. (The hardware does not exist yet, the
custom building were the hardware will be installed is not complete
yet, the wiring required to run a system simulation will be installed
2 months after the building is complete, and the customer will not
provide the 150 workers for half a day required to run a simulation
anyhow, except for a few pre-defined acceptance tests at project
milestones, determined when the contract was signed.
All this from a *real* project.)
</OT>

I was simply trying to point out there are often (but not always)
process techniques that can replace tools.

Process and tools should complement each other, but for the type of
validation I was referring to in my previous post, (syntax and naming
conventions believed to reduce the possibility of making mistakes) I
have no doubt that tools should take precedence.
Isn't "automate, automate, automate" one of the extreme programming
mottos?

With regards to the coding rule you called 'daft': ("Identifiers will
not differ by: ... The interchange of the letter 'I', with the number
'1' or the letter 'l')

1 int *port11;
2 int *port1l;
3 int *port1I;
4 int *portII;
5 int *portlI;

All this declarations are different yet, with the font my newsreader
is using, I can not tell the difference between lines 4 and 5. That
rule eliminates a potential source of errors that COULD NOT BE
DETECTED by visual inspection.
I would call it a life saver...
.

Relevant Pages

  • Re: automated coding standard validation?
    ... I assume that you are talking about eXtreme Programming. ... A formal code review brings people with more of an "outsider" point ... I have done lots of pair programming. ...
    (comp.lang.c)
  • Who Is Just Not Getting It?
    ... I was skimming the contents of Yahoošs Extreme Programming ... I came across a posting from Kay Pentecost ... As one example, pick up a copy of Beck's first book, look ...
    (comp.object)
  • Re: print LIST vs print join "", LIST
    ... sorry:) Extreme Programming didn't come to mind. ... when I say "die late" i don't mean to return an incomplete ... the class diagram I came up with did impress mostly everyone. ...
    (comp.lang.perl.misc)
  • Re: dynamic type checking - a pauline conversion?
    ... and rabid enforcer of strong typing. ... >> Four years ago I got involved with Extreme Programming. ... Here is problem with static types: ...
    (comp.object)
  • Re: eXtreme Programming work - Including pair programmin
    ... >> eXtreme Programming with pair programming. ... better spent on another project or particularly formally testing the ...
    (uk.consultants)
Loading