Coding standards and techniques are dynamic. You start with some basics, then you add a few things. Then you decide that the brilliant style idea you had wasn't so brilliant, so you modify your technique. Over time it grows and changes.
The really fun part is that you've now got (organic) code and (organic) coding standards and (organic) style, and they're all of varying ages and applications. If you change a piece of code you haven't touched in a while, it might not conform to your current coding practices in a lot of ways, even if the change you're making is really small. We have a few options here:
- Whenever we change a coding practice or style, we go through and update all the code.
- Whenever we touch a piece of code, we update the entire file/class/method to use the current style.
- We write all new or modified code in the current style, and don't worry about code you're not touching.
- We give up on coding standards. Or give up on our code. Come to think of it, this one is a bad idea. Skip #4!
Any of the first three options is viable. If you have a huge code base, or frequent style guide changes, then option 1 starts to take an inordinately long time. Option 2 or option 3 may be more appropriate.
If you stick with a code base for any period of time longer than a few months, you'll likely see code changes, and you'll likely see style changes. When that happens, you'll need to decide how to deal with it. You have choices, just be sure to make your choice so that your entire team knows what to do as things change.