125 lines
3.5 KiB
Markdown
125 lines
3.5 KiB
Markdown
# 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 |