Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!munnari.oz.au!bruce!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: Dealing with pointer freaks Message-ID: <6470@goanna.cs.rmit.oz.au> Date: 24 Jun 91 08:17:05 GMT Article-I.D.: goanna.6470 References: Distribution: comp Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 54 In article , mikeg@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.