The GNU Coding Standards document the programming style used by the GNU Project. Its main purpose is to guide all volunteers in writing portable, robust, and reliable programs; and to provide GNU tools that behave consistently. The GNU coding standards only mention coding in one C.
Indentation
Here is one example of the indentation:
int main()
{
foo(bar);
}
The basic level of indentation puts the curly brackets on one line, indenting them two spaces in. The statement(s) after the brackets are indented four spaces in.
For a function, the curly brackets should be on the first line, on seperate lines. The body of the function should be indented two spaces in.
Statements such as the if statement should be styled like this:
foo()
{
if (foo == bar)
{
puts(bar);
}
}
Each statement (in this case, if) should be indented from the starting curly bracket. If the statement is a compound statement the curly brackets of its own should be indented two more spaces judging by the statement's position.
do-while statements should be written like this:
do
{
foo(bar);
}
while (foo == bar)
Variable Declaration
Variables are declared each on one line, or two of the same sort on one line. The former is prefered in the GNU coding style.
Examples:
int foo; int bar;
OR
int foo, bar;
The method:
int foo,
bar;
is not permitted under the guidlines.
Comments
Based on the standard, all comments should be in English. Each comment should have basic punctuation, but if a lower case identifier comes in the start of a sentence , you are not meant to capatilise it.
According to the standard, a brief comment at the top should explain the program use. This comment should be at the top of the source file containing the main() function.
Comments should also be at the top of functions, explaining what they do and what arguments they recieve. To the standard, it is not neccasary to dupicate the meaning of the functions arguments, if they are being used in a customary fashion.
The standard determines that there is no need to re-state the name of the function, the reader can see it for his or her self.
Every #endif should have a comment, explaining the condition that is being ended and its sense. Also, every #else statement should have the same sort of comment after it.
The standard asks that when a programmer enters a comment, the standard asks that two spaces are put on the end of the sentence so that the Emacs sentence commands work.
Files (temporary, configuration and/or backups)
The GNU coding standard tells where to save your temporary, configuration or backup files. It recommends to not assume that /etc or /usr are writeable. A program should have the ability to keep files somewhere else.
To this rule, there are two exceptions, one is that /etc is a place to hold system configuration information, the other is that if a user explicitly asks to store files in a directory, it is reasonable of the program to store the rest of the files in the same directory.
Portability
The GNU coding standards define the issue of portability in this way; portability in the Unix world means 'between Unixes', in a GNU program this kind of portability is desirable, but not vitally important.
According to the standard, portability problems are very limited as GNU programs are designed to be compiled with one compiler, the GNU C Compiler and only run on one system, which is the GNU system.
There is one form of portability problem though, and that is the fact that the standard makes it clear that a program should run on different CPU types. The standard says that GNU doesn't and won't support 16 bit types, but handling all the different 32 and 64 bit types is absolutly neccessary.