But moreover it was to forward the idea of a stream of easily digestible
bites, formatted for easy understanding which fix one basic problem.
In my mind a large patch (>100 lines) is a significant rewrite, and ought to
come with regression tests.
I'm not complaining about the comments in the code; in most places it's fine
and helpful. And I'm certainly not advocating idiot comments (int i=0; //make
and integer "i" and set it to 0). But I have looked at some sections of the
code, and to my untrained eye the purpose of the code was obvious, and in
other places was not. The more obvious the code is, the faster Linus or anyone
else can evaluate it and either make corrections or accept it.
Otherwise, the reviewer must slog through, and hope they have a clear picture
of what's going on while they simultaneously try to figure out whether that's
what *should* happen.
This process serves to make the code superbly maintainable , and therefore
much more likely to be stable as well as be extendable.
I dare say Linus probably suffers from the afflic... desire to understand.
To look at some code, and be able to test it by running it on a few cases is
not enough, because if you don't truly understand it, you go away with this
nasty feeling that you are missing something. And often you are. I recall a
funny problem a long time ago where an algorithm worked beautifully most of
the time, but failed miserably of the buffer than it was looking at was
exactly 1023 bytes. It turned out that some added an alignment patch that
added *2* bytes to this, which tossed it over the line in page-faultsville.
Apparently the programmer thought a short=8 bits.
Anyway, enough rambling.
-- Hacksaw = David Charles Todd GTEI-BBNT = Hacksaw's Employer Hacksaw's Opinions != GTEI-BBNT's Opinions Linux understands you.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/