Some too Strong Opinions on Code Style

Code style may not be the most important part of programming, but it’s not meaningless. Good formatting can do wonders for code’s readability - and I have some kinda strong opinions on how it should be done.

Brace Placement⌗

There are 2 main ways of formatting braces - based on where the opening brace is placed. You can place it on the same line as the statement it links to (struct, function, if-else), or you can put it on the following line.

I always put it on the same line.

There’s no super important reason for this, I just think that this

void f() {
    // Code
}

looks infinitely better than this

void f()
{
    // Code
}

And that’s not even mentioning this atrocity

typedef struct 
{
    int n;
} S;

But for me, the worst offender is if-statements.

if (cond)
{
    // Branch
}
else
{
    // Branch
}

Just look at all that wasted space! All those lines that could’ve been saved by just not pressing return!

if (cond) {
    // Branch
} else {
    // Branch
}

Writing C with a formatter that automatically puts braces on a newline brings a tear to my eye every time autoformat kicks in.

Pointer Placement⌗

There are 2 ways to place the asterisk for a pointer type. Next to the type, and next to the identifier. (T* x & T *x).

I always prefer the former, but I actually have a reason this time.

When reading code, I tend to mentally break it apart into pieces based on whitespace. For example, int x = 42; will be broken down into the type (int), the name (x) and the value (42). When the asterisk is separated from the type, I end up having to backtrack in order to correctly understand it.

For example, int *x; is read by me as follows:

1. The type is int
2. The name is– wait no the type is int*
3. The name is x

Written as int* x, I read it as:

1. The type is int*
2. The name is x

The latter style is so much easier to read because the pointer is essentially a type modifier, so it’s easier to parse when it’s next to the thing it’s modifying.

Naming Rules⌗

This is the one which probably matters the least out of all the things here, but I think the ideal naming scheme I’ve come up with is interesting enough. to share. Who knows, maybe the next big programming language will end up using it by default.

• Variables are named in snake_case
• Constants are SCREAMING_SNAKE_CASE
• Functions/methods are camelCase
• Types (structs, enums & their variants, etc.) are PascalCase

The logic behind this set of rules is that capitals make something look like a proper noun, so more proper capitalisation = more important.

Alright, I may have made up the reasoning. But I feel like it’s nice to differentiate between different types of identifiers using casing rules, even if it doesn’t matter.

However⌗

Regardless of whether you agree with me or not, I think the more important thing is that code style is consistent. It’s better to stick with the consensus for formatting rules rather than doing your own thing for the sake of not making codebases look like frankensteined abominations with no clear rules.

The standard may not be ideal but it’s easier to understand code when the style is consistent.