Disclaimer: Not as exaggerated as the title suggests, but it still makes me uncomfortable. I'm just going to express honestly, so take it with a grain of salt. Just pretend that I'm talking about that coding standard that you don't like working with.

Edit: The fact that I don't like it, doesn't mean I don't use it or enforce it.

I decided to ask this question in the spirit of how to get over a standard you don't like, not to get help on how to better argue how it can be changed (although any comments regarding this last part is appreciated). Besides, I work in a big company and such a change of something that has lived for so long and that matters so little is unlikely.

The standard is the opening-curly-brace-on-dedicated-line standard:


Instead of the *clearly superior* (note the joking/frustrated tone):

somefunction() {

My personal arguments against the standard:

  • It bloats code: extra unnecessary lines
  • Harder to type: although probably this is just me struggling with the standard, I know one extra keystroke isn't that bad.
  • Not easier to read: I start reading a function declaration, if statement, or any other scope-stacking statement and I already don't have to look for an opening brace. Nested blocks with this standard just make me angry for some reason.
  • Used by people who come from a Microsoft IDE background: I think there should be an argumented reason (or more) behind a standard, not just take it in by paradigm.

Their arguments (and my way of internally retorting to them):

  • Easier to read because you can see where blocks start and end right away: I cannot understand this, what good is the block if you don't know what it is owned by, so then you have to read backwards.
  • I used it in a Microsoft IDE and I liked it: Uhh... ok?
  • It is in the standard: *cringes*

Am I the only one that struggles with an opinionated stance against a specific standard?, how have you gotten over these?, what is your opinion on what this particular standard should be (just for fun)?

  • 6
    for how long do you use the standard you "hate"? and do you use other standards "in parallel"? I mean, could it be just a matter of getting used to it? Have to admit I used to hate the same standard, but after about a year writing exclusively that way this hate has gone away completely
    – gnat
    Commented Jan 16, 2013 at 8:49
  • 55
    You are omitting the clearly required whitespace between the end of the function declaration and the curly bracket! You must burn!
    – pap
    Commented Jan 16, 2013 at 9:05
  • 5
    Live with it. That's a really, really minor problem. Be happy that that's the only thing bothering you. If you change the language you should also be able to adjust to the new style. So working for some weeks with it should fix this feeling that it's "wrong".
    – schlingel
    Commented Jan 16, 2013 at 10:02
  • 8
    Used by people who come from a Microsoft IDE background It's not a Microsoft thing, e.g. the Linux Kernel and K&R use the same style.
    – Lucas
    Commented Jan 16, 2013 at 11:19
  • 5
    If you expend all of your energy getting all raged out about the trivial, you're not going to have any left for the things that actually matter.
    – Blrfl
    Commented Jan 16, 2013 at 11:42

15 Answers 15


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?

  • 2
    I agree entirely. If you've solved all the other problems and deciding where to put the curlies is the most important thing remaining, you're doing better than every other software project out there.
    – user4051
    Commented Jan 16, 2013 at 10:50
  • 4
    Is your codebase otherwise so pristine that bracing is the only issue worth the time to argue about? - This would be a rhetorical question - such a codebase has never existed in history!
    – MattDavey
    Commented Jan 16, 2013 at 11:22
  • 15
    I would like to add that Linus goes nuts if you format git commit messages "incorrectly" wired.com/wiredenterprise/2012/05/torvalds_github Commented Jan 16, 2013 at 11:35
  • That's because he was commenting on the fact that you're going into a project, you respect the project's style guide and submit proposals to change it...otherwise stick to their style!
    – user7433
    Commented Jun 26, 2013 at 15:57
  • 1
    @GilesRoberts: Linus goes nuts if you format git commit messages "incorrectly", because it does not work with the established review process. One that works well for the project for 20 years and involves hundreds of people. Some process rules are much more important than code formatting ones.
    – Jan Hudec
    Commented Sep 13, 2013 at 7:15

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.

  • 5
    I think he's asking how he should get over it. Which is actually a very different question. Commented Jan 16, 2013 at 7:07
  • 19
    Not following the standard creates a worse problem, and annoys everyone. "Suck it up" indeed! Commented Jan 16, 2013 at 7:07
  • 2
    I agree. You just have to deal with it.
    – Cody
    Commented Jan 16, 2013 at 7:51
  • 3
    Honestly, It would frustrate me, too, but "suck it up" is the right answer, unfortunately.
    – Sulthan
    Commented Jan 16, 2013 at 10:12
  • I know this answer is 9 years old, but I have to say, this DID answer his question, and should be the accepted answer. Q: "How do I deal with it?" A: "You suck it up." 𝘛𝘩𝘢𝘵 is how you deal with it. Standards are like that. They're put in place because not everyone does them naturally. Therefore some people will experience friction. And if the question is really "How do I suck it up when faced when something I hate?", then it's really not a software-engineering question in the first place and belongs in a forum about psych or the workplace.
    – Aiken Drum
    Commented Mar 26, 2022 at 14:41

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.
  • 7
    +1 for (3), bonus points if you set it up as a post-pull/pre-push hook for SCM you're on. Commented Jan 16, 2013 at 8:49
  • 1
    Styling tools make this problem go away and make people put their money where their mouth is. If you truly looooooove curly braces a particular way, then you go change your styling configuration to make it all warm and cozy for yourself. Otherwise, shut your mouth can get coding.
    – Calphool
    Commented Dec 3, 2014 at 18:56

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.

  • "only" a psychological resistance to change? Psychological resistances to change can be quite big. Commented Sep 13, 2013 at 10:21

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.

  • Yes, I'm torn between like_this and likeThis as well. I'm leaning toward the all-lowercase style lately, it's just plain clearer to read.
    – doug65536
    Commented Jan 16, 2013 at 9:22
  • 1
    Of course, now I'm stuck with likeThis in some projects. Oh well, naming conventions aren't very important in the grand scheme of things.
    – doug65536
    Commented Jan 16, 2013 at 9:31
  • 1
    Exactly. It doesn't matter in the slightest which line the opening brace is on. It doesn't matter in the slightest whether you write MultiWordIdentifiers or multi_word_identifiers. Whatever standard your company uses, go with it, and in a couple of months you'll find it hard to remember you ever wanted to do it the other way. Commented Jan 16, 2013 at 12:03

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.

  • a clearly superior answer
    – Mawg
    Commented Dec 3, 2014 at 15:20

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.

  • "Get involved in a language standardization effort ... Have the good sense to get off the language standardization effort as quickly as possible" -- norvig.com/21-days.html Commented Jan 16, 2013 at 10:09

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


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.

  • 1
    -1 I agree on all points, but I don't think any opinion on each of the various points is particularly helpful.
    – Caleb
    Commented Jan 16, 2013 at 9:01

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.


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.

  • 1
    As stated in the question, the question really isn't about the specific standard, so your first paragraph isn't germane.
    – Caleb
    Commented Jan 16, 2013 at 9:07

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 {.


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:


Most of the one's saying "its the standard" are following the "five monkeys" principle.

  • 1
    could you please explain how does that answer the question?
    – gnat
    Commented Jan 16, 2013 at 11:43
  • Isn't it apparent?
    – Mawg
    Commented Dec 3, 2014 at 15:23

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.

  • 2
    -1 The point of the question is how can I get over this?, but your advice boils down to don't try to get over it, just keep doing it your way. That doesn't seem helpful. It's also not very practical -- using a prettyprinter creates the possibility of collateral damage, i.e. after converting to your preferred format and back again, many lines may not be exactly the same even if they mean exactly the same thing. That creates a lot of trouble for people looking through different versions trying to find out what really changed.
    – Caleb
    Commented Jan 16, 2013 at 8:40
  • @Caleb - It may possible that your experience of using prettyprinter is different. We are using Atristic Style and no one has complaints about it.
    – Manoj R
    Commented Jan 16, 2013 at 9:15
  • 9
    Any serious software development is going to use a source control system. Introducing differences that aren't important will cause problems and make people viewing the diff(s) annoyed - or worse, cause check-in conflicts.
    – doug65536
    Commented Jan 16, 2013 at 9:28

Not the answer you're looking for? Browse other questions tagged or ask your own question.