Done from scratch to note choices done so far instead of copying and modifying after it. This just denotes my preferred coding style but the most important is for a project’s code to be consistent.
And this applies to all programming languages that I use, even if I’ll use C vocabulary when applicable.
The following contain good information, some of which is repeated below, some of which is contradicted below.
- Tabs for indentation; space for alignment
- C braces break style: Allman when it’s for grouping (ie. C if-else blocks), K&R when the braces are mandatory (ie. C function definition)
- When using
includesor similar, have them sorted (so there is deduplication) and grouped at the start of the file
- Code: 80 soft-limit, 100 hard-limit
- Text: 80 hard-limit, expect when non-breakable (like URLs)
- Compacting: do it if it fits the soft-limit
- main function is defined at the end of the file and functions are grouped by topic, preferably by reversed-order of execution (scripting languages habit).
- Functions to be used outside of their defining file should be put in a header. Make them private otherwise. This allows a clean and well-documented API.
- Documentation is mandatory for the API and must be reachable to where they are used. (ie. external for commands/networking, internal for functions)
- Design with extensibility in mind (so avoid booleans, test against sucess rather than error, structs are friends, …)