From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: C code Layout
Keywords: C code layout
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 17 Dec 1992 01:26:50 GMT

In article <MARTINC.92Dec16111734@hatteras.cs.unc.edu> martinc@hatteras.cs.unc.edu (Charles R. Martin) writes:

>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?
>
>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.

Indeed it does apply to these other issues.  It also applies to
whether our programming languages should use color and fonts to give
us additional degrees of freedom to convey more information in the
same visual area.  It argues not just for full page screens, but for
larger displays and even large desktops and tables and whiteboards in
programmer's offices. 

Clearly this stream takes the syntax of a language, C in this case, as
a given.  Should we do this so quickly? What might result from other
changes to the language (such as fonts and text styles--literate
programming style, or schematic representations). Is a macro that
compresses 24 lines into one small statement good or bad? etc.

Even assuming that we want C as ONE representation, do we want it to
be the ONLY one?  Or might we benefit like architects by being able to
see several equivalent but visually distinct representations. I think
we might. Here's a short description of a past experience that
suggests it might:

About two years ago I was managing a team of developers working on a
complex object oriented system of over one million lines, written in
C (not C++, that's a different story). A few subroutines and macros
provided the basic object message dispatching, but coding the messages
in this way was very "long winded", and even simple programs to check
files out of the repository, edit them and check them back in took
over 25 pages. 

One of my engineers, Joshua Levy, came up with an innovative way to
read these object message, method and instance variable definitions
and turn them into schematic representations. These schematic
representations were relatively more compact (especially, they used
the horizontal axis more effectively) in many cases, and the
cognitive overhead of understanding them was often much less.  This
allowed programmers to often get an instant understanding of
situations that before had appeared very complex. We even identified a
few old, long standing bugs in the C code, that screamed out at us in
the schematic representation. One was so glaring that we thought we
had a problem in our schematic generator, since the programmer who
wrote the strange looking code claimed that the implications of the
code were impossible and not even worth a first glance. The second
glance showed that "the impossible" had indeed happened. We later
worked on a program that went the other way, converting the schematic
into the equivalent C code.  (It is hard to describe the scehcmatic
form here where I can't draw pictures, but people who have seen
TGS's ProGraph will have a clue).  One obvious lesson from this is
that two llanguage representations can be mathematically equivalent
but from a cognitive performance view very different.

Nathaniel Borenstein wrote a book called "Programming as if People
Mattered", which is an expression that I have been using for years.
For reasons I can't explain, we often seem to forget that we
programmers are people too, and subject to the same cognitive
limitations as other people.  Just as ignoring people factors can lead
to disaster in our products, our failure to pay attention to this
issue as it applies to ourselves causes great damage as well.






-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.