🇲🇽🐧🖥🎵🕹🍺Y͢i͢Z͢u͢X͢🎮⛸📱 reviewed Clean Code by Robert Cecil Martin (Robert C. Martin)
Muy chingon
5 stars
Excelente libro \m/
taschenbuch, 431 pages
English language
Published July 20, 2008 by Prentice Hall.
Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
Noted software expert Robert C. Martin, presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin, who has helped bring agile principles from a practitioner’s point of view to tens of thousands of programmers, has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of software craftsman, and make you a better programmer―but only if you work at it.
What kind of work will you be doing? You’ll be reading code―lots of code. And you will be challenged to think about what’s right about …
Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
Noted software expert Robert C. Martin, presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin, who has helped bring agile principles from a practitioner’s point of view to tens of thousands of programmers, has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of software craftsman, and make you a better programmer―but only if you work at it.
What kind of work will you be doing? You’ll be reading code―lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly you will be challenged to reassess your professional values and your commitment to your craft.
Clean Codeis divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code―of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.
Readers will come away from this book understanding How to tell the difference between good and bad code How to write good code and how to transform bad code into good code How to create good names, good functions, good objects, and good classes How to format code for maximum readability How to implement complete error handling without obscuring code logic How to unit test and practice test-driven development What “smells” and heuristics can help you identify bad code This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
Excelente libro \m/
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 …
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 …
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.