Index O'Stuff
Home
Compression
Arithmetic Coding
Burrows-Wheeler Transform
Huffman Coding
LZSS Coding
LZW Coding
Run Length Encoding
Misc. Programming
School Projects
Thesis Project
crypt(3) Source
Hamming Codes
Bit Manipulation Libraries
Square Root Approximation Library
Sort Library
Trailing Space Trimmer and Tab Remover
Command Line Option Parser
Humor
Dictionary O'Modern Terms
The Ten Commandments of C Style
Other Stuff
TOPS Success Story
Free Win32 Software
External Links
SPAN (Spay/Neuter Animal Network)
Los Angeles Pet Memorial Park
Mirrors
Pages at geocities
Pages at dipperstein.com
Obligatory Links
Visits since I started counting:
|
The Ten Commandments of C Style
A remedial course for caps criminals
1
- Woe be to those errant scribes who ignore capitalization in the writing
of the C program, and a plague of frogs on those who turn off the switch of
capitalization.
- Thou shalt not capitalize statements such as the "if" or the
"for".
- CONSTANTS shall be shouted to the multitudes in all caps, from every
rooftop and steeple, as they are the unchanging firmament and change not
through all time, and woe be to those that confuse them with variables.
- Those Types and Structures which are user defined shall be presented with
the first letter capitalized, as they are the high born, lest they be
confused with the lesser variables, nor with the shouted CONSTANTS.
- Variables shall be lower case, even as they start a sentence, for they
are the low and common peasant workers doing the everyday drudgery of
programming work, and must not be confused with the high-born Structures, nor
with the ever-stable firmament of CONSTANTS.
- Brothers have come to blows o'er the use of long variable names, with
many favoring the internal capitalization, thus the use of
long int numberOfPeopleInHell;
whereas others have countered with heated words that the proper way would be
long int number_of_people_in_hell;
Woe be to those who use either name, for it is likely not unique in the first
six to eight letters, making some compilers gnash their teeth, while the true
scope of the number of people in hell would vastly exceed the capacity of the
long int, causing the dreaded plague which infecteth, locketh-up and
rebooteth all computers from the lowly PIC to the mighty Cray.
- While much blood has been shed over the issue of the curly brace, and
many are the programmers that have argued that opening curly braces should go
on their own line, while others have protested with sword-in-hand that they
must go on the same line as the statement, and many have come to blows over
this, the closing curly brace shall be indented to the same level as the
opening function.
- Thou shalt not comment the obvious. Those rapscallions and heathens who
penned the line:
i++; /* Add one to i */
shall be forever banned from the inner circle of C, though their resume grow
long and their accomplishments and finished code stretch out before them
like a lake of ASCII text. Likewise, any code which is not obvious, or
obfuscates and bebothers the user, shall be extensively commented so as to
make clear the intent of the programmer.
- Thou shalt comment the author, date, and revision of each C program, and
lo, other comments shall be brief, descriptive, to the point, yet clear as
the purest mountain spring water in their explanation and clarification of
the code. Each function shall have as its companion a description of its
function, its inputs and outputs, as each dog has its day and each actor his
moment on the stage. Thou shalt document the purpose of each and every I/O
pin in an embedded processor, and for each variable, data member or Structure
there shall be a comment which shall illuminate and enlighten the reader of
the program as to its use.
- Thou shalt properly indent programs, each subservient function being
indented one level more than its master.
1
Written by Lawrence Lile and
originally posted to the PICList.
|