How to make developers follow coding standards? [closed]

Answer 1

You ought to instate code reviews where the senior developers review the code of the other developers. If they don't follow convention, they fail the code review and it won't make it into the repository.

This requires a bit of human-engineering in that it is more process-based than software-based.

Oh, and tight deadlines are no excuse for bad code. As programmers it's our job to write solid quality code that is maintainable by the rest of the team.

Answer 2

If your co-workers and management don't care about code quality, you cannot force them to care. If you made a genuine attempt to convince them and you are being ignored, it is not really your role to take it any further.

I'm actually tired of rewriting that awful code on my own.

I think it is time to quietly start looking for a new job. Meanwhile, resist the temptation to rewrite the crap code for reasons other than fixing bugs. And try and get the culprits to fix their own bugs.

Having said that, it is possible that the team lead cares more about this than he is letting on. He may simply not be in a position to take the necessary action to deal with the poor quality culture. For example, if the project is running behind, getting rid of staff may not be an option. Or maybe he does not have any real clout on staffing issues ... and the culprits know it.

Answer 3

Just get rid of them and find new ones. If they're too lazy to do things right, they don't deserve to be employed. In this economy, you'll have 100 resumes in your hand by morning.

Answer 4

You have the standards. You have a process for them to follow. If they do not follow, terminate them and find qualified individuals who can follow standards.

More specifically,

1. At the beginning of the project, review the standards with the team. Communicate that they must be followed.
2. At the end of the project, review to ensure they were followed. If they were not, work with the individuals responsible for not following. Ask questions regarding why etc.
3. Give him/her a second chance.
4. If repeated, terminate the individual.

Answer 5

I would start by rephrasing your question: "How can I convince developers that following coding standards will make their lives better?"

There are at least two parts to the answer:

1. The burden of proof is on you as the advocate: if you can't make the business case for why adopting the standards will make life better in measurable ways, your coding standards are not worth adopting. This is your major stumbling block: you already have an organization where people are employed to do work so the business clearly already has some success. How does your standard make things better? Your answer should be phrased in terms of dollars or hours of people's lives (which are effectively the same thing in the workplace).

2. Simplicity is better. If your standards document is pages long, it will be immediately ignored by a busy developer. In my world, the best document is no more than a page long. For a coding standard, I would be inclined to create a single sheet of example code. Provided that I'd successfully made the business case above, I would then say to the team, "Make your code look like this, please."

If you make the mistake of involving more senior management in this discussion, point 1 is even more important. They're going to be surprisingly brutal when it comes to understanding exactly how many dollars your coding standards will save the organization. You can win that argument if you think it through carefully: e.g., reducing debugging time cuts hourly cost as people are able to check off lists of bugs quickly. That's cash money saved.

If you make the mistake of threatening the engineers (e.g., the suggestions of termination above), there's a very high probability that you'll eventually be featured on the Daily WTF.

If you manage to succeed at points 1 and 2, the actual support for standards validation are already well understood. Make sure that as much as possible is handled in the IDE (control-shift-F to format properly, etc.), automated checking tools, etc.

The technical methodology is the easy part. The people problems are always the hardest (and the most important).

Answer 6

Coding guidelines are important, but be careful not to:

• be too pedantic. Easy to follow/easy to remember rules are good. Public (eg: to your customers) interface standards are good. Imposing if an internal variable must be called num_of_elements or number_of_elements or nelem is too much.
• stepping from standardization into their creativity. For example, deciding that Singletons are forbidden is too much. Being a programmer is not more different than being an artist. You have to leave some degree of creativity.

In addition:

• Do peer review. When a developer commits some code, another developer must review it and approve it, also in terms of coding standards. If a fault is found, you don't put blame on a single person, which is never good, but you split the chance of the error to happen to be simultaneously on two (willing or unwilling) developers.
• If you are a manager, do find the time to perform this review as well, even code with them. A good manager is part of the team, and shares its tasks and its burden. If you are just a "mail, documents and orders" kind of manager, you will not get respect from your team, in particular if made of enthusiasts, as opposed to mindless typing monkeys. Be as you are a more experienced team member, get your hands dirty together with them.