What about all those coding rules?

Question

I always supported the idea of having coding rules for developers in a company or a specific project. Especially if the company is size greater than 10. The bigger the company the bigger the need. I know a lot of people will disagree, but I have seen projects that don't have them and the code looks like total disaster.

The real problem that comes from this is how to make those hard headed ones that don't like to use brackets in if statements, or use the same connections string everywhere in the code, or whatever, to use the coding rules without making them oppose the idea?

Answer 1

Get them involved in fixing a problem rather that fighting rules. I personally prefer the idea of "style guides", "coding standards" or something similar, in the hopes that it prevents the knee jerk "rules=bad" reaction.

But even if it does - I tend to think that the rules are in place for a reason, and the way to get hard headed people to turn around is to get them to realize that by following guidelines, they are helping make the code easier to read for everyone.

Sometimes peer pressure is the best solution for this.

Answer 2

At my work we use all three of the following solutions:

1) Adopt a code style checker such as the excellent Checkstyle (for Java) or StyleCop (for C#). These are easily configured tools which can automatically highlight coding style/rule deviations. It gives everyone a neutral 3rd party to determine what is and isn't acceptable.

2) Adopt an auto-save reformat code template (here's an example using Eclipse) (and another for Visual Studio) which will automatically format your code on save. This is great for allowing someone to code how they wish, but have all the code formatted the same way on save/commit. I really like this one and our code has never been more consistent.

3) Code reviews. Hopefully you are doing these anyway, but one thing these should highlight is where coding rules/styles are breaking convention.

In addition to the above, its important that everyone is on the same boat and has agreed the styles/rules they are working towards. Make it clear that you won't get agreement from everyone on everything, but ask for commitment from the team to hold true to what the team decides. Be sure to occasionally review the styles/rules chosen to account for real-world experience using them and team turn-over.

Answer 3

The real problem that comes from this is how to make those hard headed ones that don't like to use brackets in if statements, or use the same connections string everywhere in the code, or whatever,

Are they being "hard headed" by not using brackets or is this a "hard headed" request?

Pick your battles. I doubt this is one of the ones worth picking. I would not enjoy working anywhere that expected anywhere near this level of detail on "first check in code". This is a red flag indicator that the team does not understand refactoring.

OO 101: "Refactor when the product does what it needs to do". Not before.

Answer 4

It's pretty difficult to sit on the shoulder of every single developer in large teams, making sure they put braces where you think they should go - trust me on that one ;).

If it's something you really feel is hindering your development, then you're going to need a "gatekeeper". Don't let people check in without a code review for example. Have the technical architect or team leader to review the code and reject it until they "correct" the code style. They will soon get tired of this and adjust to the rules, though, possibly for only as long as they are being checked on.

Of course, some companies take away check-in privileges completely from junior programmers. When they finally learn the companies coding rules, then they get the privilege.

Answer 5

I think you are talking about problems of very different levels:

how to make those hard headed ones that don't like to use brackets in if statements,

That is mostly a style/readability issue, unless there is an explicit operator precedence problem. The latter should not be very common, and is unit testable anyway, thus easy to fix. The former can easily regress into a Holy War with little to gain, but severe negative consequences to team morale. So beware - only push tried and tested rules, which have been accepted by at least some teams/communities and proven to work.

or use the same connections string everywhere in the code,

If you mean Magic Constants, that is indeed a maintenance (plus potentially security) problem, and as such IMHO any seasoned developer will understand and accept that it is a Bad Thing.

or whatever, to use the coding rules without making them oppose the idea?

You can't force people to agree with whatever coding rules - your only chance is to get to a common understanding and buy-in from team members via discussion and (sometimes fierce) debate. You need to use logical and convincing arguments, showing the value behind each rule, and explaining how following it is going to pay for the inconvenience of adjusting ingrained habits. On the other hand, strive to make the transition as easy as possible, by e.g. introducing automated code formatting at check-in, according to the accepted rules.

Still, at times you just need to accept that people have differing opinions, thus the coding rules everyone can accept will be lenient in certain respects. Accept that and focus on areas where you can improve things with less effort.

Answer 6

Get them involved in establishing rules. This usually helps to encourage people to follow them.

Answer 7

This is what code review is for. The code reviewers should not be letting code pass that doesn't meet the standards. Make sure not to relax the rules for urgent fixes. Having to redo a few times under pressure to get it done will fix those reluctant to do their jobs properly the first time.

Answer 8

The same connection string everywhere? The solution to that is to refactor until you've removed all the duplication. Copy-paste coders should go to programmer jail. (Don't laugh! Steve Ballmer is the warden.)

But the real problem here is your verb "make". You can't make programmers do anything, and if you do, you're wasting their most valuable characteristic: the deep intellectual engagement that comes from working on something you care about.

The way I'd solve it:

1. Insist that the team have a common coding standard. It can be 5 lines long, but they all have to agree.
2. Every time you notice an argument insist they settle it together and put it in the coding standard. If you notice people reformatting things back and forth, treat that as an argument.
3. Whenever a standard item is agreed upon, see if there's a tool that will clean the whole code base up at once.
4. Every couple of months, go through the coding standard and see which ones are still true and relevant. The standard just documents what people are doing. And there's no point in keeping items in the standard that have become obvious.

Programming is a team sport, or a collective artistic work. What people agree on doesn't matter nearly as much as that they agree, and are good at coming to new agreements as necessary.