0

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?

  • 2
    Are these new rules or new team members? Have you tried coming up with a consensus style-guide? – jcm May 14 '17 at 23:47
  • 1
    What's in it for them? Why should they change their behaviours that they know work for them? How will these changes improve the work they do? Provide them answers to these questions, and include them in decisions on what changes to adopt, and you might get a result. – HorusKol May 15 '17 at 1:53
  • You can have an autoformatter do it for you, and invoke it at file-save. Easy to set up if everyone's on the same IDE. Sooner or later, they'll get used to it. – rath May 15 '17 at 7:51
  • @JoeStrazzere For consistency. It's easier working on a project with one coding style than as many code styles as there are coders. It's a nice thing to have, though not critical. – rath May 15 '17 at 7:53
  • The question was down voted but I don't see any comment explaining 'Why?'. Can the down voter give a reason for negative vote? – displayName May 24 '17 at 23:03
5

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.

  • Dear god the exact opposite of this. THe minute you start bitching about style issues in code reviews, the value of code reviews plummets. People start caring more about missing spaces than looking for actual logical bugs. I'd start shipping my resume the first time a style issue was brought up in one, it has always been the #1 sign of a broken development process. I've never seen quality come out of a process that focuses on style. – Gabe Sechan May 15 '17 at 5:52
  • I've done just that, including working at 2 of the biggest websites in the world. My experience was that consistency didn't matter. At all. What did matter was understanding what you were doing and the effects on other systems, and 90 percent of issues were there. I also noticed that the best run parts of those systems were where the teams didn't care about the style guides in code reviews and focused on logical and interactivity bugs. The more style was brought up, the shallower the crs were and the less value they brought. Every missed issue had plenty of useless style comments in that cr. – Gabe Sechan May 15 '17 at 6:28
  • Removed my response to your comment. It was borderline trolling and not helpful. The OP is asking "How do I introduce the industry wide standard practice of a coding standards?". And I'm giving him my perspective from having worked on two of the biggest deployments of software applications in the world. :) A simple coding standard should be a part of the process that all engineers practice and enforce if the code is expected be maintained for the long haul. But from the other answers and comments, I suspect we just entered "holy war" territory. Let's agree to disagree. – selbie May 15 '17 at 15:39
3

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.

  • 1
    You can even include the code checker in most IDEs which will highlight detected error, warning or notice messages. We use Eclipse/PyDev with pylint (for python programming). This way the code can be improved while writing it rather than when trying to commit it (which may feel like a big bummer). – hardmooth May 15 '17 at 6:51
  • You might also consider the following technical challenge: the VC server might be blocked (depending on your used technology) for the duration of a code check. Especially if many developers want to commit, the last one is blocked for every prior code check (and his own). – hardmooth Aug 8 '17 at 5:27
2

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.

  • 3
    Very not helpful. Please tell me how consistent code doesn't help readability. – Silas Mollod May 14 '17 at 23:59
  • 1
    @SilasMollod This answer never claimed it didn't. But if that's the one thing you gain, what you sacrifice is likely too much. – Weckar E. May 15 '17 at 8:57
0

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.

-1

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.

  • 3
    Authoritarian pronouncements from on high are just about the worst way possible to get support for something. – Philip Kendall May 15 '17 at 5:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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