Dealing with pointer freaks

Richard A. O'Keefe ok at goanna.cs.rmit.oz.au
Mon Jun 24 18:17:05 AEST 1991


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.

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

> We argue that when he gets out into the Real World
> he'll be screwed -- and he says he'll deal with that later.

I have bad news for you:  he is acting rationally.  Right now, it is more
useful to him to get his programs working (which means using a style _he_
can understand) than to earn your approval.  Leave him alone.

> So what can we do?  How can we convince him of the error of his ways?

Leave him alone.  If he comes to you and says "can you help me find this
mistake?" tell him "no, I can't read the code you write.  Rewrite it so
that I can read it, and then I'll help."

> PS- Can someone mail me an ftp site for the Indian Hill style guide?

Don't bother.  There are _some_ experiemental results in the psychology
of programming.  Some of the things the Indian Hill style guide
recommends are known to be very bad ideas.  Buy a copy of

	Professional Software
	Henry Ledgard with John Tauer
	Vol 1: Software Engineering Concepts ISBN 0-201-12231-6
	Vol 2: Programming Practice ISBN 0-201-12232-4 <-- this is the one

You particularly want to read Chapter 8 of Vol 2 (get both volumes, they
are US$20 each).

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).
-- 
I agree with Jim Giles about many of the deficiencies of present UNIX.



More information about the Comp.lang.c mailing list