NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/5028

Text File | 1992-12-17 | 3.9 KB | 75 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!ncar!csn!raven!rcd
From: [e-mail] (Dick Dunn)
Subject: Re: C code Layout
Message-ID: <[e-mail]>
Organization: eklektix - Boulder, Colorado
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 17 Dec 1992 08:14:51 GMT
Lines: 64

Charlie is pretty good at finding the vulnerable spots in my arguments!
But I enjoy the spirit of the discussion...

[e-mail] (Charles R. Martin) writes:
>[e-mail] (Dick Dunn) writes:
>   >[e-mail] (Lee Derbenwick) writes:
>   >|> One reason that I personally dislike very large comments embedded in
>   >|> the code is that they greatly reduce the amount of code within my
>   >|> visual field (whether on a screen or on paper):...
...
>   [ref another discussion] ...But it's a good point in any case...

>But then ... it was just one news item ago that you were enjoining us to
>get tools that suit the job rather than perverting the work to suit the
>tool.  Doesn't that apply to 25-character screens as well?

Yes, I still say "get better tools", and that certainly applies to screen
size.  But who's talking about 25-line screens?  I'm writing this on a
25x80 right now, but I don't do serious code here (nor after this much
brandy:-).  At work I've normally got a 64x80 and a 54x80 side-by-side
(which is what fits with some elbow room for a couple of status-related
things plus enough room to find other windows and yank on them).

Responding to an earlier example, I had noted a seven-line comment+code
item as taking up 10% of the screen space...there, I was thinking of a
page-sized screen window (~ 70 lines, not 25).

Take a second look at what Lee Derbenwick said--it's the amount of code
within the visual field.  Beyond some point, increasing the amount of
"stuff" on the screen doesn't increase what you can take in.  Once you get
a certain amount, it's not the physical screen limit so much as the eye/
brain limit.  Back to Scott McGregor's notes on chunking.

>I'm actually serious -- an acquaintance seriously noted that getting
>full-page screens for their terminals improve productivity substantially
>on a big project, just because it allowed holding a whole function in
>one screenful.

I believe it!  I've had displays with about the equivalent of a full page
of text for several years, and I'm convinced it's made me not only more
productive but less likely to make mistakes.  Given how little it costs
(compared to the burdened cost of programmer time), it's foolish not to buy
into it.

Seems to me there's more than passing significance to the average size of a
page of text.  The amount of text on one printed page, for common books,
fits within a surprisingly narrow range.  (Newspapers deviate by a lot, but
(a) they're constrained by lack of binding and (b) one page contains
multiple items; you don't expect to find a story covering an entire page.
If you look at the size of a story, or the fraction before continuation on
another page, you come up with an amount in the same range as a book page.)
I think we can push our displays up to the equivalent of a large page of
text, with continuing improvement in the understanding it gives us, but the
returns will start to drop off rapidly after that.  I've played with large
listings, by using an 11x17 printer and relatively small type...other
things really get in the way before you can use the length of the page.

The point of that long ramble is that if you've got code with lots of
detailed comments, you can push past a hardware barrier to displaying it,
but you'll still run into eye/brain limits.  THOSE limits--our mental and
physiological limits--we have to take into account when writing code.
--
Dick Dunn    [e-mail]   -or-   raven!rcd    Boulder, Colorado USA
   ...Mr. Natural says, "Use the right tool for the job."