[Ao7bei3s]

I agree, Clean Code was the most important book for me too. But I wouldn't follow it blindly. Also, it's less useful for non-Java and much less useful for non-OOP languages (it's ok to have a focus, but one has to keep in mind that sometimes, certain idioms, best practices or design patterns are actually workarounds around the limitations of Java).

My favorite example: Overdoing the short functions thing. I've seen this a lot. Unsurprisingly, considering that for most devs, when you ask them what makes good code, "short functions" seems to be the first thing that comes to mind.

Splitting code into extremely short functions has a few disadvantages too: a) in what order they're called is not immediately clear, b) where they can be called from is not immediately clear, c) going up/down the stack can make it harder to follow when debugging interactively. d) It increases the LOC and noise. And e) especially in OOP languages, short methods make it more tempting to turn variables into attributes to avoid passing them around explicitly (bad due to longer lifetime).

Splitting functions should only be done if it makes sense semantically. Each function should make sense on its own. If some logic is highly cohesive (e.g. because it implements a specific algorithm), not independently reusable, and it's subblocks only make sense in one order, and it all fits on a few screenfuls, it might make sense to keep it in one longer function instead of dividing it into fairly arbitrary chunks.

[davnicwil]

I think the short functions thing is a funny one. The benefits of short functions are definitely praised in the book, but they are really more of a side effect of the real goal: to have pieces of logic that do one single thing that can be summed up in a function name and understood as a clear input -> output 'step' at the level of abstraction above, without having to dig in to find out 'how it works' or understand any weird quirks / unexpected side effects etc.

Usually, by their nature, such functions don't end up being very long. This is great, but it remains just a nice side effect of the real goal, and one that is not more important than the real goal. To artificially break up a slightly longer function which is very focused in its behaviour, just for the sake of line count, is probably a mistake.

To be honest, I can't remember how clearly the book makes this distinction, or if it does at all, but I feel like it probably could be made clearer given how common this misinterpretation is.