How do I get programmers to follow contribution rules and coding style?

Question

I'm currently a project lead and I've lead projects in the past. I've never had a great response from my fellow programmers when I try to institute project consistency in and out of code. It always becomes an argument about specifics or that I'm being too neurotic (what? you're lecturing me because I used semicolons??). I realize not all style rules are utilitarian; some are purely subjective. Yet, consistency is entirely objective. I want to, yet again, apply set of contribution rules (coding style, commit messages, naming) to this latest project. How do I go about this without having the programmers on my project rebel?

Answer 1

They will not rebel if they are involved in how these best practices are introduced.

Start with the coding style:

• Build agreement that this is valuable. Everyone on the team should agree that some type of coding standard is better than no standard. Emphasize that the maintenance of the code will likely go for many years and having quality built into each check-in will insure an easier to maintain product.

• Strive for a simple coding standard that is easy for anyone to memorize after reading it.

• Give the team engineers an opportunity to contribute or help define the style guideline document. Perhaps a few consensus meetings. Or at the very least, let them give you feedback about the standard your are proposing before it is finalized. Publish it formally to some place (Wiki, OneNote, Git repo, website, etc...) where everyone on your team has access to.

• Make coding standards part of the code review process. (You do have a code review process that precedes check-in, right?) Everyone on the team who reviews code is expected to flag coding standard violations.

After the coding style doc is imbued on the team, other things like the commit message format will be easy to introduce.

To as much as possible, automate this. You didn't indicate which programming language you are working in. But some languages have "lint" like tools that can detect bad style. (e.g. jslint for JavaScript). If your check-in infrastructure can reject checkins when the tool flags an error, then you can have an easy defense against sloppy code getting checked in.

Answer 2

If you want to enforce code standards then you should implement an automated code checker in your version control system's server (you are using one, right?) which will reject commits which don't adhere to the code standards. There are free and open source code checkers for almost all mainstream-ish languages.

You'll probably have to deal with pushback and complaining on this, but this will be once and not every time you review someone's code. After this, the code checker will take care of it.

Interesting analogue: back in 2002 I was a boy scout leader at a local Scouting troupe. We could all smoke inside the club house, but then due to some law changes we were forbidden to smoke inside.
The amount of complaining and ranting about it made it seem that it was an existential threat to the entire Scouting movement! People were on the verge of grabbing their pitchforks and storming the government building.

But ... even after a few months going outside for a smoke became the most normal thing in the world. In fact, looking back more than 15 years later I find it quite shocking there was any opposition against this in the first place.

It'll probably go the same with your code-checker; once people are used to it, it'll be natural.

---

That being said, do have a discussion about which code standards you want to have and which you want to enforce. I would recommend you use the standards for the language you're working in, as this avoids all the discussions about where to put the braces and what not.
It might be a good idea to start with just a few of the most important guidelines and work from there; some guidelines are huge, and having everyone adjust to them in one go will be a lot harder than having everyone adjust to them over time.

Answer 3

Maybe you should learn from your experiences. I would predict that all you can achieve is to make all decent developers find better paid jobs elsewhere, while you will be left with those who are afraid nobody else would hire them and call you "little Napoleon" behind your back.

Regarding your comment: Read Gabe Sechans answer is well. He is spot on. And Philip Kendall's comment: "Authoritarian pronouncements from on high are just about the worst way possible to get support for something".

You call this answer "not helpful". I'd say it wasn't the answer you wanted to hear. Very often the best answer to "How do I do this" is "Don't do it". Of course you can integrate a source code checker into the submit process - and make enemies forever.

Answer 4

Consistency is highly overrated, and generally valued by one particular type of programmer- those with micromangement tendencies and control issues. It shows that there's a focus on minutiae rather than quality. There's categories of things that actually do matter- good variable names, indenting your code, good comments. Then there's things that don't matter- spacing, brace style, etc. If your style guides focus on category one, programmers don't tend to have a problem. If your guide focuses on category 2, it tends to be a net negative. That's why your programmers are rejecting it.

My suggestion would be just not to do it. If you are going to do it- you don't get to decide any of the rules. Let the programmers themselves decide whats in the guide, and how strict the enforcement will be. Anything else will just lead to resentment and loss of productivity. And whatever you do, do not ever bring that stuff up in code review- the minute it creeps into there, code reviews stop being about finding bugs and improving quality, and moves into being nit picking on style issues. The result is buggier code gets released more slowly.

Answer 5

Be assertive and clear from the start. Provide a set style that your direct reports must adhere to and tell them that they must commit to it. Also make it clear that this is about providing consistency in coding style across the project, if that hasn't been made clear yet. If you have any that continue to rebel or push back, bring this further up the chain (eg. your manager), or if you can, discipline them accordingly. You're the lead in this case, so your word holds more authority in this case.