HomeGroupsTalkZeitgeist
This site uses cookies to deliver our services, improve performance, for analytics, and (if not signed in) for advertising. By using LibraryThing you acknowledge that you have read and understand our Terms of Service and Privacy Policy. Your use of the site and services is subject to these policies and terms.
Hide this

Results from Google Books

Click on a thumbnail to go to Google Books.

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

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin… (edition 2008)

by Robert C. Martin

MembersReviewsPopularityAverage ratingMentions
7661317,835 (4.35)1
Member:sptz45
Title:Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)
Authors:Robert C. Martin
Info:Prentice Hall PTR (2008), Edition: 1, Paperback, 464 pages
Collections:Your library
Rating:
Tags:oop programming tdd

Work details

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

Recently added bypixelogical, geoff_ford, syskoplan, architrave, dmngmln, MickBrooke, jzents, private library, wmercheu
None
Loading...

Sign up for LibraryThing to find out whether you'll like this book.

No current Talk conversations about this book.

» See also 1 mention

English (10)  Dutch (1)  Spanish (1)  Hungarian (1)  All languages (13)
Showing 1-5 of 10 (next | show all)
A good book to read for any coder - perhaps not as thorough as Code Complete but much more effective than Pragmatic Programmer.

This book's biggest strength is that it includes tons of code examples, including some fairly long and in depth ones. Instead of just listing rules or principles of clean code, many of the chapters go through these code examples and iteratively improve them. The rules and principles fall out of this process and the reader is a part of developing them, which is an effective way to learn.

I also liked the justification for why clean code matters in the intro chapters. However, there was not enough discussion of real world trade offs. The book brushes them aside and claims that the programmer should *always* write the most clean code possible; what is not mentioned is to what extent to do this and when. In fact, the book compares code to poetry and art and makes a point to mention that neither is ever done. And yet, everyone needs to ship at some point. So when is code not just clean, but clean enough?

Some downsides: the chapters have different authors, so a few are weaker than others. Also, the book is too tailored to Java and imperative/OO programming. Similar to Code Complete, this book would benefit from discussing functional programming, which addresses many of the lessons/problems.

Some fun quotes from Clean Code:


We want the factory running at top speed to produce software. These are human factories: thinking, feeling coders who are working from a product backlog or user story to create product.

Yet even in the auto industry, the bulk of the work lies not in manufacturing but in maintenance—or its avoidance. In software, 80% or more of what we do is quaintly called “maintenance”: the act of repair.

You should name a variable using the same care with which you name a first-born child.

Quality is the result of a million selfless acts of care—not just of any great method that descends from the heavens.

You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.

Remember that code is really the language in which we ultimately express the requirements.

LeBlanc’s law: Later equals never.

Michael Feathers: I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by some- one who cares deeply about the craft.

Language bigots everywhere, beware! It is not the language that makes programs appear simple. It is the programmer that make the language appear simple!

The ratio of time spent reading vs. writing is well over 10:1.

Books on art don’t promise to make you an artist. All they can do is give you some of the tools, techniques, and thought processes that other artists have used. So too this book cannot promise to make you a good programmer. It cannot promise to give you “code-sense.” All it can do is show you the thought processes of good programmers and the tricks, tech- niques, and tools that they use.

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Functions should do one thing. They should do it well. They should do it only.

Every system is built from a domain-specific language designed by the programmers to describe that system. Functions are the verbs of that language, and classes are the nouns. This is not some throwback to the hideous old notion that the nouns and verbs in a requirements document are the first guess of the classes and functions of a system. Rather, this is a much older truth. The art of programming is, and has always been, the art of language design.

Master programmers think of systems as stories to be told rather than programs to be written.

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

"Objects are abstractions of processing. Threads are abstractions of schedule.” —James O. Coplien

Concurrency is a decoupling strategy. It helps us decouple what gets done from when it gets done.

Boolean arguments loudly declare that the function does more than one thing.

Names in software are 90 percent of what make software readable.


( )
  brikis98 | Nov 11, 2015 |
A very practical guide to improving the quality of the code you write. Mostly focused on unit testing and refactoring, including examples of gradually improving real projects.

Main idea: you cannot expect to find the best code structure from the first attempt, so plan to refactor it multiple times even as you write it, and provide the test coverage to do that with confidence. Otherwise, you end up with a pile of code that only sort-of-works, and that no-one ever dares to touch in order to make it better, including yourself.

Also lots of good general advice on code structure and style. Useful even if you do not agree with all of it. ( )
  valdanylchuk | Aug 26, 2015 |
Essential book if you were-are-want to be- a programmer. ( )
  JavierRiestra | Aug 21, 2014 |
An excellent guide for the teams and the engineers which take care of agility, productivity and on the other hand quality in software craftsmanship. "The Clean Code" shows us the "clean" way how to work together effectively in a team and produce maintainable software in the long term and not only functional code stacks. The book points out how important the aspects like readability and consistency are - even in comments - in order to reduce bugs and increase robustness . You'll also find lots of refactoring examples by author which show us how to apply these rules iteratively and still improve our source code. The only critic about the book is the concurrency chapter. It is in my opinion superfluous since the concurrency issues and the best practices respectively can not be covered within a chapter and for that reason it remains superficial. But it is still one of the book which i would read more than once and keep it on my desk while i am coding. ( )
  ebagdemir | Apr 7, 2013 |
.. ( )
  Kevin.Parent | Oct 21, 2012 |
Showing 1-5 of 10 (next | show all)
no reviews | add a review
You must log in to edit Common Knowledge data.
For more help see the Common Knowledge help page.
Series (with order)
Canonical title
Original title
Alternative titles
Original publication date
People/Characters
Important places
Important events
Related movies
Awards and honors
Epigraph
Dedication
First words
Quotations
Last words
Disambiguation notice
Publisher's editors
Blurbers
Publisher series
Original language
Canonical DDC/MDS

References to this work on external resources.

Wikipedia in English (4)

Book description
Haiku summary

Amazon.com Product Description (ISBN 0132350882, Paperback)

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 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 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 This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.

(retrieved from Amazon Thu, 12 Mar 2015 18:02:19 -0400)

No library descriptions found.

Quick Links

Popular covers

Rating

Average: (4.35)
0.5
1
1.5
2
2.5 1
3 11
3.5 2
4 48
4.5 7
5 53

Penguin Australia

An edition of this book was published by Penguin Australia.

» Publisher information page

Is this you?

Become a LibraryThing Author.

 

About | Contact | Privacy/Terms | Help/FAQs | Blog | Store | APIs | TinyCat | Legacy Libraries | Early Reviewers | Common Knowledge | 131,594,976 books! | Top bar: Always visible