Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

5 Answers 5

up vote 10 down vote accepted

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.

share|improve this answer

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 A, but not that it should be dome 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.
share|improve this answer

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.

share|improve this answer

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 :)

share|improve this answer
    
Can you explain the reasoning behind that choice? –  Ward Bekker Jan 17 '11 at 9:31
    
Uh ... you can say, it's kinda intuition. Based on what mrwooster has said above, if it's a commercial app, I won't waste my time just to do some cosmetic changes. (Remember, functionality remains same). Moreover, say, the change is not only how you instantiate objects. But also, say, how you access it's methods. Then a lot of code needs to be fixed, with a handsome chance of introducing bugs. So, better let the old man remain there. –  Barun Jan 17 '11 at 10:15

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.
share|improve this answer
1  
I'll add that it also depends on your test coverage. I've re-factored some pretty large 10,000+ lines with loads of confidence as the critical functionality was covered by integration and unit tests. –  Martijn Verburg Jan 17 '11 at 9:34
    
@Martijn - Good point, this is also very true. –  mrwooster Jan 17 '11 at 9:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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