“Never attempt to teach a pig to sing; it wastes your time and annoys the pig.”

– Robert Heinlein

This is not actually about strange code, just some productive advice…

As you interact with more of other people’s code, you’ll find everyone has a distinct style. Not just in the flow of logic, or the names of functions and variables, but simply details of layout.

As long as you always pair up the curly braces and end every statement with a semicolon, C is otherwise nonjudgmental about what goes where. This contrasts with others like Python, which can be strict about consistent indentation, and also has a whole culture of favored coding practices.

These two versions of a C function are roughly equivalent:

void do_if_odd(uint16_t x) { if(x & 1) do_the_thing(); }

void do_if_odd(unsigned short x)
{
    if (x % 2)
    {
        do_the_thing();
	}
}

void do_if_odd(uint16_t x) { if(x & 1) do_the_thing(); }

void do_if_odd(unsigned short x)
{
    if (x % 2)
    {
        do_the_thing();
	}
}

One is packed tightly like a suitcase, the other spread out like an Apple store. One uses a bitwise AND to check for oddness, the other a modulo operator…but same result. The only functional difference is an obscure one: there might be rare platforms where uint16_t and unsigned short are different sizes. “Readable” is largely in the eye of the beholder; some will grasp program flow better when more is visible on screen, but generally the airy code will be kinder on newcomers. There are countless middle-grounds as well.

C Programmers sometimes get into heated debates about The Only Good And Proper Way To Structure Code™. Should indentation be performed with spaces or with tabs? Should the curly braces starting code blocks appear on their own line, or with the prior statement? Is goto in fact irredeemably evil?

Everyone has preferences. That’s healthy and fine! I get such a thrill when lining up comments in adjacent lines of code. But these are subjective things, you will always find dissenters.

If you’re contributing to an open source project, or are part of a team: the winningest strategy I’ve observed of top programmers—or maybe they’re just extremely jaded programmers—is don’t go there. The correct answer is: there is no One Answer™. Instead, within the scope of a project, adopt the conventions of the project lead, or a mutually agreed-upon style guide.

Stay flexible. Do what you enjoy in your own code, but in collaborative code, the most prolific are doing the work, not arguing over spaces or curly braces, or GIF vs JIF, or pineapple on pizza or tails on werewolves. Take the group conventions to heart and then do the work. Fix that bug. Add that feature. Stop reformatting code like you’re rearranging deck chairs and Do. The. Work.

In Adafruit libraries we’ve adopted the practices of using clang-format for consistently formatting C/C++ code (with default settings, nothing special), and doxygen for API documentation. If new code is written close to those conventions, it’s minimally disruptive to then filter it through those tools.

I’m quite certain that not a single person here 100% agrees with these tools’ formatting conventions…but it’s always at least adequate, consistent, and avoids religious debates. No time wasted, no pigs annoyed!