[davnicwil]

Do you have examples of things you learned on the courses that you thought made your code more difficult to understand and modify?

After that, did you completely switch back to the code style you were using before the courses? Did you cherry pick some things and not others?

Just to make my view plain, for me 'clean code' was the most important book I've read in my career, and what I learned from it has (in my view) massively positively influenced the quality of my code over the years. I'm really interested in getting an opposing viewpoint. At the end of the day I'm aiming for my code to be understandable and maintainable by other people as much as myself.

[taeric]

The single most dangerous thing I learned was that "cleaning" as you go and the "intrinsic quality of the code" were somehow paramount.

I'm not against the ideas, per se. But they have a cost. And at the end of the day the quality of the product you are building is far more important than any intrinsic quality of the product. Worse, it would be nice if they correlated, at the least. They don't seem to, IME. I'd be welcome to data showing otherwise. Make sure you understand your budget. And for the love of god, realize that idioms in the codebase and in the general programmer pool are more important than purity of some style.

[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.