[lkml]   [1997]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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    [W:0.020 / U:7.520 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site