This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why not contribute? (to GCC)

> My rule of thumb: good code is largely self-documenting.

Maybe.  But good code can't give the SPECIFICATIONS of a function,
just it's implementation.  I don't believe there's any substitute
for putting comments in front of a function to say what the function
is SUPPOSED to do.  That's only in the mind of the writer and needs
to be written down.

Also, an important thing to put in comments is WHY something is done
the way it is and (more importantly) why it ISN'T done another way.
No amount of good quality code can contain that information.

>     [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).

You need to understand, what a block of code is doing, what it's supposed
to do, and why it's doing it.  In some cases, the latter two parts are
obvious, but when they're not, there's no substitute for proper comments.

> 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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]