17

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:

somefunction()
{
    //...
}

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)?

toniedzwiedz
  • 1,345
  • 4
  • 16
  • 25
dukeofgaming
  • 13,943
  • 6
  • 50
  • 77
  • 2
    Not sure where the "Microsoft IDE" comment comes from. The VS simply uses the rules you tell it to use; nothing to do with paradigms! If you hadn't said that, I'd have found it much easier to sympathise. – Mr Lister Jan 16 '13 at 07:22
  • 2
    @MrLister True, I think he meant that it's the default bracketing style in VS. – Zachary Yates Jan 16 '13 at 07:27
  • 1
    I write like I want an format the code with eclipse or webstorm afterwards. Ctrl+f Ctrl+s and done. – K.. Jan 16 '13 at 08:45
  • 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 Jan 16 '13 at 08:49
  • 55
    You are omitting the **clearly required** whitespace between the end of the function declaration and the curly bracket! You must burn! – pap Jan 16 '13 at 09:05
  • Yeah, their coding standard is correct and yours is bad. Kidding! I prefer the way they want you to do it, mainly because it gives a little breathing room. Pure K&R style is too cramped and hard to look at. I used your style a long time ago until I realized that cramming source onto the screen is counterproductive. – doug65536 Jan 16 '13 at 09:18
  • It's personal preference if you have the choice, or as in your case it's the house style so you have to suck it up. Using the style that you want to use would drive *me* nuts, personally. – Alan B Jan 16 '13 at 09:27
  • 1
    If you end up with many parameters, or parameters with long names you may loose sight of the curly brace, at which point the line-feed before the curly brace helps. – Simon Gibbs Jan 16 '13 at 09:34
  • 2
    While I personally agree with your preference, this is really just a trivial detail that's not worth discussing at all. At least it is trivial assuming you're writing in a "normal" procedural/OO style; things look rather different if you make heavy use of very small local functions, which usually only makes sense in the form of lambdas. If supported at all, I reckon your standard doesn't forbid "inlining" the opening brace for those, does it? – leftaroundabout Jan 16 '13 at 09:58
  • Just to be clear: are you talking about all {...} blocks, or only function definitions? – Beni Cherniavsky-Paskin Jan 16 '13 at 10:02
  • 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 Jan 16 '13 at 10:02
  • It's mainly preference, but the way they want it allows you to comment out the first line (function declaration, control statement or whatever) and still have a syntactical correct code block. – Flygenring Jan 16 '13 at 10:23
  • Code standards promote endless discussions. I think everybody here is right when they tell you to suck it up or else you are going to have new enemies at work if you keep complaining about it. Everybody should follow standards used by the company if they were defined. If the company does not have a standard you can suggest one standard to leaders. If he/she does not care with this, keep walking (with mouth shut) ;-) – Junior Mayhé Jan 16 '13 at 10:36
  • 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 Jan 16 '13 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 Jan 16 '13 at 11:42
  • 1
    `Used by people who come from a Microsoft IDE background` Clearly not. LibreOffice also uses this style. – ignis Jan 16 '13 at 11:52
  • 1
    Surely this should be closed? I don't see any interesting or original discussion here. – Mike Weller Jan 16 '13 at 12:39
  • 4
    The best way to get over it: realize that there are others who are equally annoyed by your favored style, and that one way or another, somebody had to win. – Michael Shaw Jan 16 '13 at 13:49
  • 2
    Remind yourself that code written with The Wrong Brace Style, ugly as it is, is *much* better than code written with mix of The Wrong Brace Style and The Right Brace Style. – Keith Thompson Jan 16 '13 at 16:12
  • 1
    @MikeWeller Ha, you're funny. – Mr Lister Jan 16 '13 at 18:55
  • 2
    Evangelize that the codebase be rewritten in Python. – Stefan Majewsky Jan 18 '13 at 21:16
  • 1
    The style you hate does NOT bloat the *compiled* code in any way. – Craig Tullis Dec 29 '14 at 07:54
  • Putting brackets on newlines was, is, and always will be the best way to do it! :) – LuckyLuc Apr 22 '22 at 18:15

15 Answers15

67

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.

Cromulent
  • 957
  • 1
  • 6
  • 13
  • 5
    I think he's asking **how** he should get over it. Which is actually a very different question. – Zachary Yates Jan 16 '13 at 07:07
  • 19
    Not following the standard creates a worse problem, and annoys _everyone_. "Suck it up" indeed! – Frank Shearar Jan 16 '13 at 07:07
  • 2
    I agree. You just have to deal with it. – Cody Jan 16 '13 at 07:51
  • 3
    Honestly, It would frustrate me, too, but "suck it up" is the right answer, unfortunately. – Sulthan Jan 16 '13 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 Mar 26 '22 at 14:41
45

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?

RegDwight
  • 527
  • 1
  • 5
  • 12
scrwtp
  • 4,532
  • 1
  • 24
  • 29
  • 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. –  Jan 16 '13 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 Jan 16 '13 at 11:22
  • 15
    I would like to add that Linus goes nuts if you format git commit messages "incorrectly" http://www.wired.com/wiredenterprise/2012/05/torvalds_github/ – Giles Roberts Jan 16 '13 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! –  Jun 26 '13 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 Sep 13 '13 at 07:15
27

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.
Community
  • 1
Zachary Yates
  • 1,776
  • 13
  • 16
  • 7
    +1 for (3), bonus points if you set it up as a post-pull/pre-push hook for SCM you're on. – Martin Green Jan 16 '13 at 08: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 Dec 03 '14 at 18:56
16

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.

mouviciel
  • 15,473
  • 1
  • 37
  • 64
8

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.

Kyle Jones
  • 229
  • 1
  • 2
  • 5
  • 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 Jan 16 '13 at 09: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 Jan 16 '13 at 09: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. – Carson63000 Jan 16 '13 at 12:03
8

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.

Pieter B
  • 12,867
  • 1
  • 40
  • 65
5

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.

Andrew
  • 2,018
  • 2
  • 16
  • 27
4

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.

Caleb
  • 38,959
  • 8
  • 94
  • 152
  • "Get involved in a language standardization effort ... Have the good sense to get off the language standardization effort as quickly as possible" -- http://norvig.com/21-days.html – Beni Cherniavsky-Paskin Jan 16 '13 at 10:09
3

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.

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

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.

Jaydee
  • 2,667
  • 1
  • 18
  • 17
2

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.

Firedragon
  • 209
  • 1
  • 7
  • 1
    As stated in the question, the question really isn't about the specific standard, so your first paragraph isn't germane. – Caleb Jan 16 '13 at 09:07
2

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

Beni Cherniavsky-Paskin
  • 180
  • 1
  • 6
0

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.

guillaume31
  • 8,358
  • 22
  • 33
-2

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.

Anon
  • 1
-5

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.

Manoj R
  • 4,076
  • 22
  • 30
  • 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 Jan 16 '13 at 08: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 Jan 16 '13 at 09: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 Jan 16 '13 at 09:28