[lkml]   [2004]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Bug zapper? :)
In article <> you wrote:
> I guess it should describe INPUT, OUTPUT, PROCESS, STATE CHANGE, and

You do not need to describe behaviour if the pre-condition is not valid.
This is common asumption in "design by contract". However, this is not good
robust programming, to not handle those pre-condition violations.

> Readable. Don't guess what the code does.

What else is the author of the comment doing? You cant describe all
(important) aspects of a piece of code in a language that is less complex
than the code itself (locking, concurrency, mm, ressouce consumption, ...).
In fact you are very likely introducing errors. Thats why comments are only
needed for navigating you and giving you the overall picture. They are also
good to explain unusual statements (especially in optimized hot path).

> Of course not. The goal I was aiming for was to create an extremely
> structured documentation scheme in the hopes that it would provide a
> great deal of ease in understanding what a function does. "if you don't
> understand what it does, don't fuck with my code"

Well, actually it is good to describe a function at the high level, but dont
go further than that.

eckes privat -
Project Freefire -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.047 / U:7.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site