Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!nosc!manta!grantk From: grantk@manta.NOSC.MIL (Kelly J. Grant) Newsgroups: comp.lang.c Subject: Re: Dealing with pointer freaks Message-ID: <2075@manta.NOSC.MIL> Date: 24 Jun 91 16:34:15 GMT References: <6470@goanna.cs.rmit.oz.au> Distribution: comp Organization: Computer Sciences Corporation Lines: 72 In article <6470@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > 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. 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@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