The FreeTDS coding style for C code is close to K&R/Linux kernel style.  
This document makes explicit the coding style found through most of the 
project.  There are likely to be portions of code that do not follow this 
style, but ideally all would.

We are of course not trying to dictate how you code, but patches or submissions 
to CVS should be converted to this style prior to committing.  The indent program
found on most Unix systems will do this nicely.

Code Blocks
-----------

Blocks of code should start with the { on the line with the control statement.

For example,

for (i=0;i<x;i++) {
	...
}

This applies to for, do, while, switch, if and any other looping or branching
constructs.  The exception to this is function declarations, in which the { 
should follow the declaration, as in

void foo(int bar)
{
	...
}

Indenting
---------

Indenting should be done with one tab character per level.  I generally use a 
tabstop of 5 when programming, so it probably looks best like that.

Variables
---------

Variables in FreeTDS should be all lower case with words separated by '_' 
(underscore).  Furthermore, brevity is valued but not at the expense of clarity.
For instance, the variable 'minor_ver' is clear enough in context and doesn't 
need to be labeled 'minor_version'.  The counter example to this is that the 
variable 'can' is rather ambiguous and be expanded to 'canceled' for clarity.

The sole exception to this is arguments to the ODBC functions.  ODBC because of 
its lineage uses hungarian notation for the names of the function arguments.
Variables that are internal to the functions should still follow the coding
style, but function arguments retain their Microsoft given names.

Variable declarations at the top of the function should be left aligned. This is
a departure from K&R style but one I find is helpful when scanning through the 
code.  Example,

void foo(int bar)
{
int i;

	for (i=0;i<bar;i++) {

	...

}

a single space is generally preferred to separate the type from the variable
name, although some code pushes variable names to the right for clarity. 
Which ever looks better is fine.

Function Declarations
---------------------

Function declarations started out a little like this:

void foo(int bar, int baz)
{
}

with no spaces between the function name 'foo' and the left paren, between the 
left paren and the first argument, nor the last argument and the right paren. A
single space should follow the comma after each argument.

In recent times, the functions have been moving towards the GNU style 
declaration with the return type and modifiers on the line above, and the next
line starting with the name of the function

static void
foo(int bar, int baz)
{
}

Spacing remains the same, but having the function aligned to the left side makes
searching for functions, and not the calls to them, easier.  This style is now
preferred, but much of the code does not implement it.

When creating a function with no arguments there should be no spacing between
the parens.

void
foobar()
{
}
 
Comments
--------

FreeTDS is a fairly portable package and runs on a number of platforms that 
have either no C++ style comments or need special switches to turn them on 
(the AIX C compiler comes to mind).  Therefore, all comments must be C-style
comments and not the C++ // comments.

void
foo()
{
	// incorrect
}

void
foo()
{
	/* correct */
}

The second comments related item is function documentation.  While not really 
widely implemented yet, we are moving towards doxygen (JavaDoc) comments so 
that function declarations can be extracted into a programmers manual.  

See http://www.stack.nl/~dimitri/doxygen/manual.html for details.

