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

move the standard and create a real readme

Browse Source
This commit is contained in:
anon 2024-11-23 15:44:48 +01:00
parent a7535167ed
commit 5956f67c49
2 changed files with 140 additions and 122 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

137
README.md
View File

@ -1,125 +1,18 @@
# Chad Coding Standard
# /chad/ - C Help And Discussion
This repo attempts to collect and organize
information related to the /chad/ general.
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`
![media/chad.png](media/chad.png)
### 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
## What is there to see here?
+ the [standard](standard.md) is a coding guideline created by the IRC group
+ [the thread copy pasta](chad.pasta)
+ [memes and such](media/)
+ [/chad/ history](https://igwiki.lyci.de/wiki/C_Help_and_Discussion)
+ [incomplete list of things Xolatile hates](miscellaneous/xolatile_hates.list)
### 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
## See also
+ IRC - #/g/chad @ rizon.net
+ [Anon's gitea mirroring the software of multiple /chad/s](bis64wqhh3louusbd45iyj76kmn4rzw5ysawyan5bkxwyzihj67c5lid.onion)
+ [installgentoo wiki /chad/ page](https://wiki.installgentoo.com/wiki/C_Help_and_Discussion)
+ [wiki mirror](https://igwiki.lyci.de/wiki/C_Help_and_Discussion)

125
standard.md Normal file
View File

@ -0,0 +1,125 @@
# 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