Recently we have had some turnaround in the shop I work in, because of this comments in our source code were made hastily and explained very little. We have started working on the departments first draft of coding standards and one of the bigger questions is: Should we implement this standard across the existing source code? Since this is only our coding standards first draft (done to promote flexibility and future considerations), should we be implementing on new features and during maintenance?
Update: I would like to say thank you for all of the answers and comments that were received on this topic. Our shop has started to move forward with developing a draft for our coding standards and we have taken bits and pieces from all of the comments and answers to work with throughout our process. Thank you for your time and experience on this matter.
2
Definitely implement on new features and during maintenance. There is no value in spending time manually retweaking code to meet the guidelines. If you are an internal development shop, the business will have more pressing matters. If you are a commercial development shop, that is effort that is wasted while the competition does something.
The only real caveat is if you can easily feed your rules into an automated system and apply them. Since standards are new, this would most likely take more time than is prudent to devote to it.
3
What has worked best for me in the past and currently is that as we refactor code we use the current coding standards. If during this refactoring the code becomes unclear (because say we refactored out a method in one spot but it is not consistent with the rest of the class) we tend to bring the whole class up to the current standard. It really depends.
All forward and new development is in the new standard.
One reason we only update older code as it is refactored though, is because much of the legacy code is maintained by a few core developers. If we wholeheartedly changed the standard on the legacy code these developers would have a harder time. As we refactor out this code and move on though, this is less of a problem and the legacy developers learn the new standard (often they are doing the refactoring too) and bring the code forward.
All in all this rarely takes much more time than doing the work necessary there and it doesn’t stop development on the product as a whole for everyone for a bit while all code is being brought to standard. This process is accounted for in the velocity of the developers in the sprints they are on and is transparent to management outside of the tech teams so no one has to ask or present why additional time is necessary to change code that is currently working. Trying to explain to executive management that is not technical why coding standards matter and why they are changing versus getting new features for Sales in the code is remarkably difficult at times. This process avoids it.
It is fine to implement new coding standards in existing code. It is important that you are able to objectively prove that the coding standards changes did not impact the actual functioning of the software. To that end, you should create unit tests that prove how the code currently functions and use these unit tests to prove that the changes to the code (coding standards should be cosmetic in nature) did, in fact, not change the functionality of the code.