Private Methods. Smelly-ish

Although not definitely bad, I've been finding it a pretty useful rule-of-thumb to treat private methods with plenty of suspicion. Certainly when deciding where to put "new code" but also in code reviews. The argument against private methods in terms of design principles is summed up somewhat nicely, if a little black and white, in Private Methods are a Code Smell. In brief it too soon leads to flagrant violations of the Single Responsibility Principle and other core OO design principles.

Keeping this simple rule-of-thumb may have an important role to play in controlling the rate of growth of class size and complexity.

Michael Feathers, legacy code guru that he is, suggests the type of growth we see in code-bases over time shouldn't be a surprise to us.

For the following reason:

Which is usually the easier option for the developer?
(1.a) Add code to an existing method
(1.b) Add a new method

(2.a) Add code to an existing class
(2.b) Add a new class

Generally speaking, (1.a) + (2.a) are easier. And so this is what you’ll see done time and time again. Unfortunately this pushes you towards bigger classes and bigger methods over time.

So we should not be surprised to see code growing as it does (or even be surprised to catch ourselves contributing to the problem). But the key is what to do about this tendency, this widespread inclination.

Applying rules of thumb such as avoid private methods to your decision-making process might be a good counter-measure.

Now to think of the counter-counter-measure for the inevitable over-use any rule-of-thumb ends up with…