Date: Tue, 22 Apr 2003 12:02:25 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jonathon McKitrick <jcm@FreeBSD-uk.eu.org> Cc: freebsd-chat@freebsd.org Subject: Re: Code layout and debugging time Message-ID: <3EA591C1.AE00376A@mindspring.com> References: <20030422132906.GB64101@dogma.freebsd-uk.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathon McKitrick wrote: > I was just reading an interesting statement in Code Complete: In general "Code Complete" should be taken with a grain of salt; it's very easy to get to "The Process *IS* The Product" by taking any coding standards and practice too far. ISO 9000 is a good example; effectively, all it means is: 1) Document your process 2) Document what you actually do 3) Audit #2 to ensure that it complies with #1 4) Take corrective action, as necessary But the *implementation* most people take away from it has all your programmers socumenting what they are working on, in 10 minute increments. > "Although this particular statistic may be hard to put to work, a study by > Gorla, Benander, and Benander found that the optimal number of blank lines > in a program is about 8 to 16 percent. Above 16 percent, debug time > increases dramatically (1990)." > > Doesn't this seem to contradict the idea that clear, well-formatted code > with lots of blank lines is easier to read and understand? Depends on your definition of "lots". 8-) 8-). > How could debugging be any different? Debugging, in most cases, is not a matter of making the code not give compiler warnings, of having prototypes in scope for everything and its cat, or making the code pass some arcane and arbitrary obstacle course thrown up by a program like "Flexelint"; it's about logic errors. It's pretty obvious that you can have perfectly beautiful looking code, which has logic errors in it. So debugging is about being able to "grok" the code: to be able to understand both its purpose, and how well it's self is aligned with that purpose. So offseting discrete logic blocks that are intended to achive specific goals makes it easier for the programmer to hold in their head both the idea of what the code is intended to do, and what their own logic dictates to them that the code actually does. > As a side note, perhaps it is simply legacy code, but it seems that the > older the source in the BSD tree, the denser it is. Probably to save > punched cards, eh? ;-) Actually, I attribute this to people applying arbitrary standards without being cognizant of their emergent consequences. I also attribute it to older programmers being able to hold more in their head at one time than younger programmers... try coding on a single 80x24 screen some time: you have to hold a lot of lines of code in your head, even if all you are dealing with is a single file. Now consider that tcp_input was originally written on an 80x24 screen. 8-). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EA591C1.AE00376A>