Break The Rules
From Programmer 97-things
Knowing when to break a rule can be as important as knowing the rule. Rules exist to help keep things maintainable, consistent, flexible and stable. They are created for a specific reason and should evolve over time to accommodate changes in technology and practice.
This evolution is at the heart of the issue. Blindly adhering to a rule that may have become outdated may have serious consequences. For example, applying coding practices from Visual Basic 6 to VB.Net 3.5 would definitely impact the system. While there are definitely rules common to both, the inconsistencies are far greater. A more practical example would be the use of Hungarian notation, once considered a best practice, it is now obsolete.
So how do you know when a rule should be broken? Ask yourself the following question, "Does the rule make the system unstable, inflexible or difficult to maintain?" If the answer is yes, then it is time to look at breaking the rule.
The first step is always to look at the reason a rule exists. Hopefully, this is documented somewhere although there is a very good chance it's not. In that case, talk to other developers to determine the basis for the rule. It's important to check with more than one developer so that you can get a complete perspective.
The next step is to determine if there is a way break the letter of the rule but keep the spirit of the rule. What other options are available? Do they contradict the spirit of the rule? Is it the best solution available?
Now comes the most important part. Do you break the rule? Before you answer yes, you need to look at your solution. If it is in the spirit of the rule and it will probably occur again, then maybe the rule definition needs to be modified to include the circumstance and solution. Remember, consistency and maintainability are primary goals so make sure you document and communicate the rule change.
If it is not in the spirit of the rule or it's a onetime issue, then leave the rule definition alone and break the rule. In your documentation, note the rule that was broken, why it was broken and your solution. In your code reference the documentation so the next developer will be able to understand what you have done.
By Paul G Brown
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page
