Stories about Software


How to Get Developers to Adopt a Coding Standard

Editorial Note: I originally wrote this post for the NDepend blog. Head over to their site and check out the original, here.  While you’re there, have a look around at the other posts; if you enjoy static analysis, you’ll enjoy what’s there.

If you’re a manager, there’s a decent chance that the subject of coding standards makes you want to bang your head against a wall repeatedly.  If you’re a developer, you can probably understand why this is true of your manager, if you think about it.

The group coding standard has the following properties.

  • It’s extremely technical and granular.
  • Developers tend to squabble about it.
  • If it produces any business value, it does so obliquely and theoretically, from management’s perspective.

Thus, if I’m a manager, there’s this inscrutable document out there that causes my team to argue, and whose existence I must take on faith to be a good thing.  As you can see, it doesn’t start out on my good side.

Does It Matter?

There are all manner of opinions and arguments to be found on the internet as to why a coding standard matters (or doesn’t).  I’ve wrote about the subject myself from time to time.  So, without belaboring the point, I’ll make the quick business case for it.

The purpose of a coding standard, at its core, is twofold:

  1. It promotes maintainability by making all code look similar and familiar to all developers.
  2. It standardizes approaches that promote correct code (and avoid incorrect code).

Thus, on the whole, the coding standard makes the total cost of ownership of the codebase decrease by some amount ranging between 0 and “indeterminate.”  As an outside party, you simply have to take on faith that there is an ROI and that the amount of time wasted in arguments, complaining, and compliance is offset by the reduced troubleshooting and onboarding times.

And, in my experience, it generally is.  Notwithstanding pouting and bickering that happens early in the project and makes life unpleasant, it’s better to have these things than not to have them.  The key, then, becomes minimizing the cost of having the standard.  And you do this by securing compliance with the least amount of heartburn for all involved.

So how do you do that?  How do you convince the developers to buy in with a minimum of resistance and friction?


Understand Your Personnel

The first thing you need to do is take stock of your team’s dynamic and understand the impact that a relatively bureaucratic-by-nature institution will have on them.  Introducing a coding standard to a development team is like introducing an “appropriate decoration policy” to a neighborhood of houses — some team members will be apathetic, some will be enthusiastic about telling everyone how to work, and some will be resentful of any meddling in what they do.

With this in mind, do not, for instance, allow your most meddlesome or irksome team member to have free reign.  Instead, understand your team and facilitate an introduction of the concept in a way that will minimize friction.  If you have a natural leader admired by all, perhaps that should be the person to introduce it.  If you have a team member that will object to any suggestion posed by others, task him with making the suggestions instead.  You know the team and its dynamic, so use this to be a facilitation enabler.

Limit the Scope

The next important consideration for buy-in is to limit the standard, especially at first, to things that demonstrably solve problems.  Resist the impulse to google around until you find some 50 page document on the internet, and then to take that and modify it.  Less is more here.

In my experience, the standard should contain items that solve a problem seen in the past.  For instance, if the codebase has historically had two disjoint variable naming schemes, then standardization will help.  If, however, the team has not struggled with this, then there’s no reason to introduce a rule.  You’ll get all of the annoyance from the team with none of the benefit.

Automate, Automate, Automate

The two pieces of advice that I’ve offered up to this point orient a lot around soft skills.  Manage personalities and limit opportunities for discord and, hopefully, the team will willingly adopt the standard.  And, yet, it’s still possible that they won’t.

You might have good faith efforts, but people are forgetful.  You might have annoyed, half-hearted efforts only if people do not buy in.  And when that happens, the inevitable bickering starts, and you start to want to bang your head against the wall that I mentioned earlier.  Arguments ensue.  One team member appoints himself “standards cop” and starts hassling the others from a position of self-righteousness.  Another team member adopts the passive-aggressive, “too cool to care” position.  It can be a mess and a headache.

Unless, of course, you make such things impossible.  There’s a great piece of advice that I’ve heard before, and it applies well to people management and new technique adoption both at the same time.  Build a system, and, when things go wrong, blame the system.

When it comes to a coding standard, here is what you can do.  First, make sure that you’re practicing continuous integration and that you have a build machine.  With that in place, take your nascent coding standard and use a static analysis tool to analyze the code and render a “compliant or not” verdict.  From there, you can just add this analysis to the build, meaning that non-compliance causes a broken build.

In one fell swoop, you’ve transformed the coding standard from “annoying afterthought requiring nagging” to “just part of making software that works.”  There’s no need to send angry emails — developers literally cannot call their work done until it is compliant.

Not only does this ensure that the standard is followed, but it pretty much eliminates any sustained friction among team members.  They may be initially annoyed, but after the build integration, their annoyance, if it exists, will be directed at the build.  Or, to put it another way, they’ll blame the system instead of each other.

Adoption of a coding standard can be a tricky goal, but with automation via static analysis, it’s really kind of a gimme.

  • Noam

    Great post. Loved the idea of adding it to the build.
    How do you deal with peer code review and irksome co workers? any trick?

    • I think that’s probably a blog posts’ worth of topic material, right there. I’m adding it to my Trello backlog of topics 🙂

      • What is this Trello backlog? Does it work elsewhere not only in Disqus?

        • The tool is the site trello: http://trello.com

          There’s no relation to the commenting section, per se. It’s where I keep a backlog of reader questions that people ask, picking from it whenever I do a reader question post.

    • There are two kinds of coding standards:
      1) really smart ones enhancing future development and understandabilty of the project;
      2) invented by stupid team leaders in order display their power to embitter the life of their expert programmer underlings.

      • Noam

        could you give examples for both?

        • Dar Brett

          The Linux coding style guide vs the GNU Coding Standard.

          Not that I’d go as far as to say the GNU coding standard is entirely bad, but if I saw a company style guide that in depth I’d really doubt anyone would follow any of it.

        • 1) a) Stan Sieler: How to write readable pascal programs
          b) The “Hungarian notation” stackoverflow.com/questions/202107/good-examples-of-hungarian-notation
          2) Personal experience of mobbing when a guy with unfinished programming education became my system manager. He managed to fire three of us and transfer the task to his incompetetent friends.

  • JHelp

    What if standard are wrong and make mess ?

    • What qualifies a standard as “wrong”? And regarding messes, if you’re doing something — anything — that makes a mess, I’d suggest stopping that thing.

      • JHelp

        And example of wrong standard in Java is the use of anonymous class (Lambda didn’t solved the issue). A good architecture solve this nightmare for memory, performance, maintenance and code easy to read and find information. It became standard because lot of guy used it. But its not because lot of guy jump inside the fire that is a good idea to follow them.

  • Kirk W

    Wow, the #3 reason for the coding standards for us, which is REALLY the most important, is to let developers KNOW that they will be HELD to a standard, and that their code WILL be reviewed.

    My experience has taught me that developers will clean their code better if they know a human will be reviewing it.

    We usually start our code reviews as an “after the fact” review of what has been published. And we apply it to all files touched, etc. Until everyone knows what is expected of them, and then we want the reviews to happen BEFORE we actually publish the code. Experience has taught us that it is better to more loosely follow the process than it is to be rigid from the get go.

    Also, stay focused on the rules. We have a set of exceptions in which violating the coding standard increases the legibility of the code, and therefore its accuracy.

    I am not sure you can automate that “feeling” you get when you read the code and it feels like the wrong approach was taken. We find a lot of uncaught exceptions, and even some bad logic from time to time.

    Finally, we use the interactive code reviews as a training time for new developers getting up to speed on the project. We find it helps them to dive in, and also to build rapport with the more senior developers.

    • I’ve never viewed automating elements of a standard to be mutually exclusive with code reviews. If you standardize around cosmetic things, enforcement can easily be automated so that code review is freed up to be more high-level, design-focused discussions. In other words, you don’t need a human nagging you to put an underscore in front of a class field, or whatever. But a human’s attention is well suited for something like, “that method seems needlessly complex — what if we took advantage of design pattern X to simplify?”

  • Mark

    1) Coding standards should be a team thing, not a top-down thing.
    2) Anyone with a brain would see right through the automated enforcement by a CI server. The concept of “it’s just how the software works” shouldn’t be acceptable to anyone who writes code that has a brain.

    • I agree with (1). (The original post was written to a prompt/reader question about how someone in management could persuade a team to follow a standard)

      I don’t understand what you’re saying with (2). What does “seeing through” automated enforcement mean? The whole idea is that the enforcement is transparent — there’s nothing to “see through.” It would specifically say, “we’re failing the build because this code doesn’t comply with X” in the same way it would say,. “we’re failing the build because the code didn’t compile.”

  • Damian Dennis

    I have been using git hooks for this process, gets them before they commit, https://www.npmjs.com/package/git-hooks, if you are using npm is a good way to enforce especially when the project has dependencies in npm also.

  • Dale Barnard

    Well written. We’ve been through hell with code standards, and I wish I had read your post before that process.

    • Thanks for the kind words! Hopefully, something in here can at least help you in the future.