Writing sustainable code is a long term commitment. To be effective you must be consistent.
- Easier expert chunking
- Tooling (very very important)
- Allows us to stop arguing about stuff that doesn’t matter! (Even more important)
What do I mean by consistency? Well consistency includes:
- Naming and formatting
- Parameter ordering
- Namespace naming
- Declaration order
- Design principles
- Other things.
- Don’t use lambdas?
What is with the “Don’t use lambdas” thing? Well, consistency may include your organization’s own rules, as long as they make sense and it is relatively easy to assure they can be followed over an extended period of times. This is important, having a lot of rules that nobody can follow is useless. Remember, you need a minimal set of good rules, that everybody can follow over an extended period of time.
Regarding consistent design, this is also very important. It is true that we can argue that, imposing SOLID principles would not always result in the simplest design but, the testability and consistency provided by these principles, would give your team more benefits that a somewhat simpler design in some obscure module. Without a consistent design there is always a chance to have a very very bad one. Also when debugging you must be clever, really clever, to understand exactly the architecture of a specific part of code. What if the developer who wrote the original code was stupidly clever? Now you must debug a stupidly clever code and we all know that won’t be fun. The safest thing is to go with SOLID, it is proven to provide the best results on average. Yea, I too, can give a lot of examples when SOLID may go wrong, but the argument still holds: on average it would make your code more testable, readable and maintainable, and when working on a team this is really really important. Just because there are exceptions to the rule it doesn’t mean the rule is not good. You can also check my previous post: Do not make rules for exceptions cases for details on this topic.