anon/chad_standard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update 'README.md'

Browse Source
This commit is contained in:
anon
2024-01-19 14:29:08 +00:00
parent 94d3639b39
commit 4a4fcf269e
1 changed files with 117 additions and 91 deletions

210
README.md

@ -1,99 +1,125 @@
# Coding Standard # Chad 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 ### The most important thing is to be consistent with an existing codebase, don't make unnecessary large changes.
+ single line for separating logical blocks inside the same block If there are places where brackets should be used, use them! except for only `else if`
+ multiline for exaplaining code
/\* stuff ### First Off ###
\* and more + keep a line width of 80
\*/ + string NULL termination is spelled '\0', not '\00'
+ use them very sparsely + use NULL not 0, when applicable
+ Use the correct editor
### Compilation ###
+ Provide Makefile
Preferably GNU Make, or POSIX Make
### Headers ### ### Headers ###
+ never use relative paths, manipulate the compiler + NEVER use relative paths, use well a written build script with `-I`, `-L` and other options
+ use #define type header guards + Use these kinds of header guards:
+ header guards shall be all caps ```c
<namespace>\_<unit> #ifndef NAME_H
+ make function forward declarations explicitly `extern` ...
#define NAME_H
### Macros ### #endif
+ only with consensus can any new macro be added to the codebase ```
+ always parenthesize values + Headers should, if meant to be exposed externally in any way, should have namespacing prefixes
### 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
### If ###
+ align logical operators under the keyword if
if (a
&& b
&& c) {}
+ align negating operators and the lack of there of
if (!a
&& b
&& !c) {}
+ always omit useless comperasions
if (a) // good
if (a != 0) // bad
### Switch ###
switch(...) {
case ...: {
} beak;
}
+ GNU range extensions allowed
### 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
### Operators ###
+ prefer prefix crementors when possible { `++i;` }
+ use spaces (if you dont intuetively know what this means, kys)
### Naming ### ### Naming ###
+ namer chooses spelling, consistency must follow + 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 + snake\_case\_for\_all
+ \*\_t on all typedefs
+ LOCAL variables shall be short enough to not use snake\_case
### Misc ### ### Indentation
+ keep a line width of 80 + Tabs & Spaces (get Smart Tabs plz)
+ string null termination is spelled '\0'
# Development Process ### Macros ###
### How to manage a group project + Parenthesize macro values
1. Select PM
2. Settle on the exact features ### Padding ###
3. Settle on the technologies + Pad after commas
4. Settle on basic structure + Add padding around if, while, and for clauses
5. Let the PM type out the frame with function prototypes / empty bodies + Do not pad after a function name `func()`, NEVER `func ()`
6. Let the PM distribute the work + Do not pad inside parentheses `func(a)`, NEVER `func( a )`
7. Type away furiously + 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