Evolution in coding standards, how do you deal with them?

Question

How do you deal with evolution in the coding standards / style guide in a project for the existing code base? Let's say someone on your team discovered a better way of object instantiation in the programming language. It's not that the old way is bad or buggy, it's just that the new way is less verbose and feels much more elegant. And all team members really like it. Would you change all exisiting code?

Let's say your codebase is about 500.000+ lines of code. Would you still want to change all existing code? Or would you only let new code adhere to the new standard? Basically lose consistency?

How do you deal with an evolution in the coding standards on your project?

Answer 1

Coding standards exist to make teams more productive. In theory, they make code easier to understand, alter, and test. In practice, they can create a dangerous amount of meta-work; teams re-write existing code over and over in pursuit of the most correct and elegant solution. Unfortunately, the meta-work problem seems worse on teams where everyone is engaged, passionate, and obsessed with doing the right thing.

As a consultant moving from project to project, I've found that excellent discipline with a rigid coding standard contributes far less to a project's success than excellent developers who are interested in results. Inconsistent coding styles are a minor nuisance to amazing developers. They're productive with or without consistency. Granted, if they encounter inconsistent code they'll ask about the current standard and stick with it. They won't, however, insist on updating every line of code in the project to the current standard. They don't insist because they've seen best practices come and go. The correct way of doing something today is not the same as the correct way of doing something tomorrow. If it was, your coding standards wouldn't evolve. So, if the correct way of doing something changes with time, maybe our definition of "correct" is broken.

That's not to say that standards don't matter. Just keep in mind that the goal of standards is productivity. If you can't guarantee re-writing to a new standard will pay for itself in the long-term, then don't waste time on it. It's far easier to justify a new standard in new or refactored code. Elegance is cool but it's not the same as results.

Answer 2

What we do is evolution (not revolution) for the code base also, we would use the updated standard when;

• new code is written
• code is refactored
• bugs are fixed
• new portions are added to an existing class

It is important that your codebase is consistent, so if the change opens a possibility of confusion between "old" and "new" style code, it might be better to reserve the update of your coding standard to the next project.

Answer 3

First of all, I would not include such "best practices" in the (mandatory part of the) coding guidelines. They might be mentioned, for example in an appendix, as an example how you could do something, but not that it should be done that way.

That said, there are two cases to consider for changes to a coding standard:

1. Changes that don't impact readability, even if old and new code are mixed without updating the old code.
   These changes can be added to the coding standard immediately and must be considered in effect for all new and modified code. Old code should be adapted incrementally as time permits and as changes in that area are being made.
   An example of this kind of change, which I actually encountered, is a change in the copyright statement at the beginning of each file.
2. Changes that deteriorate readability if old and new code are mixed.
   These changes should either be applied to the entire codebase in one go, or should be reconsidered if they are really needed.
   An example of this kind of change is a change in indentation or brace-placement.

Answer 4

This really has to depend on the type of product you are creating:

• For a commercial application that is written in house and you are deploying to customers, your main goal should be revenue. As long as the old code is not buggy then it does not matter that new coding standards have evolved, you should be concentrating in adding new features to your product and generating revenue. By all means, adapt the new coding standards for new code, but changing all the existing code would be a waste of time.
• If you are developing an open source product, or a product where multiple companies (maybe even your clients) will see and work on the source, then code readability becomes much more important and in this case, a sensible decision should be made depending on exactly how much code needs to be changed and what the benefits will be in the long run. Although we all like pretty code, the reality of it is that for a commercial company dealing with closed source, constantly adapting new standards will mean that you will loose out on revenue in the long run.

Answer 5

Personally, I would opt to keep old codes as it is, and follow new standards from whatever you do new. More specifically, I won't use double standards in old.c. But if am gonna create new.c, it can use the newer, refined syntaxes :)