|
It is vitally important to agree on design/coding parameters early
on in a project. Some people believe that as long as
everyone documents decently, that's enough, but I
disagree, especially on coding standards, which are not
the same as layout standards. Coding standards
include naming, use of various flow structures and rules
of what's important.
Standards are important for many reasons, but I would
argue that the most important is their overall effect on
quality, but not for the reasons one might think.
Yes, everyone using a standard is key to review and
maintenance, but more importantly, it forces developers to
"think" about quality all the time. My
favorite example is the use of braces in C++ for single
line instructions following a decision, as in:
if (customer_level == 4)
abort_flag = true;
My problem with this is that adding a second line to
the instructions after the IF alter the program flow, as
in:
if (customer_level == 4)
printf ("Customer has died; we are
aborting.\n");
abort_flag = true;
Note how the flow has changed and the program will no
longer abort. Yes, experienced programmers should
check for this, but philosophically, this is a very bad
practice that can induce errors. Any practice which
can induce errors should be proactively stamped out, not
only to reduce those types of errors, but because it
instills the notion that only perfect coding practices are
acceptable. The proper style is, of course, the
following. Always use tools like lint or CodeCheck
to insure compliance with this rule.
if (customer_level == 4) {
abort_flag = true;
}
Beyond simple formatting and flow issues, teams should
talk about defensive
programming, how/when to check stuff, use of pointers,
encapsulating things, maybe some memory issues, very
aggressive use of asserts, checking return codes, use of
exceptions, etc.
Again, discussions should make clear that the process of doing
these things and the thinking that goes into it are really
the main goals, not necessarily things like the asserts
themselves.
I've seen compilers taken away from people, making them
send code to QA for compiling; this actually produces vastly
superior code as it's like the old days with punch cards;
you really, really think about your design and code; don't
worry, I won't be advocating taking away of compilers, but
this is the general mindset necessary to write very high
quality code.
See the separate standards pages for some ideas on
things to do in various languages, including C++, Visual
Basic, and Java.
|
|
