I work on a small team, around 10 devs. We have no coding standards at all. There are certain things that have become the norm but some ways of doing things are completely disparate. My big one is indentation. Some use tabs, some use spaces, some use a different number of spaces, which creates a huge problem. I often end up with conflicts when I merge because someone used their IDE to auto format and they use a different character to indent than I do. I don't care which we use I just want us all to use the same one.

Or else I'll open a file and some lines have curly brackets on the same line as the condition while others have them on the next line. Again, I don't mind which one so long as they are all the same.

I've brought up the issue of standards to my direct manager, one on one and in group meetings, and he is not overly concerned about it (there are several others who share the same view as myself). I brought up my specific concern about indentation characters and he thought a better solution would be to, "create some kind of script that could convert all that when we push/pull from the repo." I suspect that he doesn't want to change and this solution seems overly complicated and prone to maintenance issues down the road (also, this addresses only one manifestation of a larger issue).

Have any of you run into a similar situation at work? If so, how did you handle it? What would be some good points to help sell my boss on standards? Would starting a grass roots movement to create coding standards, among those of us who are interested, be a good idea? Am I being too particular, should I just let it go?

Thank you all for your time.

Note: Thanks everyone for the great feedback so far! To be clear, I don't want to dictate One Style To Rule Them All. I'm willing to concede my preferred way of doing something in favor of what suits everyone the best. I want consistency and I want this to be a democracy. I want it to be a group decision that everyone agrees on. True, not everyone will get their way, but I'm hoping that everyone will be mature enough to compromise for the betterment of the group.

Note 2: Some people are getting caught up in the two examples I gave above. I'm more after the heart of the matter. It manifests itself with many examples: naming conventions, huge functions that should be broken up, should something go in a util or service, should something be a constant or injected, should we all use different versions of a dependency or the same, should an interface be used for this case, how should unit tests be set up, what should be unit tested, (Java specific) should we use annotations or external config. I could go on.

  • 3
    Some merge tools give the option to ignore whitespace diffs. It wouldn't solve the root cause, but could mitigate the intermediate pain... Jul 18, 2011 at 13:44
  • 5
    Why don't you like your manager's solution of formatting the code when it gets pushed to source control? Jul 18, 2011 at 13:50
  • 5
    I think this is a social problem, not a technical problem. If the team can't agree on standards, IMO no amount of technology is going to help. Jul 18, 2011 at 14:13
  • 12
    EVERYBODY should use the IDE autoformat with the same settings. Just do it.
    – user1249
    Jul 18, 2011 at 19:23
  • 1
    @Thorbjørn - Agreed. We just issued global IDE settings yesterday. Jul 19, 2011 at 21:34

13 Answers 13


A co-worker and I had a similar problem on our team when we first joined (I joined the team first, he joined about a year later). There were no real code standards. We're a MS shop, and even the MS coding standards weren't used. We decided to lead by example. We sat down together and drafted a document that had all of our standards: IDE standards, naming standards, everything we could think of. Then he and I agreed to follow the standard explicitly. I sent an email to the team (from the both of us), and notified them that we had found a lack and we were going to address the lack with our document. We invited critique, ideas, comments, opinions. We received very little in the manner of feedback and only a little push back. He and I immediately started using the standards, and as we brought junior developers onto our projects we introduced them to the standard and they began using it. We have a few leads who were reluctant at first but have slowly begun using the standard for a great many things.

We found that many of the junior developers had recognized the same problem but were waiting for someone else to step up and make the decision. Once there was a plan to follow, many were eager to adopt it. The tough nuts to crack are the ones who refuse to code by any other means, and they'll usually code themselves out of the picture in the long run.

If you want standards, blaze the path. Come up with a suggested list of standards you think would benefit your team. Submit it to peers and leads for feedback. I'm sure other people on your team have similar ideas, but they probably lack the gumption to do anything about it. As Gandhi said, "You must be the change you wish to see in the world."

  • 4
    I love the idea of starting among those who agree! I'd add to it that the easier you make it to find and follow standards, the more likely it is that people will do so - make sure that if you have IDE formatting tools, the setup instructions and any config files are easy to find and the install is documented well. Jul 18, 2011 at 18:40
  • 1
    In short, hold yourself to a standard before you expect others to be held to the same standard. Start by identifying what most of your teams devs are using, and set your environment to do that.
    – Freiheit
    Jul 18, 2011 at 18:45
  • 2
    +1 This is exactly how we have handled the same situation. I've found that leading by example most often fixes many problems in a development shop--but you do have to have win buy in from others. If you're the only one blazing the path then you should probably re-evaluate the path in the first place.
    – Jduv
    Jul 18, 2011 at 19:19
  • 1
    Joel, this story has inspired my coworkers and I. We're picking up the torch using your story as a template. Jul 19, 2011 at 19:55
  • I agree partially with you start with one that agree, but I disagree with "We sat down together and drafted a document" developer shouldnt do this crap instead use a tool. You can use resharper or free alternative code maid, you can force it to reformat your code everytime you save file. Anyway I have work for company that force coding standard to insane level like sorting method by alphabet, grouping field by type and using region. it drove me off it feel like wasting half of my time.
    – kirie
    May 10, 2014 at 4:33

Standards shouldn't be something defined and enforced by a manager. The team as a whole should agree to standards. If they can't agree on a common set of standards, getting a manager to force standards upon them will fail.

You and the others who agree with you should lead by example. Start using the same coding standards, publish them, and promote them to the rest of the team and invite feedback on how to improve them.

Here's the important bit when trying to promote standards: make sure the focus isn't on finding the best way to do things, but rather on finding a consistent way of doing things. Much as some people might disagree, there is no one true brace style, no one true commenting style, etc. What makes code easier to read (and thus, easier to maintain) is a consistent style, no matter what it is.

  • 4
    I agree that the team needs to define the standards but ideally the manager should be the enforcer. If you don't have buy-in from the manager on the whole idea of having coding standards you should consider taking on that leadership role yourself (see Joel Etherton's answer).
    – semaj
    Jul 18, 2011 at 15:31
  • 3
    Well technically there is a One True Brace Style: en.wikipedia.org/wiki/Indent_style#Variant:_1TBS Jul 18, 2011 at 18:21
  • @semaj: I wholeheartedly disagree. It shouldn't be up to the manager at all. Not even slightly. Sep 5, 2011 at 0:37
  • On the other hand, you're a programming team, somebody's employees, not a hippie commune. Whose head rolls if the project fails? I guarantee somebody's does. If everybody is responsible, then nobody is. See this, this, this, etc. Dec 29, 2014 at 7:08
  • "Who's head rolls," I meant. Obviously... Dec 29, 2014 at 15:50

Can you show some evidence of the time you've wasted due to the problems this is causing?

If you are spending a significant amount of time working round these problems, or it's causing bugs that take time to fix, then this is a cost you can drastically reduce by adopting coding standards.

So keep a log of the problems you encounter and the time it takes to resolve them - both for you and (where you are aware of them) your colleagues.

Then when you've got a reasonable amount of data present it to your colleagues. They should see the benefit of adopting a standard. If not show the data to your boss and his boss. Show that by having coding standards you can save your company money and they should back you in getting them adopted.


On your particular situation, I think your boss's solution is a good one. Nobody has to change what they've been doing for their whole careers, and that's okay because the bits of code style that the compiler ignores don't matter as long as the code is readable. If everyone did an autoformat to their style when checking out and an autoformat to a standard style when checking in, all would be well. (Sadly I suggested that where I work and it was opposed on the grounds that the coder would no longer be writing the same exact code as the continuous integration server sees.)

I think coding standards are good when applied to places where it makes a real difference in code quality: for example, smallish methods, classes that have one clearly-stated responsibility, useful and accurate commenting for the harder bits, etc. Unfortunately, those aspects are harder to automatically check, but that's fundamental to software development. All you can really do is teach others good practices and teach yourself to read code with the brace on the wrong line.

  • 3
    I'm fine with the brace on whatever line. I get thrown off when both styles are in the same file. Makes it harder to scan. Jul 18, 2011 at 13:52
  • It drives me crazy, myself. But since I can't exactly reformat the whole code base, I just try to deal with it until such time as I can push for an automated solution.
    – jprete
    Jul 18, 2011 at 14:00

Regarding coding standards: I'll climb on board with almost everyone else in saying that coding standards are a "good thing" (versus no standards).

However, don't get carried away. I've worked on some projects that dictated a specific indentation style, right down to the number of characters (and when projects do go that far, they inevitably choose something stupid like 8 space indent). Don't sweat the small stuff.

A simple solution: Give the developers a limited set of choices for brace and indentation, but dictate that the brace style and indentation must be consistent across a module. (You do want foo.h and foo.cpp to follow the same style, don't you?) Maintainers must adapt to the existing style; they cannot rewrite a module to suit their whimsical style. Multiple styles within a module is just confusing and is a sign of sloppiness. When I see that nonsense it makes me wonder what else is wrong.

You might also want to think about banning tabs for indentation in the saved contents of a file. Most IDEs/editors do a reasonable job translating user-input tabs to spaces, and most have options for making that translation automatic. Many do a crappy job when the file already contains tabs, particularly a mixed bag of tabs and spaces.

All that said, I think you may have a deeper problem in your project. You mentioned problems with merging. If you find yourself needing to do a lot of merging it might be a sign of a bad partitioning of the project. Just as too many cooks spoil the broth, too many programmers operating on the same file spoil the project. Why are each of Joe, Susie, and you touching foo.cpp?

  • 3
    Or you could just use tabs and individual devs can make them whatever size they want.. Jul 18, 2011 at 18:24
  • 1
    @Brendan: In m experience that doesn't work. Programmers inevitably mix tabs and spaces to get their code to line up just so, particularly continued lines. That mixed mode space and tab garbage can look downright ugly with a different setting for tabs than the one used by the developer. Jul 18, 2011 at 23:45
  • 2
    I never said to mix them. Use just tabs. Now indentation looks however each dev wants it to. If you really need your code to line up "just right", then still use tabs for indentation, and then spaces after that to line it up (I consider this a waste of time). Jul 19, 2011 at 1:13
  • 2
    It is the spaces afterward that kill this idea. The "no tabs in source files" rule is common across many, many coding standards. There is a reason for it. Jul 19, 2011 at 12:35

This is one of the areas in which some research is done. Basically the main question is whether you're doing code reviews. Code reviews are without a doubt the most efficient means to improve code quality. (Source: Software Engineering Institute, CMU). It's certainly more efficient than an extra tester.

Now, code reviews benefit from a common coding standard, as that makes it easier to read other peoples code. That provides you with a two-step argument to introduce coding standards: in the end, it does make it cheaper to produce good code.


Since there are already "several others" who are with you on this, I would suggest an impromptu meeting. Invite all the devs, take a short while and figure out what things are bothering yourself and your colleagues day-to-day. Don't try to find specific solutions at first, just figure out what needs changing in the way you are all writing code at present.

Then, see if you can all agree on some basic concepts. The suggestion of using the same style within each module that @David Hammen brought up is a good start, and one I think most developers could readily agree to.

If, once you have that down pat, you feel that you can all agree on some basic style for when writing new code, that's a good addition. Focus on things that actually impact maintainability; naming issues would be high on my personal list because if you have half a dozen different naming styles in a single product of any notable complexity, it's going to become a headache very quickly, but again, focus on what you and your team feel is important. Draft a short document that everyone can at least agree to follow (even if they might have a different pet style themselves) and mail it to everyone on the team. Make it a "living" document, make sure to update it with time, but be sure to not make it too rigid and specific.

Unless your boss is involved in writing code, he should not worry too much about which exact style is adopted (provided that it focuses on readability and maintainability), but he should be able to see the benefits of everyone on the team following a common style when writing code.


There are some things that are painful. Most painful is an IDE that automatically reformats code, combined with developers that set up their IDEs in different ways. Every time you compare code you have hundred changes after someone with different settings edited the code. That's unacceptable. Here you need to bang everyone's heads together, agree on a set of settings, and reject any checkins by anyone using different settings. If I change a single line of code, the diffs should show a single line of code changed, and not hundreds.

Everything else is either harmless, or there are better ways to do things that others can be convinced of. Here the rule should be: Don't mess with other people's code unless you really improve it. And a mix of style A and style B is always worse than both style A or style B.

Make sure you follow best practice. Which is different per language. But there you don't need standards (which may have been written by someone well-meaning but not actually that knowledgable), but everyone should try to give good examples.

Definitely avoid power struggles. There is nothing worse than some little Hitler in your team trying to force everyone to his will. And that's unfortunately the guy who will volunteer to write your coding standards :-(

  • Different standards from different developers on the same project leads to hair loss. Create standard settings for the project. Have every dev import those settings. Period. This is easy with tools like the Visual Studio IDE. If you have devs who insist on using Emacs (which I like an awful lot, myself) or whatever, they're responsible to adhere to the standard. Use a pretty print routine to reformat the code for check-in. The goal is uniform code that is easy for everybody to comprehend, not individual artistic style in everybody's individual source code files. Dec 29, 2014 at 7:15

All the examples you have given are basically about whitespace and formatting. If that's the biggest problem, I sort of agree with your manager: it's not that big of a deal.

Where standards are really very useful is with naming things and reducing complexity. How to name identifiers, classes, where to put them, etc. Keeping names consistent is extremely important, especially in a large project. Rules for reducing complexity include keeping functions under a certain number of lines (break it out into smaller functions), or keeping parameter lists below a certain number of arguments (maybe you should be bundling them into an object and passing that around).

If a specific developer on your team writes code that is harder to understand/debug because it includes a lot of long chunks of code with single letter variable names, that is a good reason to adopt some standards, and not something that can be fixed with a script. That's a good thing to point out (tactfully) as an thing that standards can improve.

Another reason your manager might not see it as a problem is that you don't actually read each others' code very often. That can happen when everybody has their own area of the code and doesn't venture outside of it too much. That works pretty well until somebody leaves the organization, which could happen for a variety of good or bad reasons. Standards that help readability will make it easier for a new developer to take over maintenance of a piece of code.


conflicts when I merge because someone used their IDE to auto format and they use a different character to indent than I do

sounds like this is your problem, not the formatting, but the re-formatting. This is a huge problem for SCMs and the advice is simple: don't do it. So next time someone re-formats all the spaces to tabs, or refactors the curly brackets to their preferred style, you need to slap them down. Make them do the merge instead; stand over them looking disapproving of the waste of time their thoughtlessness has caused.

The alternative is to put a pre-commit formatter in, that always re-formats all code to the standard style before checkin. If you have a team of devs who re-format as a matter of course, then this is a good option - the SCM will always see the same format, so the deltas will be small and nice to merge.


When someone suggests a new coding standard where I work we vote on it. If it gets a majority vote it is accepted otherwise its rejected. If you don't do this, you won't get buy in on your standards and they won't be used even if they are documented.


As of your specific issue, your best bet will probably be beginning with Joel's suggestion and leading by example. Gather 1 or 2 programmers who care about this, get to an agreement and you'll have some force to impose over the lazy ones.

Now, for the generic issue, I find it best to simply modulate. Each person gets a different file, if you have to give maintanence to a file you keep its coding standards intact, even if it's different from the other. Need to write in the same file? Make a subset file and include it instead.


Don't try this!

Lead by counter example. Try to make your code format as horrible as you can, and check in lots horribly formatted changes to other peoples' pretty code. When the (inevitable) reaction occurs, say that what you are doing is fine because there is no coding standard.

If you don't get lynched by your coworkers (!!), you may end up with a coding standard.

Obviously, this is a high risk strategy ... :-)

  • Actually, there are a couple people trying this one out now and many who have used this strategy before I started there. Despite their best efforts, no standards have emerged thus far :( Jul 19, 2011 at 10:57
  • @Josh Johnson - they obviously haven't tried hard enough. Consider using ROT-13 on all identifiers :-)
    – Stephen C
    Jul 30, 2011 at 3:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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