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?
Best Answer
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.