Re: Debian coding style?
In article <[🔎] m10gZVz-0006IrC@vanzandt.mv.com>,
James R. Van Zandt <jrv@vanzandt.mv.com> wrote:
>Stephen Zander <gibreel@pobox.com> writes:
>> >> Remember that the person who is most qualified to test any
>> >> piece of code is the person who wrote it.
>> Wichert> I can argue about that. But I won't :)
>>The person who wrote the code is almost always the *least* qualified
>>person to test it.
>
>Thorough testing needs several viewpoints. The original programmer
>may be the best one to single-step through the code, checking for
>things that differ from his expectations, or things which could
>cause trouble given other data.
I think that that testing isn't really about style. Style implies
ways to present your code to other _human_ developers who have to
read it. The C compiler doesn't care how you indent 'if' statements
or where you put spaces around expressions. Consistent indentation
helps the programmer-to-programmer process but does nothing for the
programmer-to-compiler process. Any coding convention that can be
expressed as a syntactically-equivalent algorithmic transformation of
any other coding convention is probably an element of style. Testing
(and quality assurance in general) is a matter of good overall technique
and using effective day-to-day procedures.
A typical corporation develops common internal procedures to increase its
efficiency, but at the same time the initial skill and experience sets of
employees sometimes differ wildly (my experience has shown much greater
variation between employees in a corporation than active developers on
an open-source project, IMHO because the latter group selects itself).
In order for a corporation to work, its new employees have to be trained
in existing procedures, and the shortest path to achieving that goal is
to make everyone start life by reading a common text that contains the
basic knowledge necessary to function in the group.
In a software shop, that common text tends to be the best known document
available among the developers -- which often starts life as a coding
style document. The role of this text gets expanded to include some of
everything else a new employee needs to know, and it relies on knowledge
that anyone who was not part of the corporation wouldn't necessarily have.
We've seen this here: some Debian developers have never _seen_
Hungarian notation until three days ago, but most of Corel's developers
have fingers that type "lpsz" without requiring conscious thought from
nearly a decade of practice. On the other hand, some Corel developers
are likely to have a really hard time setting their tab stops back to
8 characters for the first time in as many as 10 years, and anyone who
has to work on both Corel and non-Corel code is going to be screaming
epithets near release deadlines. I guarantee it.
Open-source projects have less in common, and as such they have documents
targeted toward different audiences. Part of the problem with the
original set of alleged "Corel Linux" guidelines, aside from some of
its contents, was that it was a witches' brew of elements of style,
technique, and procedure, with not enough of any of those and too much
of all of them.
By contrast, the "GNU Coding Standards" is a full standards document that
has style mostly separated from the technical and procedural stuff.
While opinions vary about the technical content, the GNU document itself
is a well organized collection of English text. All the words seem to be
spelled correctly and except for the 'info' link syntax well-punctuated
too. The much shorter "Linux Kernel coding style" document discusses
_only_ style: indentation, placing braces, naming, function length,
commenting, and using tools to adjust existing code to the correct style.
It doesn't suggest any particular coding or testing techniques at all.
Other Linux documents describe procedures (e.g. how to prepare and
submit a patch) and technique (although defining coding technique in
a kernel is always approximate at best, and sometimes actually varies
by architecture).
--
Zygo Blaxell, Linux Engineer, Corel Corporation. zygob@corel.ca (work) or
zblaxell@furryterror.org (play). Corel may disagree with my opinion (above).
Size of 'diff -Nurw [...] winehq corel' as of Mon May 10 17:14:00 EDT 1999
Lines/files: In 54144 / 292, Out 16700 / 154, Both 48717 / 329
Reply to: