Clean Code. Whew! 18

Posted by Uncle Bob Tue, 08 Apr 2008 05:10:16 GMT

I’ve been working on this book for several years now. After a flurry of effort (you might have noticed I’ve been quiet lately) I’m very pleased to say that I’m done with the writing and am preparing the manuscript for production. See The Prentice Hall Listing

Table of Contents

Clean Code    1
    There Will Be Code    1
    Bad Code    2
    The Total Cost of Owning a Mess.    3
    Schools of Thought.    11
    We are Authors.    12
    The Boy Scout Rule    13
    Prequel and Principles    14
    Conclusion    14
    Bibliography    15
Meaningful Names by Tim Ottinger    17
    Introduction    17
    Use Intention-revealing Names    17
    Avoid Disinformation    19
    Make Meaningful Distinctions    20
    Use Pronounceable Names    21
    Use Searchable Names    22
    Avoid Encodings    23
    Avoid Mental Mapping    24
    Class Names    25
    Method Names    25
    Don't Be Cute    25
    Pick One Word Per Concept    26
    Don't Pun    26
    Use Solution Domain Names    27
    Use Problem Domain Names    27
    Add Meaningful Context    27
    Don't add Gratuitous Context    29
    Final Words ...    30
Functions    31
    Small!    34
    Do one thing.    35
    One level of abstraction per function.    36
    Switch Statements.    37
    Use descriptive names.    39
    Function Arguments.    39
    Have no side-effects.    43
    Command Query Separation    44
    Prefer exceptions to returning error codes.    45
    Don't Repeat Yourself.    47
    Structured Programming    48
    How do you write functions like this?    48
    Conclusion    49
    SetupTeardownIncluder    49
    Bibliography    52
Comments    53
    Comments do not make up for bad code.    55
    Explain yourself in code.    55
    Good Comments    55
    Bad Comments    59
    Example    71
    Bibliography    74
Formatting    75
    The Purpose of Formatting    76
    Vertical Formatting    76
    Horizontal Formatting    84
    Team Rules    89
    Uncle Bob's Formatting Rules.    90
Objects and Data Structures    93
    Data Abstraction    93
    Data/Object anti-symmetry.    95
    The Law of Demeter    97
    Data Transfer Objects    99
    Conclusion    101
    Bibliography    101
Error Handling by Michael Feathers    103
    Use Exceptions Rather than Return Codes    103
    Write Your Try-Catch-Finally Statement First    105
    Use Unchecked Exceptions    106
    Provide Context with Exceptions    107
    Define Exception Classes In Terms of a Caller's Needs.    107
    Define the Normal Flow    109
    Don't Return Null    110
    Don't Pass Null    111
    Conclusion    112
    Bibliography    112
Boundaries by James Grenning    113
    Bibliography    119
Unit Tests    121
    The Three Laws of TDD    122
    Keeping Tests Clean    123
    Clean Tests    124
    One Assert per Test    129
    F.I.R.S.T.    132
    Conclusion    132
    Bibliography    133
Classes    135
    Class Organization    135
    Classes should be Small!    136
    Organizing for Change    146
    Bibliography    150
Systems    By Dean Wampler 151
    How would you build a city?    151
    Separate constructing a system from using it    152
    Scaling Up    155
    Java Proxies    158
    Pure Java AOP Frameworks    160
    AspectJ Aspects    163
    Test-drive the system architecture    164
    Optimize decision making    165
    Use standards wisely, when they add demonstrable value    165
    Systems need Domain-Specific Languages    166
    Conclusion    166
    Bibliography    167
Emergence By Jeff Langr    169
    Getting Clean via Emergent Design    169
    Simple Design Rule 1: Runs all the tests    170
    Simple Design Rules 2-4: Refactoring    170
    No Duplication    170
    Expressive    173
    Minimal Classes and Methods    174
    Conclusion    174
    Bibliography    174
Concurrency    by Brett Schuchert 175
    Why Concurrency?    176
    Challenges    177
    Concurrency Defense Principles    178
    Know Your Library    180
    Know Your Execution Models    181
    Beware Dependencies between Syncrhonized Methods    182
    Keep Synchronized Sections Small    183
    Writing Correct Shut-Down Code is Hard    183
    Testing Threaded Code    184
    Conclusion    188
    Bibliography    189
Successive Refinement    191
    Args Implementation    192
    Args: the rough draft.    198
    String Arguments    212
     Conclusion    246
JUnit Internals    249
    Conclusion    262
Refactoring SerialDate    263
    Conclusion    280
    Bibliography    281
Smells and Heuristics    283
    Comments    283
    Environment    284
    Functions    285
    General    285
    Java    304
    Names    306
    Tests    310
    Conclusion    311
    Bibliography    312
Concurrency II    by Brett Schuchert 313
    Client/Server Example    313
    Possible Paths of Execution    317
    Knowing Your Library    322
    Dependencies between methods can break concurrent code    325
    Increasing Throughput    329
    Deadlock    331
    Testing Multi-Threaded Code    335
    Tool Support for Testing Thread-Based Code    337
    Conclusion    338
    Tutorial: Full Code Examples    339
org.jfree.date.SerialDate    345
Cross References of Heuristics    406
Comments

Leave a response

  1. Avatar
    Paddy Healey about 1 hour later:

    Congratulations getting this done Bob. I saw you give the Clean Code – Args talk at Agile 2006 and you were gathering feedback about whether there was a book in this subject. The result from the room seemed to be an overwhelming “yes!” and I’ve been eagerly awaiting the book ever since. The Table of Contents makes it look like this will be worth the wait. It will be on my shelf the day it comes out.

  2. Avatar
    Philip Schwarz about 3 hours later:
    Any idea of when it will hit the shelves in the UK? When will it be pre-orderable on Amazon UK? Thanks. An impatient reader. Your previous book, ‘Agile Software Development – Principles, Patterns, and Practices’ is, in my humble opinion, one of the best development books (there are Kent Beck’s books as well) I have ever come across. Pure quality. It is a ‘must read’.
  3. Avatar
    Stephen Seymour about 7 hours later:

    Thank you very much, Dr. Martin. I feel indebted to you for writing “Agile Software Development” because it truly helped further my understanding of software development. I suppose I did the work on my end by reading it and digesting it, but your book has had a ripple effect of helping my entire family by putting me in a position to do well in our industry.

    Thank you, sincerely, once again. I will certainly buy and read your new book. It’s an investment only the foolish wouldn’t make.

  4. Avatar
    Dave Hoover 1 day later:

    Great to hear that this book is coming soon! I am excited to read it and share it with my team.

  5. Avatar
    flipdoubt 1 day later:

    Looking forward to it.

    One question that has been nagging me lately: I believe I grok the benefit of the SRP, but if all your classes are responsible for just one thing, won’t your software do just one thing? I don’t mean for that to sound overly simplistic. I’m more interested in learning where the best place is to bring all these single responsibilities together to deliver real value to the user.

  6. Avatar
    http://www.grayger.com/wp/ 6 days later:

    I am looking forward to the book, especially chapter “error handling” and “concurrency”. Any sample chapter available?

  7. Avatar
    Pete 10 days later:

    Look forward to reading the book and more blog posts!

    I have three other books from the Robert C Martin series but none by the man himself. They’re all quite brilliant in their own ways. Working Effectively With Legacy Code, Agile Java and FIT for Software Development. I expect the quality of Clean Code to be similar.

    Have you got plans for a paperback edition of Agile Software Development?

  8. Avatar
    TonyB 15 days later:

    Looks good. I have a copy of Agile Principles, Practices and Patterns in C#, which is one of the most readable and clear software books I’ve ever read. In fact it’s the only one I’ve ever finished. I appreciate many of these concepts are cross-language, but will the examples in the new book be oriented towards C#, Java or what?

  9. Avatar
    Aaron 24 days later:

    Looking forward!

    When exactly would this book be published?

  10. Avatar
    mBria about 1 month later:

    Congrats…this is awesome news, I’ve been waiting with baited breath. If you’re looking for reviewers, I’d love to have the opportunity. Cheers!
    —MB
    (bria526 at gmail)

  11. Avatar
    rev about 1 month later:

    still got my ‘test first’ bracelet. when can we get this from amazon?

  12. Avatar
    Philip Johnson 5 months later:
  13. Avatar
    Mike Finney 8 months later:

    This is a fantastic book. As shared in my review of the Clean Code book, it’s a mind jarring, supportive, and thought provoking book!

  14. Avatar
    Rolf 8 months later:

    More people should understand how to write clean code. It will make all of our lifes a lot more pleasant. It’s on my christmas list :-)

  15. Avatar
    Neil 8 months later:

    I just bought this book and read it cover-to-cover. I have been looking for a book like this for Java since I read “Writing Solid Code” many years ago! Super-excellent book. Renforces the thinking I have been having for years reading crappy code. I have some comments/errata – Where can I send/post these?

  16. Avatar
    waterproof digital about 1 year later:

    Congrats…this is awesome news, I’ve been waiting with baited breath. If you’re looking for reviewers, I’d love to have the opportunity. Cheers!

  17. Avatar
    David Mårtensson about 1 year later:

    Hi.

    I am reading the book right now and I found it very rewarding.

    I have already started to use the principles despite not even being done with it.

    But I have found what I consider a failed assumption on page 300.

    FEET_PER_MILE is said to be such a well known constant not needing explanation.

    Well, I live in Sweden where we use meter and kilometer, not feet and mile, I would never have guessed what 5280 stood for without explanation.

    You should not make cultural assumptions like that as software development is a global business. :-)

    But thanks for writing the book, it have made me a much better programmer so far in just over a week.

    And seen some real improvement in the code I work with daily.

  18. Avatar
    Daniel about 1 year later:

    Hello, I put up an unofficial errata page for the book since there isn’t an official errata list: http://www.engineering.uiowa.edu/~wwalls/clean_code_errata/

    Contributions welcome and will be attributed.

Comments