10

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?

Stephen Bailey
  • 2,236
  • 14
  • 14
TheBoyan
  • 1,285
  • 10
  • 23

8 Answers8

9

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.

bethlakshmi
  • 7,625
  • 1
  • 26
  • 35
  • Playing devil's advocate here, it's always possible for rules to be plain wrong (for example, something put in place for a past project but is a burden on developers on the current project) - so having a rule review/repeal process - even if it is rarely used - may also be helpful in reassuring people that the rules are a helpful guideline rather than an imposition on developer freedom. – Beekguk Mar 29 '11 at 16:27
  • Absolutely - and I think if you stick with the advice to focus on why you need the rule, then if you figure out you *don't* need the rule, you know the team or person came at it from an open mindset, rather than just being defensive due to an inexplicable rule process. – bethlakshmi Mar 29 '11 at 21:09
6

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.

Community
  • 1
Chris Knight
  • 702
  • 5
  • 12
  • You can configure some revision control systems to enforce things like Checkstyle on check-in. If you do so, start with the most critical rules and add pickier rules later. – BillThor Mar 29 '11 at 00:00
4

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.

P.Brian.Mackey
  • 11,123
  • 8
  • 48
  • 87
  • The not using brackets was just an example :) although I've worked for a big company that had a book of >200 pages of coding rules and this was one of them. Anyway, I'm sure that you would agree with me that someone that deliberately uses the same connection string(an example again) over and over again in the code just because he/she is too lazy to put it in a config file and read it from there, needs the attention and one needs to know how to deal with this kind of situations. – TheBoyan Mar 28 '11 at 19:17
2

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.

Martin Blore
  • 4,645
  • 5
  • 29
  • 35
  • 2
    If the brace placement is your biggest quality problem, I guess you are pretty lucky. Is that the right level to focus on? – Bo Persson Mar 28 '11 at 19:03
  • Purely an example taken from the question. The principle being that code design "guidelines" as bethlakshmi says below, are just that - guidelines. If you're really concerned of how they are followed, then points in the process need to happen to remind/teach/enforce them. – Martin Blore Mar 28 '11 at 19:06
  • But braces where you think they should go... That speaks volumes. I think there are more fundamental aspects of coding readability/coding standards then brace placement. I agree everyone on the project should follow the same standard but one over the other does'nt matter much here. Maybe you can let them "win" the battle of brace placement in exchange for them acception your other suggestions on coding standards ? Not only that but they will feel part of the solution if their idea of braces placement is in the standards. – Gilles Mar 28 '11 at 19:19
  • 1
    Exactly. I gave up trying to persuade a developer to do brackets on their own line, instead of inline brackets, in exchange for him learning SOLID and TDD... a great trade I'd say ;). – Martin Blore Mar 28 '11 at 19:21
  • 1
    "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." - this is the only way to do it when it matters. – ocodo Mar 30 '11 at 01:28
2

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.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
  • "introducing automated code formatting at check-in, according to the accepted rules" ...this sounds interesting, any further ideas on where I can find something like this. – TheBoyan Mar 28 '11 at 19:19
  • @bojanskr, most mainstream IDEs nowadays support code formatting rules to a lesser or greater extent, and can autoformat your code upon save or checkin. For Java, both Eclipse and IntelliJ do, I guess NetBeans as well, but I haven't got much experience with it. For C#, see @Job's comment above. But there are also standalone tools, such as Artistic Style for C/C++. And most SCCs I know supports execution of user-specific scripts/triggers at e.g. checkin. – Péter Török Mar 28 '11 at 19:34
2

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

JeffO
  • 36,816
  • 2
  • 57
  • 124
1

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.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
1

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.

William Pietri
  • 3,060
  • 1
  • 17
  • 20