Página inicialGruposDiscussãoMaisZeitgeist
Pesquise No Site
Este site usa cookies para fornecer nossos serviços, melhorar o desempenho, para análises e (se não estiver conectado) para publicidade. Ao usar o LibraryThing, você reconhece que leu e entendeu nossos Termos de Serviço e Política de Privacidade . Seu uso do site e dos serviços está sujeito a essas políticas e termos.
Hide this

Resultados do Google Livros

Clique em uma foto para ir ao Google Livros

Clean Code: A Handbook of Agile Software…
Carregando...

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin… (edição: 2008)

de Robert C. Martin

MembrosResenhasPopularidadeAvaliação médiaMenções
9841915,566 (4.32)1
Even bad code can function. But if code isn't clean, it can bring a development organisation 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 has teamed up with his colleagues from Object Mentor to distil their best agile practice of cleaning code "on the fly" into a book that will instil within you the values of a 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 Code is 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… (mais)
Membro:twistedmind
Título:Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)
Autores:Robert C. Martin
Informação:Prentice Hall PTR (2008), Edition: 1, Paperback, 464 pages
Coleções:Sua biblioteca
Avaliação:*****
Etiquetas:Nenhum(a)

Detalhes da Obra

Clean Code: A Handbook of Agile Software Craftsmanship de Robert C. Martin

Nenhum(a)
Carregando...

Registre-se no LibraryThing tpara descobrir se gostará deste livro.

Ainda não há conversas na Discussão sobre este livro.

» Ver também 1 menção

Inglês (15)  Húngaro (2)  Holandês (1)  Espanhol (1)  Todos os idiomas (19)
Mostrando 1-5 de 19 (seguinte | mostrar todas)
I have very mixed feelings about this book. Early on, it made me quite mad. But somewhere in the middle, it suddenly started to make sense. By the end, even though I still didn't agree with everything, I really appreciated the point that it's trying to make, and can agree with it.
Don't get me wrong, there are plenty of problems: so many of the examples are either bogus or have glaring problems of their own, there's a lot of bloat and back-patting in the prose, and to say this book is programming language agnostic is a massive lie. There are large sections devoted to the most Java-centric issues and examples, and it renders a lot of the advice from these sections meaningless for anyone using a different language.
My recommendation: start with the last chapter. If you feel like anything it says doesn't make sense or is unjustified, go back and read the related section. Reading the whole thing is a recipe for frustration. ( )
  nitemice | Dec 28, 2020 |
I finally got around to reading Clean Code by Robert C. Martin (Uncle Bob). It is often high on lists of the best books for software development, and for good reason. Clean Code is an excellent book that all programmers should read. Here is what I liked and didn’t like about it.

ORGANIZATION
The books is divided into four parts. Chapters 1 to 14 go through the basics, including naming, functions, formatting, comments and error handling. Then there are three example programs that are refactored to follow the recommendations given in the first part.

The three example programs are a command-line argument parser, a part of JUnit, and SerialDate, a class for date handling. The examples are quite extensive (together almost a hundred pages), with a lot of source code. All these (and all examples throughout the book) are written in Java.

Next is a chapter called “Smells and Heuristics”, which lists problems in code (and the solutions) in the form of 66 rules.

Finally there is appendix A, with more on concurrency, and appendix B, which has the complete source code for the third example program (SerialDate, almost 60 pages of program listing).

WHAT I LIKED THE MOST
Small. This is the one-word summary of the whole book. Functions and classes should be small (no, even smaller than that). It is much easier to make sure a function does only one thing if it is very small. Dividing the logic up in many small functions also gives you more opportunities to insert meaningful names that explain what is going on.

Niladic and monadic functions. The fewer arguments a function takes, the better (a niladic function takes zero arguments, a monadic one, and a dyadic two). I hadn’t thought much about the number of arguments before, but Uncle Bob makes a convincing case for using very few.

Flag arguments. A flag argument to a function is a boolean argument that controls what should be done. This is really an indication that the function should be split up in smaller parts.

Error handling. The argument for using exceptions for error handling instead of returning error codes is that it is much easier to separate the error handling from the regular logic. Also, using unchecked exceptions (instead of checked) avoids cascading changes when a new exception is added deep down in a hierarchy.

Newspaper Metaphor. The source file should be organized like a newspaper article, with the highest level summary at the top, and more and more details further down. Functions called from the top function come directly below it, and so on down to the lowest level and most detailed functions at the bottom. This is a good way to organize the source code, even though IDE:s make the location of functions less important, since it is so easy to navigate in and out of them.

Javadoc only for API:s. The recommendation is to only use Javadoc for documenting API:s that are exposed externally. Internally in a system, Javadoc documentation usually only results in unnecessary noise. I have seen this problem a lot, and I completely agree with this advice.

Long refactoring examples. The refactoring of the three example programs was quite valuable because it showed how to apply the recommendations in practice, and how the refactorings interact. This is often missing from other books. The disadvantage is that it can be pretty hard to follow when you don’t have an IDE to help you navigate and search.

WHAT I DIDN’T LIKE
Concurrency chapter and appendix. This chapter and appendix felt a bit out of place in the book. I also didn’t like the advice on instrumenting the code to try to find threading issues. In my experience, you don’t find multi-threading bugs that way. Instead, the best way is proper load testing, where the software is in heavy use in realistic scenarios.

Chapters 11 (Systems) and 12 (Emergence). These two chapters, despite promising titles, didn’t contain much of interest. They can easily be skipped without missing out on much.

State to reduce the number of arguments. In order to reduce the number of arguments a method needs, member variables are sometimes introduced instead. While this reduces the number of arguments, it also forces you to examine how the member variable is used in the rest of the class before you have a complete understanding of what the method does. This in my mind is worse, even if the class is small. I prefer the functional style, where it is enough to know the input arguments to have a complete understanding of what will happen.

No emphasis on dynamic error information. When an exception is thrown, it should always contain as much dynamic information as possible, to help in debugging. For example, if a network connection fails, include the port number and IP address the connection was intended for. Without this information, trouble shooting is a lot harder. Unfortunately, this is not mentioned at all in the book.

Wildcard imports. Rule J1 advocates importing a whole package rather than individual classes if two or more classes are needed from the package. However, then your program can break when a class is added to a package you import (more in e.g. this StackOverflow question). A long list of explicit imports at the beginning is not a problem in my view, it is easy to skip over.

CONCLUSION
There is a lot more good information in this book than I have been able to cover here. You can also tell that the advice is based on decades of experience developing real life software systems. I rate this book as one of the top three books on software development (the other two are Code Complete and The Pragmatic Programmer), and I think all programmers should read it.

From review on my blog: https://henrikwarne.com/2015/01/03/book-review-clean-code/ ( )
  Henrik_Warne | Dec 13, 2020 |
Reading this book is akin to reading about how to sterilize instruments in the 1880s: boil everything including the linens, dressings, etc. The advice in the book will be familiar to anyone who has ever read anything relating to programming proficiency (is it a wonder that you should name your variables so they make sense later? How about comments?) The problem is that the examples in the book are incredibly specific for the Java language and are difficult to apply elsewhere. It's akin to sitting with radiation, alcohol, and antiseptic solutions and being told "nope, you need to boil". I think the only reason this book has such a high reputation is because folks go into it thinking there is something they need to find in there in order to make their code better and much like a horoscope they find any nugget of useful information in there and feel like they've achieved coding perfection.

Please do yourself a favor and seek out some of the other books in this area that can give you better guidelines. Better still, find the ones that are tailored to the language you're using and use those to learn best practices. ( )
  craigmaloney | Mar 22, 2020 |
This is a must read for any cs professional ( )
  shubhamchaudhary | Jan 27, 2020 |
There are some good tidbits in there. Nothing earth-shattering, and nothing new (if you spend some time looking around for things like this). Now, had I read this 'way back when', I suspect I would have enjoyed much more. ( )
  CraigTreptow | Dec 9, 2019 |
Mostrando 1-5 de 19 (seguinte | mostrar todas)
sem resenhas | adicionar uma resenha

Pertence à série

Você deve entrar para editar os dados de Conhecimento Comum.
Para mais ajuda veja a página de ajuda do Conhecimento Compartilhado.
Título canônico
Título original
Títulos alternativos
Data da publicação original
Pessoas/Personagens
Lugares importantes
Eventos importantes
Filmes relacionados
Premiações
Epígrafe
Dedicatória
Primeiras palavras
Citações
Últimas palavras
Aviso de desambiguação
Editores da Publicação
Autores Resenhistas (normalmente na contracapa do livro)
Idioma original
CDD/MDS canônico

Referências a esta obra em recursos externos.

Wikipédia em inglês (4)

Even bad code can function. But if code isn't clean, it can bring a development organisation 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 has teamed up with his colleagues from Object Mentor to distil their best agile practice of cleaning code "on the fly" into a book that will instil within you the values of a 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 Code is 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

Não foram encontradas descrições de bibliotecas.

Descrição do livro
Resumo em haiku

Links rápidos

Capas populares

Avaliação

Média: (4.32)
0.5
1 1
1.5
2
2.5 1
3 17
3.5 3
4 66
4.5 8
5 73

É você?

Torne-se um autor do LibraryThing.

 

Sobre | Contato | LibraryThing.com | Privacidade/Termos | Ajuda/Perguntas Frequentes | Blog | Loja | APIs | TinyCat | Bibliotecas Históricas | Os primeiros revisores | Conhecimento Comum | 157,723,535 livros! | Barra superior: Sempre visível