mikeg@c3.c3.lanl.gov (M. P. Gerlek (hack grad student)) (06/23/91)
Okay, so here's the deal: I have this officemate (who shall remain
nameless :-) who considers himself a competent C programmer, but
insists on writing what most of us consider very bad code. No
kidding, he writes:
for (i=0; i<n; i++)
printf("%d\n", *(x+i));
instead of:
for (i=0; i<n; i++)
printf("%d\n", x[i]);
There is not a single ``['' or ``]'' is his entire code. Anywhere.
Except maybe for declaring arrays. He even does this for indexing
into multiply dimensioned arrays.
He correctly argues that array syntax is equivalent to straight
pointer syntax, and claims he can "understand" the code he's doing
much better his way. So, while he gets points for having a wonderful
grasp of pointers and indirection, his code is totally meaningless to
the rest of us.
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". We argue that when he gets out into the Real World
he'll be screwed -- and he says he'll deal with that later.
So what can we do? How can we convince him of the error of his ways?
(half :-)
PS- Can someone mail me an ftp site for the Indian Hill style guide?
-[mpg]
mikeg@lanl.gov
"Bond top cheese."
--daves@hpopd.pwd.hp.com (Dave Straker) (06/23/91)
>So what can we do? How can we convince him of the error of his ways?
Probably not, by the sound of it. If he writes code that must be
maintained by others, show him how many more defects he introduces,
and how much longer it takes others to find *his* defects (as opposed
to anyone else's).
Dave Straker Pinewood Information Systems Division (PWD not PISD)
[8-{) HPDESK: David Straker/HP1600/01
Unix: daves@hpopd.pwd.hp.comok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/24/91)
In article <MIKEG.91Jun22125223@c3.c3.lanl.gov>, 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.
grantk@manta.NOSC.MIL (Kelly J. Grant) (06/24/91)
In article <6470@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > In article <MIKEG.91Jun22125223@c3.c3.lanl.gov>, 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
hp@vmars.tuwien.ac.at (Peter Holzer) (06/25/91)
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >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. Could you give some examples? My programming style happens to be very much like that recommended in the Indian Hill style guide and I want to know what I am doing wrong. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
sherman@unx.sas.com (Chris Sherman) (06/25/91)
In <2075@manta.NOSC.MIL> grantk@manta.NOSC.MIL (Kelly J. Grant) writes: >In article <6470@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >> In article <MIKEG.91Jun22125223@c3.c3.lanl.gov>, 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". >> > No kidding, he writes ... *(x+i) ... [instead of] ... x[i] ... Real C Programmers (TM) aren't bothered by *(x+i). On the other hand, C Programs who used to be Pascal (or whatever) programmers are. :-) Actually, I don't have a problem with *(x+i) because when the code gets ugly, I can decompose the pointer line into something that looks like *(x+i), and be able to understand it more. >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. This is always true. The grey area between personal style and group style is a religious issue which will last longer than any of us. IMHO, leave the dude alone. Jump up and down when you find major problems in his code like: char *d="068B9669996E9EA9E999E9DB999ACA9F8C8F",*p="12342506775730",o[480],*r,*q, c,*z,*e,x,l=80,y='0';s(){memset(o,' ',480);z=o;}main(){s();while(c= *p++)if(c-=y ){for(r=z+320,e=d+c*5;r>=z;r-=l,e--)for(x=(*e-y&~15)?*e-'A'+10:*e-y,q=r+4;x;x>>= 1,q--)if(x&1)*q='*';z+=6;}else{for(r=o;r<o+480;r+=l)printf("%79.79s\n",r);s();}} but for things like *(x+i), don't worry about it. -- Chris Sherman .................... sherman@unx.sas.com | ,-----------------------------------------' / Q: How many IBM CPU's does it take to execute a job? | A: Four; three to hold it down, and one to rip its head off.
mikeg@c3.c3.lanl.gov (M. P. Gerlek) (06/25/91)
In article <sherman.677844151@foster> sherman@unx.sas.com (Chris Sherman) writes: > IMHO, leave the dude alone. Jump up and down when you find major problems > [...] > but for things like *(x+i), don't worry about it. Yes, x[i] is just *(x+i), but consider what x[a][b+k][j+1] turns into. I can't believe more than a handful of you could look at the "pointer-ized" expression for x[a][b+k][j+1] and *immediately* tell what it means. We're considering readability of code, here. As an example, consider coding some sort of numerical, linear algebra sort of algorithm. The mathematical expression can be fairly quickly translated into C, substituting x-sub-i-sub-j ("x_ij") for x[i][j]. It's not obvious to the subsequent reader of the code that the expression *(*(x+i)+j) is simply x[i][j], however. You've lost 'readability'. I'm amazed at the number of comments I've rec'd about using pointers *instead of* simple array syntax. Tell me it's just that I'm not hearing a representative sample -- I refuse to believe the majority of the net feels that there's no point in conforming to one set style because, to quote some email, (a) there are too many styles, (b) if YOU write the code YOU can do it however YOU want, and (c) anyone using the code later should be able to just clean up the parts he or she doesn't like. (This last is particularly amazing :-) Yes, I will grant that if the peiece of code you are doing is a one-man project you can code it however you like -- but what happens after you've left the shop, and someone else needs to use it? Further, to get back to my original post, we're dealing with a case where the programmer is programming solo _today_, but will be writing code that he and others will have to port and modify _tomorrow_. Finally, I've gotten responses saying that the Indian Hill style guide is out-of-date and flat out wrong in places. Will someone please post a critique of the I.H. guide? And please tell me what y'all use instead? If anything? And as an aside to those of you who don't like "conventions" and "styles" in C: do you put your #defined constants in all uppercase? You do? Care to explain why? -[mpg] mikeg@lanl.gov "Headline: LANL High-speed Compooter Researchers Pay Raft Trip Subsidies" -- -[mpg] mikeg@lanl.gov "Headline: LANL High-speed Compooter Researchers Pay Raft Trip Subsidies"
bhoughto@hopi.intel.com (Blair P. Houghton) (06/26/91)
In article <sherman.677844151@foster> sherman@unx.sas.com (Chris Sherman) writes: >Real C Programmers (TM) aren't bothered by *(x+i). On the other hand, >C Programs who used to be Pascal (or whatever) programmers are. :-) Not surprisingly, I know a number of C programs that used to be Pascal programmers... --Blair "Y'know, Freud would've had something to say about this; and so would the Luddites..."
bhoughto@hopi.intel.com (Blair P. Houghton) (06/26/91)
In article <sherman.677844151@foster> sherman@unx.sas.com (Chris Sherman) writes:
[...]
Uh, so who's Gordon Keener?
--Blair
"And does he have a man-
page for that thing?"stanley@phoenix.com (John Stanley) (06/27/91)
sherman@unx.sas.com (Chris Sherman) writes: > IMHO, leave the dude alone. Jump up and down when you find major problems > in his code like: > > char *d="068B9669996E9EA9E999E9DB999ACA9F8C8F",*p="12342506775730",o[480],*r, > c,*z,*e,x,l=80,y='0';s(){memset(o,' ',480);z=o;}main(){s();while(c= *p++)if(c > ){for(r=z+320,e=d+c*5;r>=z;r-=l,e--)for(x=(*e-y&~15)?*e-'A'+10:*e-y,q=r+4;x;x > 1,q--)if(x&1)*q='*';z+=6;}else{for(r=o;r<o+480;r+=l)printf("%79.79s\n",r);s() > > but for things like *(x+i), don't worry about it. If God had not wanted us to write code that looked like that, He wouldn't have invented 'indent'.
greywolf@unisoft.UUCP (The Grey Wolf) (06/28/91)
/* <MIKEG.91Jun25093137@c3.c3.lanl.gov> by mikeg@c3.c3.lanl.gov (M. P. Gerlek)
*
* In article <sherman.677844151@foster> sherman@unx.sas.com (Chris Sherman) writes:
* > IMHO, leave the dude alone. Jump up and down when you find major problems
* > [...]
* > but for things like *(x+i), don't worry about it.
*
* Yes, x[i] is just *(x+i), but consider what x[a][b+k][j+1] turns into.
* I can't believe more than a handful of you could look at the
* "pointer-ized" expression for x[a][b+k][j+1] and *immediately* tell
* what it means. We're considering readability of code, here.
What, you mean *(*(*(x+a)+(b+k))+(j+1))? Makes perfect sense, what's
the matter? :-)
In all seriousness, from my own (probably insignificant) point of view,
how it is done depends largely upon how it is declared. For "propriety's"
sake, I guess I'm kind of a purist: If it's a pointer, use offsets.
If it's an array, use indeces. That's just my own style, tho'. It reminds
me of precisely that with which I am dealing.
* As an example, consider coding some sort of numerical, linear algebra
* sort of algorithm. The mathematical expression can be fairly quickly
* translated into C, substituting x-sub-i-sub-j ("x_ij") for x[i][j].
* It's not obvious to the subsequent reader of the code that the
* expression *(*(x+i)+j) is simply x[i][j], however. You've lost
* 'readability'.
Depends upon the person to whom you hand the code. Admittedly it does
get hairy when you start getting into triple-indirections (or worse).
*
* Yes, I will grant that if the piece of code you are doing is a
* one-man project you can code it however you like -- but what happens
* after you've left the shop, and someone else needs to use it?
Ummm...no, wait... "if it was hard to write, it should be hard to
understand?" :-)
Well, yes, that does produce a problem. Again, there is the problem
of: Never mind anyone else yet, first things first: Will >>>>YOU<<<<
understand the code in a week, a month, six months from now?
* Further, to get back to my original post, we're dealing with a case
* where the programmer is programming solo _today_, but will be writing
* code that he and others will have to port and modify _tomorrow_.
*
He says he'll deal with it then; let him worry about it. It's his ass
if he fucks up, not yours.
* Finally, I've gotten responses saying that the Indian Hill style guide
* is out-of-date and flat out wrong in places. Will someone please post
* a critique of the I.H. guide? And please tell me what y'all use
* instead? If anything?
I'm interested as well.
*
* And as an aside to those of you who don't like "conventions" and
* "styles" in C: do you put your #defined constants in all uppercase?
* You do? Care to explain why?
So I can tell the difference between a constant and a variable, usually.
I leave macros lowercase, though.
*
* -[mpg]
* mikeg@lanl.gov
* "Headline: LANL High-speed Compooter Researchers Pay Raft Trip Subsidies"
* --
*
* -[mpg]
* mikeg@lanl.gov
* "Headline: LANL High-speed Compooter Researchers Pay Raft Trip Subsidies"
Is there an echo in here?
--
"Is 'Faxen' the plural of 'Fax', or is it 'Faces'?"
--
# "Religion is a weapon invented by the sheep to keep the wolves in line."
# greywolf@unisoft.com