From 5956f67c49053c1eb5631fb2ec44f6507c41d7c5 Mon Sep 17 00:00:00 2001 From: anon Date: Sat, 23 Nov 2024 15:44:48 +0100 Subject: [PATCH] move the standard and create a real readme --- README.md | 137 ++++++---------------------------------------------- standard.md | 125 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 140 insertions(+), 122 deletions(-) create mode 100644 standard.md diff --git a/README.md b/README.md index 1d3f2d6..a49babc 100644 --- a/README.md +++ b/README.md @@ -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 \ No newline at end of file +## 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) diff --git a/standard.md b/standard.md new file mode 100644 index 0000000..1d3f2d6 --- /dev/null +++ b/standard.md @@ -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 \ No newline at end of file