# 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:
```c
	#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:
```c
	if (!a
	&&   b
	&&  !c) {
	...
	}
```
+ avoid useless comparison information
```c
	if (a != 0) /* BAD */
	if (a) /* as god intended */
```

### Switch ###
 + Multi-line
```c
	switch (...) {
		case ...: {
			...
			break;
		}
	}
```
 + Single line (if you dare)
```c
	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