The Bureau 14 coding rules

We don’t actually have “coding rules” at Bureau 14, at least, not in the sense you would expect them.

One one hand, we think it’s best to give as much freedom as possible to the developers and prevent rules to get in the way of evolution.

On the other hand, we don’t want our code to become a mess and need some easy to follow guidelines to help homogeneity and convergence.

So here I present to you, the official Bureau 14 coding rules!

The golden rule

I don’t want Bureau 14 to become the place where people say “I don’t know why it’s like that, it’s always been that way, just follow the procedure”. Ever. That’s why I’ve created this golden rule, back when I was alone in the company, in 2008, that applies to anyone, whether the job is to empty the trash or negotiate big deals:

You’ve been hired to solve problems and create wealth, not to follow rules. If something doesn’t make sense, it’s your duty to make sure it eventually does.

I never forget to repeat it to myself from time to time.

The constitution

This is our constitution. See that as the meta-rules, the Geist of how we work. A way to remember how we should organize ourselves and what we strive for. We never change the constitution except when we change it. You know what’s nice about democracy? It doesn’t apply here.

1. Keep it short, homogenous and aesthetically pleasing.
2. We release imperfect software.
3. Be extremely critical and even more positive.

The down to earth, non-negotiable, C++ rules

These rules are here to prevent useless and endless debate about how code should be indented and where braces belong.

We’re sorry if you don’t like them but at some point you have to accept you can’t satisfy all the fetishes. Most of these rules are automatically tested and will break the build if not abided to.

Life is tough, better get used to it.

• Use STLesque naming: lower case with underscores to separate words. CamelCase will be dealt with extreme prejudice.
• Macros are all upper case with underscores to separate words.
• We have a four spaces indentation. Make sure your editor writes spaces and not tabs. Four spaces. Exactly the number of hours you will spend in a pain amplifier if you ever forget that.
• Private variable members are prefixed by a single underscore.
• Global static variables are prefixed by two underscores. *”Private” namespaces are named “detail”.
• For general code organization and all that didn’t fit here, use common sense or the constitution in case of unavailability.

Rules of thumb

These are not rules but rather advices, guidelines. You are most guaranteed to find a code fragment that doesn’t “respect” these rules of thumb, generally accompanied by a comment with a decent amount of profanity.

• Feel free to experiment, but always document.
• All commits are peer-reviewed, but don’t wait commit time to discuss your work with your colleagues!
• If it’s not documented, it’s not implemented.
• Your local repository is local, experiment! Destroy everything! Pull back!
• Comment the why, not the what.
• Don’t write loops, use algorithms.
• Avoid object oriented programming.
• Don’t use exceptions, use error codes.
• You don’t need the virtual keyword.
• We have a build grid for a reason: so that you don’t have to worry about compilation time.
• You can’t write exhaustive tests, but you should write sensible tests. No test at all is unacceptable.
• There is no sanctuary: you can modify any part of the software if it makes sense.
• Winter is coming.