Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 12 Jan 2003 23:36:13 +0100 (CET) | Subject | Re: any chance of 2.6.0-test*? | From | "Emiliano Gabrielli" <> |
| |
<quote who="Rob Wilkens"> > On Sun, 2003-01-12 at 16:59, Adam Kropelin wrote: >> Congratulations. You've possibly increased the speed of an error path by an >> infintessimal amount at the expense of increasing the size of kernel image and >> making the code harder to read and maintain. (I say "possibly" since with caching >> effects you may have actually slowed the code down.) > > Hey, if the compiler does it's job right, I increased the speed of something in the > kernel. And, as a kernel newbie, I'm proud of that. I also did it in under 12 > minutes (from time stamp of message received to time stamp of message sent after code > compiled and diff'd). > >> Harder to read: The primary code path is polluted with repetative code that has no >> bearing on its primary mission. > > I thought it was easier to read. For me, I can read "ok, this condition happens, I > fail"... Or "if this other condition happens, I release my path, then I fail"... > > Whereas the "goto out" was very unclear. It made me page down to figure out what was > going on. > > That's the whole point.. To just browse the code.. I shouldn't have to page down to > understand what the code right in front of me is doing. "goto out" is unclear. > "retun error" is clear. "path_release" seems like a relatively plain english function > name and I can guess what it does without knowing exactly what it does.
goto out_path_release is finer to you ?!? :)
> I can also > surmise that if I go beyond a certain point in the function that I need to > path_release() the same way a non-kernel programmer might need to free memory > allocated inside of a function before returning to the calling function. > > It really is that simple. > >> Harder to maintain: Add an extra resource allocation near the top and now you have >> to hunt out every failure case and manually update them all (with yet more duplicate >> code) instead of just amending the cleanup code at the end of the function. > > It took me 12 minutes from message received to message sent to update the entire block > of code to handle the new case. How long do you think it would take to make a minor > modification that would only have to do a portion of what I did? Is it such a burden > on the developer to make the code more readable? >
I think you have no idea of the mole of the linux kernel and the number of daily patches the mantainers receive ...
I'm also a beginner, and me too at the very first time hated the goto (every one have told me they are evil !!) but after aving taken a look at the kernel and reading LinuxDevice Driver I think that the style the linux kernel is coded is cryptic for beginners, but it is perfect !
It is a wonderful experience to browse the linux kernel sources .. and every time I didn't understand why a thing was done in such a way .. well I discover later (with experience) that it was done in the best way it could ever be done !!!
-- Emiliano Gabrielli
dip. di Fisica 2° Università di Roma "Tor Vergata"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |