Dealing with pointer freaks

[Kelly J. Grant]

In article <6470 at goanna.cs.rmit.oz.au>, ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> In article <MIKEG.91Jun22125223 at c3.c3.lanl.gov>, mikeg at c3.c3.lanl.gov (M. P. Gerlek (hack grad student)) writes:
> > I have this officemate ... who considers himself a competent C programmer,
> > but insists on writing what most of us consider very bad code.
> 
> Be clear about what you mean by "bad".  From the sound of it, what he writes
> is correct.  You find it _ugly_, but then things written with an indentation
> level of 8 or 2 (anything outside the range 3..5, in fact) look ugly to me,
> and so do macro names written in capitals, and you'll find both of those
> recommended by people who should know better.

I disagree.  Just because code works does not mean it is not bad code. 
>From an academician's perspective, I suppose ugly code is reasonable
since most code written there is personal use or project related.  When
you start talking about code written commercially (ie., someone is
paying you, not necessarily a commercial product) you change the rules
drastically.  It is *NOT* your code.  Yes, you wrote it, but you don't
own it, and you won't be around for questions when someone else has
to deal with it later.  I'm not saying you need to write to the lowest
common denominator [might as well write Pascal :-)], but your code must
be intelligible.

I know how much we all hate maintenance, but the reality of life is that
source code will generally outlive our memory of how it works. Your code
should be of a style you can pick it up 6 months or a year later and 
still understand what it is doing.

> 
> > No kidding, he writes ... *(x+i) ... [instead of] ... x[i] ...
> 
> > The problem: the code he's writing probably won't be used by anyone
> > but him, so he sees no need to try and conform to anything
> > "conventional".
> 
> If the code he's writing won't be used by anyone but him, what business
> of yours is it _what_ his code looks like?  Is teaching him your style
> part of your terms of employment?  Did he _ask_ for your help?

Code written in a shop *should* conform more or less to a certain style
(whatever the style may be).  This is especially true for a project
where one person is working alone.  In this situation, if the person
doing the project can't finish for some reason, then someone else is
going to have to come in and pick up the ball.  If the person's code is
written in an "unintelligible" style, then more money will be lost by
the second person either having to waste time trying to read the code,
or having to rewrite it.

[ lots of stuff about "how can we change him", "leave him alone" deleted ]

> By the way, before you try to take the speck of dust out of your
> office mate's eye, what are _your_ *naming* conventions like?  The
> choice of names is much more important than whether you use
> x!i (the way it was done in BCPL), *(x+i) (BCPL-compatible), or
> x[i] (a bit risky, as x[i,j] doesn't mean what you expect).

It doesn't matter what your naming conventions are, except it is important
to have them, and to use them religiously.  We all have the things we believe
in (indenting, capitalization, etc..), and will argue about, but consistency
is the most important.

I disagree that names are more important.  Naming conventions can be
annoying, but they do not take a lot of gray matter to determine function.

Just my $.02 worth...

Kelly

-- 
Kelly Grant        grantk at manta.nosc.mil   (619) 225-2508
Computer Sciences Corp          ^^^^^^^^ Important: manta.UUCP won't get to me
4045 Hancock Street      "If you are given lemons.....see if you can trade for
San Diego, CA 92110       chocolate" - me