Clean Code

Consider some parts (general concepts) very valuable, while a lot of the advice on how to use the general concepts in practice is opiniated and, IMHO questionable at best.

If you read this book as the gospel I would say you are only getting half the value and will end up getting, in my opinion, a lot of bad advice.

But if you read it with an open mind and reflect on the concepts and advice given you'll be a better developer.

Questo manuale è imprescindibile per qualsiasi sviluppatore che voglia migliorare se stesso (lo dovremmo fare ogni giorno).

Nonostante gli esempi siano riferiti a Java, si può tranquillamente applicare quanto scritto a qualsiasi altro linguaggio ad oggetti. Ogni capitolo è scritto molto bene e pone le giuste opinioni su come organizzare al meglio il codice.

NON consiglierei questo libro ad uno sviluppatore alle primissime armi, perché il rischio è che si focalizzi troppo sulla pulizia senza fare i giusti errori di gioventù. Allo stesso tempo, non appena si ha un minimo di esperienza sullo sviluppo, è NECESSARIO leggre questo libro per confrontare la propria esperienza con quanto detto nel libro.

Attenzione, ci sono delle parti che forse potreste non condividere a pieno ma va bene così. Questa non è una bibbia e nemmeno ha la pretesa di esserlo: va vista solo come una collezione di esperienze.

Nota aggiuntiva: la parte finale con le appendici non l'ho trovata molto illuminante, la reputo invece quasi uno spreco di carta che sarebbe stata meglio in un blog post.

It's a very useful book, but I can't help wonder at the practicality of certain recommendations in the book. We'll see how useful this book is when I get more experience

Lots of SOLID advice (sorry, had to) , though I do think that the fact that it's written for early 00s java limits it in that it doesn't really address functional map/filter/reduce (select/where/accumulate) type stuff that more modern versions of java and pretty much all other languages allow for.

Main takeaways:
1. Names are important.
2. Functions/classes should be small
3. Comments on something that's not a public API are out of date the moment they're written. Just go crazy with privately named functions.
4. Refactor a lot
5. Inversion of Control / Dependency injection is neat - But really this was written at a time when the DI configuration step was terrible to write. I think .Net core handles this stuff really well now, and I'm sure the java frameworks do just fine.
6. Functions with a lot of arguments are terrible, maybe even evil

I don't know that I'd follow this to a tee. Conceptually I think the rules are fine, although I'm not sure I love excessive private function use with forgoing function arguments for private attributes. I understand that within an object, private attributes are fine things to go side affect crazy on, but I think that with web controller type request/response stuff, that sometimes it's just a little more straightforward and testable to have the endpoint method own the scope of the variables and just output the right thing without mutating the state of the object. Obviously the services it calls would still be injected into private attributes. Maybe in other contexts/application types it would totally make sense to keep it a bit more heavily OOP and encapsulated and all that good stuff.

Overall I think it's a good book and a great starting point for thinking about code styles, readability and consistency.