[Courses] Style (was Lesson Three: Basic Declarations&Expressions)

[Julie]

"Daniel." wrote:
> 
> >In practice this does not work.  The number of bugs I've encountered
> >over the years because someone decided to do their own thing, even
> >just an edit here and an edit there, is non-small.
> 
> I'm not sure we're talking about the same thing. I was essentially
> agreeing with Jenn's point from a previous post:
> 
> >In a larger project - that's what programs like indent are for. Use
> >them. Let people develop the code their own way, and use a prettifier
> >before release.
> 
> which seemed in danger of being shuffled aside. I approached it from
> a slightly different angle (i.e., "positioning whitespace according
> to a company standard is a job for a machine, not something you want
> to distract humans with").

Oh, okay.  I'd missed her remarks, which I'll also disagree with,
unless she's saying something other than what you're paraphrasing
her to say.

"Style" is more than just whitespace or bracket position.  I'd say
it is a collection of things which convey information about the
structure and organization of a program and the nature of it's
components.  "Style" isn't just "some whitespace goes here".  Style
should convey the flow of code -- that's what most people seem to be
doing with indentation rules at least.

	if (a > b)
		something to do with a
	else
		something to do with b

Yet style can also (and often does) include information about the
variables in a program

	int	*valuep;
	char	letter;

where the "p" on the end of "valuep" is used by the programmer to
denote that "valuep" is a pointer to a "value" and "letter" means
that, sans trailing "p", it is just a letter.  My girlfriend is
learning Visual Basic and they use "txt" before text box objects,
"lbl" before label objects, "cmd" before command buttons, and so
on.  That is also "style".

Style also includes the way comments are added, how much comment
text, how it is formated, etc.; how functions (and macros!) are
named, defined and implemented (ex: return values, capitalization,
parameter declarations); how typedefs are used and defined (ex:
use of a trailing "_t" to indicate a typedef being a common
convention); the use of header files, how named and where located
and a bazillion other things.

You'd really be surprised how =bad= code can get when someone has
their own ideas about "style".  For example, this code fragment
is from the 7th Edition UNIX Bourne shell, and it is the classic
example of "Style" gone =very= awry --

LOCAL STRING *  copyargs(from, n)
        STRING          from[];
{
        REG STRING *    np=alloc(sizeof(STRING*)*n+3*BYTESPERWORD);
        REG STRING *    fp=from;
        REG STRING *    pp=np;

        np->doluse=1;   /* use count */
        np=np->dolarg;
        dolv=np;

        WHILE n--
        DO *np++ = make(*fp++) OD
        *np++ = ENDARGS;
        return(pp);
}

On a project where everyone else is writing code like this
snip from "clri" --

isnumber(s)
char *s;
{
        register c;

        while(c = *s++)
                if(c < '0' || c > '9')
                        return(0);
        return(1);
}

what do you think the odds are that people are going to think
Bourne is "weird", even if someone could put all the right
amounts of whitespace into all the same places?

My point, by the way, is not that Bourne was a bad programmer,
rather that of the ~156,000 source lines of text in /usr/src/cmd
on 7th Edition UNIX, only the Bourne shell is coded like that.
-- 
Julianne Frances Haugh             Life is either a daring adventure
txjulie at austin.rr.com                  or nothing at all.
					    -- Helen Keller