Programming Style
Hot take: For the vast majority of questions in regards to programming formatting one can deduce the best style objectively and there is not much ambiquity in regards what the best style is. This only applied to ALGOL-derived languages, as Lisp, Forth, Assembly, and others work completely differently and have less such issues.
Assuming that…
- …Clarity is the most important aspect of code formatting
- …Readability is also important
- …that you should always choose the minimum of any measure you're taking is required
// Identation
// Always choose of 2 spaces
// It is the minimum required to be visible as being indented.
// More would be superfluous and would end up taking more space than
// minimally required
// (I'm not so sure about this particular issue anymore, as 4 spaces
// might be more readable and a better compromise between
// readability <-> using the minimum required to make it clear)
// As such, possibly disregard this.
if(condition) {
f();
}
// Tabs vs Spaces
// Spaces have always the same length and will always end up
// looking the same no matter in which editor or operating system.
// Tabs can fuck up your code and perhaps it looks different from
// what you intended, therefor for most clarity use spaces.
// Try to avoid using curly brackets wherever you can. If it is clear
// enough to understand for both the programmer and the compiler, then
// you can leave them out. If it will only lead to confusion or you
// have more than 1 instruction, then use them to make it more clear.
if(condition)
f();
else
f2();
// If the if statement and the instruction can be written on the same
// line, consider doing so, so it is more clear that it belongs to that
// particular if statement and makes the code, again, more readable
if(condition) f();
// Similarly with switch statements, the most readable way of writing it
// is writing the if statement and the instruction on the same line,
// but only when it isn't too long.
switch(condition) {
case 1: f1(); break;
case 2: f2(); break;
case 3: f3(); break;
case 4: f4(); break;
case 5: f5(); break;
default: break;
}
// The curly brackets of functions belong on their own line, because they
// cannot be nested further, unlike if/switch/do-while/while and such.
void f()
{
instruction;
instruction;
instruction;
}
// meanwhile if's and else's should definitely be on the same line as
// their curly bracket
if(condition) {
instruction;
} else {
instruction;
}
// Otherwise you will end up like this if you want to stay consistent:
if (condition)
{
}
else
{
}
// And this wastes a lot of space for no reason. Also they can be nested.
// Use verbs for functions or methods
// A verb is basically a grammatical function, as such they should be used
// for function names. In the worst case add "do-..." to it, if you cannot
// find a better word for it, but make it clear that you are DOING something
// and the things you do something WITH should be nouns, like variables
// classes, constants
void do_your_mom();
uint32_t YourMom;
typedef struct {
int a;
int b;
char c;
} your_mom_t;
#define PEE_PEE_POO_POO 1337
If I think of more examples, I'll add it to the list. Also this is just an example – to show that you can deduce a good programming style from just a few core assumptions – it is not meant to be "this is the only true programming style", because it probably isn't, but it is to show that if somebody smarter than me tried, he probably could engineer the perfect formatting and there could be little that could be argued against with.
Lesson learnt: Use Lisp.