10 Commandments, Revised

[Grant D. Watson]

Okay, forgive me if this has come up before, but I didn't find anything in
Google Groups.

I ran accross an old printed copy of the 10 Commandments for C Programmers a
little while back, and it got me thinking: "Gee, these are beginning to show
their age. I wonder what the folks on c.l.c would suggest by way of revision?"

So, if you were to produce a Revised 10 Commandments for C Programmers, what
would you add? What would you remove? What would you change?

Grant D. Watson
(e-mail address removed) (Use this one!)

 

[Jeff]

Okay, forgive me if this has come up before, but I didn't find anything in
Google Groups.

I ran accross an old printed copy of the 10 Commandments for C Programmers a
little while back, and it got me thinking: "Gee, these are beginning to show
their age. I wonder what the folks on c.l.c would suggest by way of revision?"

So, if you were to produce a Revised 10 Commandments for C Programmers, what
would you add? What would you remove? What would you change?

Grant D. Watson
(e-mail address removed) (Use this one!)

1. Never assume anything
2. See 1.

 

[Dan Pop]

I ran accross an old printed copy of the 10 Commandments for C Programmers a
little while back, and it got me thinking: "Gee, these are beginning to show
their age. I wonder what the folks on c.l.c would suggest by way of revision?"

So, if you were to produce a Revised 10 Commandments for C Programmers, what
would you add? What would you remove? What would you change?

Let's look at them:

1 Thou shalt run lint frequently and study its pronouncements with
care, for verily its perception and judgement oft exceed thine.

gcc -Wall -O and compilers with similar diagnosing capabilities remove
the need for lint. So, the validity of this commandment depends on your
compiler.

2 Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end.

s/NULL/null

3 Thou shalt cast all function arguments to the expected type if they
are not of that type already, even when thou art convinced that this
is unnecessary, lest they take cruel vengeance upon thee when thou
least expect it.

Valid for variadic functions only.

4 If thy header files fail to declare the return types of thy library
functions, thou shalt declare them thyself with the most meticulous
care, lest grievous harm befall thy program.

Obsolete.

5 Thou shalt check the array bounds of all strings (indeed, all
arrays), for surely where thou typest ``foo'' someone someday shall
type ``supercalifragilisticexpialidocious''.

More valid than ever.

6 If a function be advertised to return an error code in the event of
difficulties, thou shalt check for that code, yea, even though the
checks triple the size of thy code and produce aches in thy typing
fingers, for if thou thinkest ``it cannot happen to me'', the gods
shall surely punish thee for thy arrogance.

Valid.

7 Thou shalt study thy libraries and strive not to reinvent them
without cause, that thy code may be short and readable and thy days
pleasant and productive.

Valid.

8 Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest it
not, for thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

Couldn't agree more!

9 Thy external identifiers shall be unique in the first six characters,
though this harsh discipline be irksome and the years of its necessity
stretch before thee seemingly without end, lest thou tear thy hair
out and go mad on that fateful day when thou desirest to make thy
program run on an old system.

A bit rusty these days. The systems with this limitation usually don't
have standard C implementations. However, except for general purpose
libraries that need their own name space, the rule is relatively easy to
follow.

10 Thou shalt foreswear, renounce, and abjure the vile heresy which
claimeth that ``All the world's a VAX'', and have no commerce with
the benighted heathens who cling to this barbarous belief, that the
days of thy program may be long even though the days of thy current
machine be short.

s/VAX/Windows PC

So, most of it survived with little changes. A new item emphasising the
importance of portable programming should probably be added. And another
against confusing C and C++ and discouraging the writing of C code that
compiles with C++ compilers. But I'm completely incompetent on King
James' English, so I'm not going to write them ;-)

Dan

Dan

 

[Eric Sosman]

Okay, forgive me if this has come up before, but I didn't find anything in
Google Groups.

I ran accross an old printed copy of the 10 Commandments for C Programmers a
little while back, and it got me thinking: "Gee, these are beginning to show
their age. I wonder what the folks on c.l.c would suggest by way of revision?"

So, if you were to produce a Revised 10 Commandments for C Programmers, what
would you add? What would you remove? What would you change?

Are you aware of the "Annotated Edition?"

http://www.lysator.liu.se/c/ten-commandments.html

 

[Programmer Dude]

s/NULL/null
s/VAX/Windows PC

Just out of curiosity, is this no-final-delimiter a new idiom?
I would have expected an old unix hound to put it there without
thinking, so it's absence seems curious and perhaps in aid of
some statement...

 

[Dan Pop]

Just out of curiosity, is this no-final-delimiter a new idiom?
I would have expected an old unix hound to put it there without
thinking, so it's absence seems curious and perhaps in aid of
some statement...

Neither vi nor ed require it (or even non-Unix editors using a similar
syntax for the substitute command I have used), so why should I put it?

It is really needed only if you want to specify a flag, as in:

s/VAX/Windows PC/g

Dan

 

[Programmer Dude]

Neither vi nor ed require it...

Sunofagun, so they don't. I never realized that! Cool!!

 

[Malcolm]

So, if you were to produce a Revised 10 Commandments for C
Programmers, what would you add?

1) I am C, that brought thee out of assembly bondage. All thy algorithms
shall be specified in me.

2) Thou shalt ++ nothing to my name.

3) Clumsily shalt thou handle thy errors, I make no exceptions for thee. Try
me not, for I am C.

4) Thou shalt not define bool, nor min, neither max nor anything that shall
break the code of thy brother.

5) Thou shalt not use globals.

6) Nor shalt thou goto.

7) Thy functions shall perform one task and one task alone.

8) Thy function pointers shall be few in number, lest thy code degenrate
into spaghetti at the end of thy days.

9) Though shalt not covet thy neighbours C++ compiler for a cheap C99
compiler.

10) Thy functions shall be generalised, and shall not be thine, but shall
belong to me, the C language (via c.l.c.) , that brought thee out of the
bondage of assembly and ported thee to the land of GUIs

 

[Kevin Easton]

Neither vi nor ed require it (or even non-Unix editors using a similar
syntax for the substitute command I have used), so why should I put it?

On the other hand, sed does:

kevin@beernut:~$ sed -e 's/VAX/Windows PC'
sed: -e expression #1, char 16: Unterminated `s' command

- Kevin.

 

[Zoran Cutura]

in this case, the g modifer is necessary. You wouldn't want to remove
just one windows PC.

But he's not removing "Windows PC"'s at all. VAXen are substituted by
'em, not the other way round.

It looks like your wishes blinded you.

 

[Mark Haigh]

So, if you were to produce a Revised 10 Commandments for C Programmers, what
would you add? What would you remove? What would you change?

You're quite right that it needs revision. Here are my changes. Any
input? I reordered several of them to reflect what I believe to be the
proper priority, removed the obsolete ones, modified several, and came
up with a couple of my own that I think most clc regulars would agree with.



The Ten Commandments for C Programmers


Original by Henry Spencer
Revised by Mark F. Haigh


1. Thou shalt invoke thy compiler with all pertinent warnings enabled,
and if thy compiler ist lacking, seek out the paranoid prophet lint, for
verily their perception and judgement oft exceed thine.

2. Thou shalt not follow the null pointer, or arrogantly evaluate the
indeterminate pointer, for chaos and madness await thee at the ends.

3. Thou shalt check the array bounds of all strings (indeed, all
arrays), for surely where thou typest ``foo'' someone someday shall type
``supercalifragilisticexpialidocious''.

4. If a function be advertised to return an error code in the event of
difficulties, thou shalt check for that code, yea, even though the
checks triple the size of thy code and produce aches in thy typing
fingers, for if thou thinkest ``it cannot happen to me'', the gods shall
surely punish thee for thy arrogance.

5. Thou shalt study thy libraries and strive not to reinvent them
without cause, that thy code may be short and readable and thy days
pleasant and productive.

6. Thou shalt foreswear, renounce, and abjure the vile heresy which
claimeth that ``All the world's a PC'', and have no commerce with the
benighted heathens who cling to this barbarous belief, that the days of
thy program may be long even though the days of thy current machine be
short.

7. Thou shalt tirelessly endeavor to ensure that thy work doth not
disturb the frightful demon 'undefined behavior', whose mighty wrath
hast humbled many a clever apprentice.

8. Thou shalt be ever vigilant and wary of the 'default argument
promotions', a serpent-like beast that dwells within the dark variadic
forest, watching thy every move with ill intent.

9. Thou shalt refrain from preprocessor gluttony and premature
optimization, lest ye be cursed by the hapless souls maintaining thy
handiwork.

10. Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest it
not, for thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.



Mark Haigh
(e-mail address removed)
(formerly Mark S.)

 

[Arthur J. O'Dwyer]

^^^^
ITYM hath

Oh, well, if we're going to be correcting people's English now, we
may as well proofread the rest...

1. Thou shalt invoke thy compiler with all pertinent warnings enabled,
and if thy compiler be lacking, shalt seek out the paranoid prophet
lint, for verily its perception and judgement oft exceed thine.

['Ist' is German, not English!]

2. Thou shalt not follow the null pointer, or arrogantly evaluate the
indeterminate pointer, for chaos and madness await thee there.

3. Thou shalt check the array bounds of all strings (indeed, all
arrays), for surely where thou typest ``foo'' someone someday shall
type ``supercalifragilisticexpialidocious''.

4. If a function be advertised to return an error code in the event of
difficulties, thou shalt check for that code, yea, even though the
checks triple the size of thy code and produce aches in thy typing
fingers, for if thou thinkest ``it cannot happen to me'', the gods shall
surely punish thee for thy arrogance.

5. Thou shalt study thy libraries and strive not to reinvent them
without cause, that thy code may be short and readable and thy days
pleasant and productive.

6. Thou shalt forswear, renounce, and abjure the vile heresy which
claimeth that ``All the world's a PC'', and have no commerce with the
benighted heathens who cling to this barbarous belief, that the days of
thy program may be long even though the days of thy current machine be
short.

7. Thou shalt tirelessly endeavor to ensure that thy work doth not
disturb the frightful demon 'undefined behavior', whose mighty wrath
hath humbled many a clever apprentice.

8. Thou shalt be ever vigilant and wary of the 'default argument
promotion', a serpent-like beast that dwells within the dark variadic
forest, watching thy every move with ill intent.

9. Thou shalt refrain from preprocessor gluttony and premature
optimization, lest ye be cursed by the hapless souls maintaining thy
handiwork.

10. Thou shalt make thy program's purpose and structure clear to thy
fellow man by using the One True Brace Style, even if thou likest it
not, for thy creativity is better used in solving problems than in
creating beautiful new impediments to understanding.

Mark Haigh
(e-mail address removed)
(formerly Mark S.)


-Arthur

 

[Alex]

in this case, the g modifer is necessary. You wouldn't want to remove
just one windows PC.

s = substitute

You're not even removing one. You are, however, bringing one to life.
A 'g' modifier would bring a whole lot of them to life. You have to
be careful with these things

Alex

 

[Grant D. Watson]

Let's look at them: <snip>

So what would you suggest to replace the outdated ones? We've got to keep the
total up, you know. <grin>

Grant D. Watson
(e-mail address removed) (Use this one!)

 

[Grant D. Watson]

3) Clumsily shalt thou handle thy errors, I make no exceptions for thee. Try
me not, for I am C.

6) Nor shalt thou goto.

It seems to me that goto is often the least-inelegant solution to commandment
3. (BTW, I find exceptions to be clumsy, too. C's method is clumsy only when
you need to propogate the error.) Anyway, if we are to Keep the Commandments,
do you have a decent solution to reduce clumsiness to #3.

(Yes, this is an aside. And, yes, this is a real question.)

9) Though shalt not covet thy neighbours C++ compiler for a cheap C99
compiler.

Wow; I never even thought of that. <grin>

Grant D. Watson
(e-mail address removed) (Use this one!)

 

[Grant D. Watson]

Mark Haigh intones:

2. Thou shalt not follow the null pointer, or arrogantly evaluate the
indeterminate pointer, for chaos and madness await thee at the ends.

Now I see; the indeterminate pointer bit must have been what was intended by
the original commandment, as well.
(I'd always figured that a programmer who wrote "int *p = NULL; *p;" would
quickly find out the error of his ways.)

Thank you for the enlightenment.

7. Thou shalt tirelessly endeavor to ensure that thy work doth not
disturb the frightful demon 'undefined behavior', whose mighty wrath
hast humbled many a clever apprentice.

This seems a particularly useful addition to a post-ANSI standard list.

Grant D. Watson
(e-mail address removed) (Use this one!)

 

[Kevin Easton]

Mark Haigh intones:

Now I see; the indeterminate pointer bit must have been what was intended by
the original commandment, as well.
(I'd always figured that a programmer who wrote "int *p = NULL; *p;" would
quickly find out the error of his ways.)

There were (around the time the originals were written) machines in
common use which had a 0 stored at the address referenced by NULL, so it
could be used as a pointer to an empty string on those machines. And
so, of course, people sometimes wrote code that used NULL as a pointer
to an empty string.

- Kevin.