Don’t try to change the tabbing / bracing style

This is a guest post from Andrew Rondeau. Enjoy.

Dear New Developer,

Don’t show up an a new job and immediately try to change the tabbing and/or bracing style. This is especially important if the codebase you work on has a very consistent style that all of the other developers follow.

Why? Tabbing and bracing styles are really a matter of personal preference. What’s important is that the codebase is readable, and keeping a consistent tabbing and bracing style is more important than having your favorite style. Furthermore, because tabbing and bracing styles are really a matter of personal preference, arguing with the more senior developers about this topic is a waste of everyones’ time. The senior developers, or your manager, will probably assume that you have poor time management skills, or that you get obsessed with details that don’t matter.

And, yes: An interesting discussion can be had over the merits of tabs versus spaces, or the merits of braces before or after the newline. The problem is that some people really get irrationally attached to whichever style they are used to. These discussions don’t fix bugs or deliver features that the business needs to survive; thus, don’t waste time and stick with whatever tabbing and bracing style your codebase uses.

When is it important to discuss tabs versus spaces, or bracing styles, as a new developer? When a codebase has an inconsistent style, especially if it doesn’t match a team’s style guide! Politely point out to your manager, or lead, that there is a lot of inconsistent use of tabs and/or braces; and suggest a tool that will automatically reformat the code. Perhaps suggest a style that a well-known open-source project uses, or a well-known style guide published by Microsoft or Apple. At that point, it’s your manager or lead’s discretion if your team will adopt a new style.

If your team does agree to change the tabbing and/or bracing style, don’t do it gradually. Why? Again, a consistent style is more important than being able to write code with your preferred tabbing or bracing style. Inconsistent code is harder to read, and confuses people about what the established style really is. It also tempts people to stick with their preferred style, instead of whatever the team agreed to. Instead, use an automated tool to reformat the code.

— Andrew

Andrew is the desktop client architect for Syncplicity, a file synchronization product. Here’s his LinkedIn profile.

One thought on “Don’t try to change the tabbing / bracing style

  1. > What’s important is that the codebase is readable, and keeping a consistent tabbing and bracing style is more

    Agree.

    > If your team does agree to change the tabbing and/or bracing style, don’t do it gradually. … Instead, use an automated tool to reformat the code.

    I understand this point of view, but it is also important to mention that this destroys the history in your version control system (mercurial, subversion, git, fossil etc.). The annotate/blame tool will become useless and will point to a single person (often the junior developer who was assigned this *boring task*), you will lose the information why particular lines were written, by whom and when (of course, the information is still stored somewhere in the history, but is is practically inaccessible now). It will be difficult to distinguish important changes from formatting. And if you develop in multiple branches and merge or cherry-pick across them, the automatic process that usually runs smoothly will fail now and will require expensive human work… just because the older branches/versions have different formatting.

    The *correct* solution would require a complete history rewrite. Literally rewrite every single commit, reformat its code while keeping the *author*, *date* and *message* metadata unmodified. But: this is so many commits, so many years… in a distributed version control system, it changes the hashes, so if someone from outside references to them, this references will become invalid (e.g. links from external websites)… or there might be a bug in the formatting tool that makes some significant/logical changes in the code – then if a customer asks you for a „v3.0.0 with just a small fix“, he might get completely different version with many other changes… I am afraid that the risks are higher than benefits.

    > Perhaps suggest a style that a well-known open-source project uses, or a well-known style guide published by Microsoft or Apple.

    I recommend talking rather about [free software](https://www.gnu.org/philosophy/free-sw.html) than [open source](https://www.gnu.org/philosophy/open-source-misses-the-point.html) and avoid promoting [evil](https://www.gnu.org/proprietary/malware-microsoft.html) [corporations](https://www.gnu.org/proprietary/malware-apple.html).

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.