Update 'README.md'
This commit is contained in:
anon
parent
94d3639b39
commit
4a4fcf269e
208
README.md
208
README.md
@ -1,99 +1,125 @@
|
||||
# Coding Standard
|
||||
### Compialation ###
|
||||
+ remove all warnings
|
||||
clang -Weverything
|
||||
gcc -Wall -Wextra -Wpedantic
|
||||
valgrind --show-leak-kinds=all --leak-check=full
|
||||
+ under all cicumstances have (atleast a wrapper) Makefile for frenliness
|
||||
+ GNU Make ok, that other Make with a prefix shall burn in hell
|
||||
+ NOTE: (to Xolatile in particular) fuck splint
|
||||
|
||||
### Multi-line comments ###
|
||||
+ single line for separating logical blocks inside the same block
|
||||
+ multiline for exaplaining code
|
||||
/\* stuff
|
||||
\* and more
|
||||
\*/
|
||||
+ use them very sparsely
|
||||
|
||||
### Headers ###
|
||||
+ never use relative paths, manipulate the compiler
|
||||
+ use #define type header guards
|
||||
+ header guards shall be all caps
|
||||
<namespace>\_<unit>
|
||||
+ make function forward declarations explicitly `extern`
|
||||
|
||||
### Macros ###
|
||||
+ only with consensus can any new macro be added to the codebase
|
||||
+ always parenthesize values
|
||||
|
||||
### Identaion ###
|
||||
+ tabs
|
||||
+ max 4 levels
|
||||
|
||||
### Parenthesizing ###
|
||||
+ do not parenthesize return statements
|
||||
+ always add spacing around when after a control statement { `if (condition) {...}` }
|
||||
+ do not pad the insides { `(stuff) ; and not: ( stuff )` }
|
||||
+ do not pad after function context { `myfun();` }
|
||||
+ always use to avoid relying on operator precedence { `(a * b) + c` }
|
||||
|
||||
### Declarations ###
|
||||
+ pointer '\*'s always to the middle { `char * s;` }
|
||||
+ dont concat pointer '\*'s { `char \* \* s;` }
|
||||
+ function heads belong on the same line
|
||||
+ [static|extern] [inline] [type]
|
||||
+ align adjecent ones horizontally
|
||||
+ always typedef structs or make them anonymous
|
||||
# Chad Coding Standard
|
||||
|
||||
### If ###
|
||||
+ align logical operators under the keyword if
|
||||
if (a
|
||||
&& b
|
||||
&& c) {}
|
||||
+ align negating operators and the lack of there of
|
||||
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) {}
|
||||
+ always omit useless comperasions
|
||||
if (a) // good
|
||||
if (a != 0) // bad
|
||||
|
||||
&& !c) {
|
||||
...
|
||||
}
|
||||
```
|
||||
+ avoid useless comparison information
|
||||
```c
|
||||
if (a != 0) /* BAD */
|
||||
if (a) /* as god intended */
|
||||
```
|
||||
|
||||
### Switch ###
|
||||
switch(...) {
|
||||
case ...: {
|
||||
} beak;
|
||||
}
|
||||
+ GNU range extensions allowed
|
||||
|
||||
+ Multi-line
|
||||
```c
|
||||
switch (...) {
|
||||
case ...: {
|
||||
...
|
||||
break;
|
||||
}
|
||||
}
|
||||
```
|
||||
+ Single line (if you dare)
|
||||
```c
|
||||
switch (...) {
|
||||
case ...:
|
||||
{ ...; break; }
|
||||
}
|
||||
```
|
||||
|
||||
### Loops ###
|
||||
+ declare the iterator inside the loop
|
||||
+ variables to use for iteration 'i' -> 'j' -> 'k'
|
||||
+ use "while(1)" for infinit loops
|
||||
+ no coma in condition unless its an assignment
|
||||
+ never ommit brackets at empyt loop bodies
|
||||
|
||||
+ Try to use the alphabetical iterators `i, j, k, ...`, try not to use more than three iterators
|
||||
+ Use `while (1)` for infinite loops
|
||||
|
||||
### Operators ###
|
||||
+ prefer prefix crementors when possible { `++i;` }
|
||||
+ use spaces (if you dont intuetively know what this means, kys)
|
||||
+ 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 ###
|
||||
+ namer chooses spelling, consistency must follow
|
||||
+ snake\_case
|
||||
+ \*\_t on all typedefs
|
||||
+ LOCAL variables shall be short enough to not use snake\_case
|
||||
|
||||
### Misc ###
|
||||
+ keep a line width of 80
|
||||
+ string null termination is spelled '\0'
|
||||
|
||||
# Development Process
|
||||
### How to manage a group project
|
||||
1. Select PM
|
||||
2. Settle on the exact features
|
||||
3. Settle on the technologies
|
||||
4. Settle on basic structure
|
||||
5. Let the PM type out the frame with function prototypes / empty bodies
|
||||
6. Let the PM distribute the work
|
||||
7. Type away furiously
|
||||
+ Use the POSIX reserved \_t suffix for new types
|
||||
Loading…
x
Reference in New Issue
Block a user