Richard Kenner <ken...@vlsi1.ultra.nyu.edu> wrote:
>>> I've happened to be looking at a number of other
>>> free-software projects recently (having nothing to
>>> do with compilers) and find the quality of the code
>>> ABSOLUTELY APALLING. The formatting is random and very
>>> hard to read. There are almost no comments. There are
>>> few, if any, indications of what each function is
>>> supposed to do. And many of these projects have no
>>> documentation AT ALL except for some small FAQs or
>>> Wikis.
Michael Witten <mfwit...@gmail.com> wrote:
>> Funny. I've always felt the same way about gcc and most
>> GNU codebases...
>>
>> In fact, I've always felt the same way about the vast
>> majority of codebases that aren't my own :-D
Manuel López-Ibáñez <lopeziba...@gmail.com> wrote:
> Maybe contributing will teach you some team skills and
> style-tolerance? ;-)
>
> I felt a bit silly writing in GNU style at the
> beginning, but you get used to it because it is
> consistent. Now I can switch more easily between
> different styles and I don't feel the urge to rewrite
> everything in my style. I guess is like learning
> different languages.
I can play along fine with different styles (even if I
disagree with most of them); indeed, GNU's style can be
very logical (indenting the braces, for instance, makes
a lot of sense to me---though I don't normally do so).
My main problem is largely with identifier naming and
file/code organization (which *can* involve style via
the use of whitespace). Most people don't put too much
thought into these issues (particularly the matter of
organization), which betrays a lack of appreciation for
abstraction that ultimately taints the design and code
itself.
My rule of thumb: good code is largely self-documenting.
Let me make that statement stronger: If people are
complaining that the documentation for the code is
horrible, then they are essentially complaining that
the code is horrible; it should be trivial:
[0] to find any definition without grepping or
using something like ctags.
[1] to find the highest-level of abstraction
from which to begin a top-down reading.
[2] to understand what any block of code is
doing (this follows from [0] and [1], and
essentially promotes maintaining the proper
level of abstraction for each such block).
Following these ideals basically forces a programmer to
write code as though it is meant to be read and understood
by *others*; that's crucial to being able to work within
a team (especially one distributed around the world).
Unfortunately, the signal usually gets lost in the
noise produced by people who don't care as much, and I
call those noisy people "hackers"; the world is full of
hackers---they are great for the short-term but terrible
for the long term.
Sincerely,
Michael Witten
