If you want to get over this — there was a quote by Torvalds:

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Now consider, where does it put programmers who worry about such a minor thing like bracing style enforced by their code standard? Is your codebase otherwise so pristine that bracing is the only issue worth the time to argue about?

Some people like it your way and other people don’t. Either way someone is going to be annoyed. It is just your turn this time. Suck it up and get on with the job.

Is the team’s standard documented? If it is, are there any reasons in the style guide? Honestly, I’ve had to suck it up a ton of times and get real work done. There are worse problems to have, but I feel you — it still rankled (I agree with you on the style, by the way).

What helped me get through it:

1. Realized that there are real benefits to a single style (no matter what it is). Or at least a bunch of people think so.
2. Exactly what you just did, write out why it feels wrong, so you can posit the argument well in the future.
3. Use a styling tool for god’s sake, it will save your sanity. Resharper, CodeMaid, StyleCop, JSLint, CheckStyle, etc. … even Visual Studio will do it for you.
4. Kick ass on this project and be ready for the next when you can set the standards.

The superiority of one convention over the other is *clearly arbitrary*.

The readability issues you face, or your team mates would face with your standard, are only a psychological resistance to change.

The objective readability argument is in favour of *consistency* over the whole code base.

Think back to a time when you were sure that you were right about something and over a period of time realized that you were wrong, or at least that you were overreacting all those years ago. Consider the possibility that you might be wrong again, and give the new coding standard or process time to convince you.

My own standards rage when I was fairly new to coding (say five years into my career) was whether multiword identifiers should be WrittenLikeThis or written_like_this. I won’t even say which one I lked, but the point is that after some time I changed sides and after some more time I didn’t care either way.

The standard difference you’re describing with the curly braces is largely arbitrary. Both ways are equally good ways and for a company, as long as everyone does it the same it’s all good.

The “clearly superior” you’re are talking about is the kind of superior that people talk about when they talk about things “they’re used to”.

You’ll get used to it soon enough and in a year or so, the other way will be “clearly superior”.

So in short: deal with it.

This particular subject amounts to a Religious War between those who prefer one style over the other. Very few people are ambivalent…

Ultimately, neither is right and neither is wrong.

Style guides and coding standards exist for a number of reasons – and one key aspect is to ensure uniformity of layout, which aims to reduce the number of obvious errors, and improve maintainability.

Am I the only one that struggles with an opinionated stance against a
specific standard?

The short answer is “No” you are not the only one. But there are more important things to worry about. Even in standards that one has input to, there will always be compromise – witness some of the aspects that have made it into C99 and C12 that make no sense to me.

Even MISRA-C (which I have direct influence over) contains items that personally I don’t agree with – but I can understand why others feel the justification for.

how have you gotten over these?

And that therein lies the answer – rather than focus on why you don’t personally like it, try and understand why the person/people who agreed it did so.

Rules are usually introduced (in a closing stable door after horse has bolted kind of way) to address a previous problem. And if the rule is still nonsensical, talk to the standard owner and try and “educate” them.

Am I the only one that struggles with an opinionated stance against a specific standard?

Of course not. Meetings to determine coding standards are horrible! They drag on for hours and participants become personally invested in getting their own favorite (and invariably wrong, except for mine) idiosyncrasies enshrined in the standard. By the end, nobody is happy with the result. If anything can be worse than the coding standards meeting, it’s the formal code review meetings in the several months that follow the determination of the standard: some people try to adopt the standard, while others (intentionally or not) ignore it, and you get hours of feedback like: On lines 132, 142, 145, 181, 195, and 221 of SillyFileConverter.cpp you put the opening brace on the same line when the coding standard clearly says that it should be on the following line!

how have you gotten over these?

In their own way, the meetings help. Even if you sympathize entirely with the guy who left the opening brace on the same line as the conditional, or whatever, you will nevertheless become annoyed at him for wasting your time by not just sucking it up and following the stupid standard. If the guy is a curmudgeon and does the same thing over and over again, it becomes even more annoying. Being annoyed at that behavior makes it that much easier to justify writing in a style that’s a little different from what you’d prefer — you certainly don’t want to be that guy, after all.

Even if you’re not subjected to interminable formal code reviews, you can try to review your own code specifically for compliance with the standard. It doesn’t matter what you think of the standard, you’re just comparing what you’ve written to what the standard says. If you ding yourself every time you fail to comply, that may provide some of the negative feedback that you need to help you adopt the standard.

I think you just need to get on with it. I will try to address your notes with my own opinions:

• Bloats Code

  One extra line of code is not bloating code at all, unless you are writing 100’s of methods in a single class, that will add hundreds of extra lines. Then again if you have hundreds of methods in a single class you have another problem altogether.

• Harder to Type

  I can’t disagree with you any more about this, you have to press the return key to get to the next line anyway. What about it is harder to type?

• Harder to read

  I feel like each line in a piece of code should have a specific function. Following this you would need to define the method name in one line, then the open and close braces on their own separate lines.

• Used by people who come from a MS IDE background

  Uhh…..ok?

In summary it seems like you are nitpicking about being a .Net developer as opposed to any other type of developer as if its inferior because they used an IDE which defaults to this standard.

With this kind of thing I remember Gulliver in Lilliput. The Lilliputians had been fighting a war over which end to open a boiled egg. (The original big endian, little endian fight).

Take it as an opportunity to laugh at yourself, they don’t really come often enough in business.

A formatter + check in hook is a good start. But it’s not enough, since what you write is not as important as what you stare at all day. In some situations, the approach of Emacs’ Glasses mode – keep files in their style but display closer to your style – is attractive.

My experience with it – facing exactly the issue it was written for, CamelCaps vs underscore_separated – was that it quickly became more annoying than helpful, but for a couple weeks it smoothed my transition to (grudgingly) accepting the company’s style, as well as provided an outlet to channel my anger (“ah I hate it, let me adjust the settings again… there, at least I did something“) 😉

Anyway, Glasses mode doesn’t handle brace placement, you likely don’t use Emacs, and don’t read code exclusively in your editor 🙁
But the last point is also an opportunity – if you read code most of the time in a separate tool, you can hack that to convert styles without worrying about round-trip reformatting noise – because it’s read-only! Specifically, if you read code in some web interface(s), use Greasemonkey.

Here are some easier ideas for mild mitigation:

• Choose a wider but not so high font, to reclaim the lost screen lines.

  • Use full-screen more often, if available.

• Set up braces to be highlighted in a subtle color (and smaller font?), making them less visible than the rest of the code. Indentation should be enough for reading, esp. with the empty space from { lines…

• Make sure your editor highlights matching opening brace when you’re over } – might help a bit when your eyes instinctively go to the wrong place.

• Re “harder to type”: get a real editor, configure it to open a new line automatically when you press {.

Your particular example is unfortunate as it is one that some will agree with and some won’t. I disagree with your arguments against for example and I am sure so will many others, just as I am sure many others will agree with them. It nearly makes me think the question should be closed as it is so subjective.

However the question on how to deal with a standard you don’t agree with is possible more answerable. I think the answer is that where styling guidelines exist and are agreed and have been used then the answer is just to grin, bear it and just deal with it. Consider that having consistency is more important. If the guideline is inaccurate or wrong there can be an argument for change but this is stylistic so there is no argument really apart from personal preference.

I came from a Java background originally so followed the standard you mentioned. I then moved to more C++ and C# where the style you hate is used. But it has no right or wrong answer. What is more important is having a standard followed by everyone. If a coding standard is stylistic like this and isn’t clearly wrong then trying to argue it will just cause friction in the team.

Live with it.

This is clearly cosmetics and does not change anything about the quality of the code or your productivity as a developer. Nothing worth starting an argument over.

For that kind of coding standard, I’d pick consistency across the code base and readability over any particular (even well-reasoned) “religious” approach any day.

Thinking of it as a democratic decision of a majority of the team members about a not-so-important problem may help you get over it.

It’s the standard:

http://doh-san.blogspot.com/2005/10/five-monkeys.html

Most of the one’s saying “its the standard” are following the “five monkeys” principle.

Just go ahead and use the style you want. Then use some code beautifier to change the code in standard format, or right your own small application which will convert the code from your style to the given standard style. Use the beautifier before checking in the code.
You can also do the reverse to change the checked in code from the standard format to your format, when you are working on it.