From owner-freebsd-chat@FreeBSD.ORG Tue Apr 22 12:07:41 2003 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FAA337B405 for ; Tue, 22 Apr 2003 12:07:41 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EECF43FE9 for ; Tue, 22 Apr 2003 12:07:41 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0258.cvx40-bradley.dialup.earthlink.net ([216.244.43.3] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19833S-00053A-00; Tue, 22 Apr 2003 12:03:47 -0700 Message-ID: <3EA591C1.AE00376A@mindspring.com> Date: Tue, 22 Apr 2003 12:02:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathon McKitrick References: <20030422132906.GB64101@dogma.freebsd-uk.eu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e8a0c788e9771a9736b7d32bed2359d4667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: freebsd-chat@freebsd.org Subject: Re: Code layout and debugging time X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 19:07:42 -0000 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