JL> It would be good if linux were the most user friendly
JL> possible, but I still think kernel documentation is more
JL> important, by at least two levels of magnitude.
Oh well, you have your opinion, I have mine... if somebody wants to
spend time on it, why not? But as someone pointed out, it should be
as much as possible error free. I don't think the new kernel
developpers would like to second guess the comments.
>> This is a problem. You should be able to read _any_ kind of C
>> code.
JL> Here, we just plain don't agree. I think that if the braces do
JL> not line up vertically, it doesn't make sense. Tabs are too
JL> big; four spaces is enuf. (and don't try to change my mind on
JL> these points; waste of time)
Of course, there must be a minimal set of rules. Unfortunately, there
are many set of rules. Cc-mode (of XEmacs) support by default 6 or 7
different coding styles. I had to create a new one for Linux.
JL> I write in my style... I can read it and so can everyone else.
If you _start_ a project, you can use any style you want. If you
_contribute_ to a project, it usually has a standard style and usually
the developpers agree that contributors should use this style.
Sometimes, the rules are so strict that a patch that does not follow
the standard style of the project won't be integrated. Most of the
time, however, the patch is integrated and a warning is issued.
JL> That's really too bad since it comes under the category of
JL> "that's the way it is"... but I'm not gonna be submitting
JL> diffs anytime soon, as you may have guessed already. I just
JL> have this dream of reading a kernel source file that's more
JL> docs than code (and not just at the top of the file, nor even
JL> just at the top of each function, either.)
A very legitimate goal.
ldd