Corey's Projects: Conventions in C


	Professional Software Consulting

Conventions in C

There are almost as many ways to write C as there are people who write it. Many standards have evolved over the years, and many programmers have a love/hate relationship with them. None of the standards I saw ever really worked for me; there were always some things that I considered important that the standard didn't. So I created my own.

Code	Description	Example
c	char	cType, cUserSelection
i	integer	iCount, iLength
s	short	sCount, sLength
l	long	lFileLength
f	float	fAmount
d	double	dAmount
p	pointer	cpTPID, ipLengths, **cppArgv
a	array	caString[], caaStrings[][], iaNums[]
pa	pointer array	*cpaValue[]
r	structure	rBuffers, *rpLanguageList
t	typedef	FILE *tpOutputFile
u	unsigned	ucExtractToken, uiFileLength

The most important factor in understanding my C code is understanding what a co-worker called Polish notation (because I'm Polish). It is similar to Hungarian Notation, but with a few exceptions. Most notably is in my distinction between an array and a pointer. My distinction has primarily to do with the sizeof operator; if you use this operator on any pointer, it will always return 4 (or whatever the length of a pointer is in your system). On the other hand, if you use it on an array, it will return the length of the array accurately. This distinction enables me to very quickly spot these types of bugs.

Another item is that structure names are followed by "_r". This enables me to quickly identify keywords as structures - I typically don't use typedefs because they are too easily confused with constants. I like to know when I'm using a structure and when I'm not.

Some people think it makes the code look cluttered, but I find that once you get used to it, it makes reading the code far faster. The eye tends to get drawn towards the first upper-case character in the variable name, and if you ever wonder what kind of variable it is, you can simply look at the front.

With modern languages, this is not often useful. For example, I have found that in Java, 99% of the time, a variable is an object. Putting an "o" in front of every variable that is an object really does create clutter. And in loosely typed languages like PHP, there are no clearly defined variable types - and even if you defined a variable to hold an integer by calling it iMyVar, it is ridiculously easy to find out later that somehow, it now holds a string value.

Modern IDE's make this type of nomenclature obsolete, because you can typically find out the type of variable simply by hovering over it. This standard was designed for a feature-poor environment, where all you have to work with is vi in your ssh window.

My other conventions are pretty innocuous, such as putting the opening curly brace below the if statement instead of on the same line. I also like to try and keep my line length down to less than 80 characters, for ease of printing (if I ever need to) and also because by packing multiple 80 column windows on my screen, I can see more code at the same time than if I cascade large windows.

In the war between using tabs or spaces, I choose tabs because my favorite code editor is vi, and it has this nice auto-indent feature that is tab based. And four spaces per tab is how I prefer to see code; it spreads things out enough to enable one to easily delineate levels of indentation, but not so much that most of the page is whitespace.

An excellent book on coding is Code Complete, from which I garnered quite a few ideas on how to write simple, re-usable, and most importantly, readable code.

Something wrong with this page or this site? Let the webmaster know by clicking HERE