How to Program in C
The Ten Commandments for C Programmers
- Thou shalt run lint frequently and study its pronouncements
with care, for verily its perception and judgement oft exceed
- Thou shalt not follow the NULL pointer, for chaos and madness
await thee at its end.
- 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.
- 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.
- Thou shalt check the array bounds of all strings (indeed,
all arrays), for surely where thou typest ``foo'' someone someday
shall type ``supercalifragilisticexpialidocious''.
- 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.
- 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.
- 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.
- 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.
- 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.
Addendum - How to write in C
- Rewrite standard functions and give them your own obscure
- Use obscure, proprietary, non-portable, compiled library
packages so that you never have to move from the platform you
love so well.
- Use very descriptive comments like:
/* printf("Hello world\n"); */
before each function call
- Carriage returns are for weenies.
- tabs are for those who have not reached weenie-dom yet.
- Include *LOTS* of inline assembly code.
- "User Interfaces" are for morons. "Users"
have no business interfacing with a professional product like
- If you are forced to comment your code (in English), then
borrow comments from somebody else's code and sprinkle them throughout
yours. It's quick, easy, and fun to watch people's expressions
as they try to figure it out.
- Remember to define as many pre-processor symbols as possible
in terms of already defined symbols. This is considered 'efficient
use of code'.
- Assume the compiler takes care of all the little details
you didn't quite understand.
Addendum - How to debug C code
- Since you got it to compile, the problem must be in the Other
- If it's all your code then the problem *MUST* be in those
unreliable Standard Libraries. See '1.' in the previous section.
- Claim the bug reports are vicious lies meant to tarnish your
sterling reputation as a 'C' programmer (well aren't they?).
After all, those who wrote the reports couldn't even *read* your
code. How could they possibly know if there was a bug or not?
- If they could read your code, review "How to write in
- Claim that there wouldn't be a problem if this stingy Company/School/Wife/etc
would spring for a copy of C++.
- Insert/remove blank lines at random spots, re-compile, and
- If it still doesn't work, re-write it in assembler. This
won't fix the bug, but it will make sure no one else finds it
and makes you look bad.