In this article I am going to concentrate on the different levels of the word "use", when utilised in such phrases as "should use" or "should not use", in order to show how not understanding the correct level can lead to confusion and the wrong use of a practice or principle. When somebody says "You should not use X when ..." or "X is bad when ..." it later gets converted into "you should not use X" or "X is bad". This means that the "when" has now been translated into "always", that the statement has been converted from conditional into unconditional.
Just because it is possible for a bad programmer to misuse "X" and create bad code, that is no reason to prevent a good programmer from using "X" when appropriate to produce good code. How many times has a doctor made the statement "Too much X is bad for you" only to have it reported as "X is bad for you". Consuming too much water can be bad for you, but does that mean that we should all stop drinking water? Conversely just because a principle or practice has proven to provide benefits in some circumstance it does not automatically mean that it will provide benefits in all circumstances.
Exposing your body to sunlight helps it produce vitamin D which is good for your bones. A lack of vitamin D, known as vitamin D deficiency, can cause bones to become soft and weak, which can lead to bone deformities. On the other hand too much sunlight can give you sunburn and even lead to skin cancer. This means that the two statements "sunlight is good" and "sunlight is bad" are BOTH wrong for the simple reason that they can only be 100% correct when they are qualified with the correct condition. Thus the statement "too much sunlight is bad" and "too little sunlight is bad" are both correct because they are qualified. If you remove that qualification, that condition, you are also removing the validity of the statement.
Unfortunately there are a large number of programming practices or principles which do not have a single definitive source, which means that they get passed from one person to another by word of mouth, or by reading someone's blog, which results in a situation known as Chinese Whispers. In a lot of cases the original description can be vague (such as "reason for change" in Uncle Bob's definition of SRP) and open to massive amounts of interpretation, which then leads to other people publishing or passing on their own interpretations of what they thought it meant. The end result is not a single, accurate, unambiguous definition which is impossible to misinterpret but a series of alternative and sometimes conflicting definitions which do nothing but add to the confusion and muddy the waters. All it takes is for one person to make a mistake for that mistake to be propagated down the line. Those people down the line do not realise that they are acting as an echo chamber for a wrong idea.
When someone says "I am using X" they could be employing "X" at one of the following levels:
A typical example is where an inexperienced developer implements too many design patterns just because "design patterns are good", so he thinks "the more the merrier". Too many design patterns result in a large number of small classes with small methods, which has the effect of producing a system which is too fragmented and which demonstrates low cohesion. Trying to follow a code path through 100 objects is far more difficult then when dealing with a dozen.
Another example is the over-use of the Dependency Inversion Principle (DIP). If you look at what Robert C. Martin, the author of this principle, originally wrote at The Dependency Inversion Principle (PDF) you will see that he provides an example in a "Copy" program which explains the circumstances in which the application of this principle would be of benefit. Yet far too many people seem to think that this principle must be applied in all circumstances instead of appropriate circumstances. My arguments against this stupidity are given in Dependency Injection is EVIL.
The Composite Reuse Principle is often phrased as favour composition over inheritance
which implies that inheritance is ALWAYS bad and should NEVER be used. This is incorrect as it implies that inheritance will always cause problems when true experts know that problems only arise through the mis-use of inheritance, such as to produce deep inheritance hiearchies or to inherit from one concrete class to produce another concrete class. True experts know that such problems can be avoided by only ever inheriting from an abstract class.