Chad Coding Standard

The most important thing is to be consistent with an existing codebase, don't make unnecessary large changes. If there are places where brackets should be used, use them! except for only else if

First Off

• keep a line width of 80
• string NULL termination is spelled '\0', not '\00'
• use NULL not 0, when applicable
• Use the correct editor

Compilation

• Provide Makefile

  Preferably GNU Make, or POSIX Make

Headers

• NEVER use relative paths, use well a written build script with -I, -L and other options
• Use these kinds of header guards:

	#ifndef NAME_H
	...
	#define NAME_H
	#endif

• Headers should, if meant to be exposed externally in any way, should have namespacing prefixes

Naming

• Namer (likely project owner) chooses standard spelling, try to stay to one locale when it comes to naming things (In US, color, In Europoor, caulouur [Sic])
• snake_case_for_all

Indentation

• Tabs & Spaces (get Smart Tabs plz)

Macros

• Parenthesize macro values

Padding

• Pad after commas
• Add padding around if, while, and for clauses
• Do not pad after a function name func(), NEVER func ()
• Do not pad inside parentheses func(a), NEVER func( a )
• Pad inside brackets always { ...; }

Declaration

• for functions always abide [static|extern] [inline] [type]
• Put pointers in the center char * abc
• Definitely put pointers together always, char *** x is definitely way better than char * * * x don't trust Anon or Xolatile on this matter and do not attempt to decide things democratically
• Function parameters should remain on the same line... func (int a) {...
• If a function has way too many parameters (line length greater than limit), format them into a block or lay them out in a indented list.
• Align adjacent declarations horizontally
• Always typedef structs and enums, avoid struct mytype myvar; if possible
• You may use anonymous structures

Conditionals

• align like this:

	if (!a
	&&   b
	&&  !c) {
	...
	}

• avoid useless comparison information

	if (a != 0) /* BAD */
	if (a) /* as god intended */

Switch

• Multi-line

	switch (...) {
		case ...: {
			...
			break;
		}
	}

• Single line (if you dare)

	switch (...) {
		case ...:
		{ ...; break; }
	}

Loops

• Try to use the alphabetical iterators i, j, k, ..., try not to use more than three iterators
• Use while (1) for infinite loops

Operators

• Use prefix increment by default ++i
• Use spaces in-between operators on the same line ALWAYS! (note that multi-line operators should have tabs for normal indenting, but otherwise should use spaces)

Advice

Compilation

• Resolve All Feasible Warnings given by selected compilers clang -Weverything gcc -Wall -Wextra -Pedantic
• Consider tools like splint, but don't break your back over it

The Dreaded Multi-line Comment

• Don't ever use them unless you have to

  C++ comments for logical separation and small comments

  C comments for large explanation

• Use them always and vanish C++ demons from your code

• Use #if 0... #endif /* 0 */ if you want to comment out blocks of code

Indentation

• Try not to go over 4 levels

Parenthesizing

• Do not parenthesize return statements

Loops

• If you will have NO other use for an iterator, put it inside the for loop declaration, C99> style
• Avoid commas in conditionals, it'll make Xolatile seethe

Naming

• Use the POSIX reserved _t suffix for new types