lkml.org 
[lkml]   [1997]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Take A deep Breath - Kernel Documentation
: No, they chew them out because they get lots of flack from other
: programmers, and they discover that it takes 6 months for new
: programmers to start doing useful work on the project. Programmers do

Good, that means i have 4.5 more months before I'm expected to do
anything at work.. :)

: problems himself without others pointing them out. And the problems
: will crop up in ever code review, everytime the programmer takes a
: vacation, etc.

Code reviews are very nice tools. However, in the Linux kernel, if it
compiles and mostly runs, its "good." In addition so many people look
at patches when released that formal reviews of code are unnecessary,
even though they might be a nice idea.

: > Basically, the kernel is just fine, and the programming methodology is
: > *effective*. Either demontrate some large gains in productivity from such
: > commenting... Or drop the topic ;)

If some developers (both old and completely new) would take the time to
track the time they spend doing a kernel "hack," we could try to find
out how much time the average developer spends attempting to understand
existing code versus the number of comments in the source code. From
this we might be able to demonstrate SOMETHING... if that doesnt work,
having time metrics would be a very interesting, although useless,
piece of information.

: Yeah, but is it maintainable if the developers go away? The problem
: with your argument here is that it's a selfish one - the developer
: himself may be productive, and if he's selfish, that's all he cares
: about.

Finally, someone agrees with me.

: The unselfish approach is to think about others who have to
: deal with the code. Even when I look at my own code, it can be
: baffling several months later without the comments. I have experience
: with myself gaining productivity by looking at comments in my own
: code, and I've lost productivity when I've asked coworkers what a
: particular piece of code does and they couldn't remember. It helps
: me pick up my train of thought when I start working the next day
: or come back from lunch. That's all the "demonstration" I have, but
: I'm sure others have similar experiences.

"But Blow Joe developer is SO smart he only spends 2 minutes reading all
of the VFS code, and he understands it perfectly. So, why would he want
comments." Sorry, just couldnt resist. This is stuff people have been
emailing me (exagerated, of course).

: The big problem is that I think many programmers do not learn to
: comment, or learn that it's something you do just before you turn in
: an assignment. They never get into the habit. Myself, I can put in a
: comment while sitting thinking "hmm" between bursts of typing. (and I
: find it helps me write better code, since I have to be thinking

True. My professors didn't start requiring any type of documentation with
code (other than simple file headers) until midway through my junior
year in college. Times are changing, but there are a lot of developers
who don't see the benefits of comments.

I am sometimes even stupid (?) enough to include copious comments
little perl scripts I write. :)

: coherently about what the code does to write a comment) It takes
: very little time, more time is wasted trying to defend why one
: shouldn't have to comment.

So true..

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2011 Jasper Spaans