Im Sortiment seit:
Kartoniert / Broschiert
Anyone with a modicum of industry experience knows that there is an awful lot of bad code out there. It's not that it's just unsightly. Code that is not clean can quite easily move beyond being a functional problem to becoming an expensive organizational issue that has to be dealt with immediately. There are no shortage of suggestions and methods for cleaning up your code after it has been written, but in this new book, Robert C. Martin espouses nipping these potential problems in the bud by cleaning on the fly, rather than doing it in segments or waiting until the end of a project. The book is a tutorial and reference that will teach the reader to conceive and write cleaner code through a multitude of proven examples. This book shows the PROCESS of cleaning code. Rather than just illustrating the end result, or just the starting and ending state, Martin shows how several dozen seemingly small code changes can positively impact the performance and maintainability of an application's code base. It will also explain why each of those changes was made. In the end the book will boil all these changes down into a suite of heuristics and principles that will guide the reader in his own code cleanups.
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 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 *What "smells" and heuristics can help you identify bad codeThis book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
Robert C. "Uncle Bob" Martin has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor, Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, C#, Ruby, OO, Design Patterns, UML, Agile Methodologies, and eXtreme programming.
Foreword xix Introduction xxv On the Cover xxix Chapter 1: Clean Code 1 There Will Be Code 2 Bad Code 3 The Total Cost of Owning a Mess 4 Schools of Thought 12 We Are Authors 13 The Boy Scout Rule 14 Prequel and Principles 15 Conclusion 15 Bibliography 15 Chapter 2: Meaningful Names 17 Introduction 17 Use Intention-Revealing Names 18 Avoid Disinformation 19 Make Meaningful Distinctions 20 Use Pronounceable Names 21 Use Searchable Names 22 Avoid Encodings 23 Avoid Mental Mapping 25 Class Names 25 Method Names 25 Don't Be Cute 26 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 Chapter 3: Functions 31 Small! 34 Do One Thing 35 One Level of Abstraction per Function 36 Switch Statements 37 Use Descriptive Names 39 Function Arguments 40 Have No Side Effects 44 Command Query Separation 45 Prefer Exceptions to Returning Error Codes 46 Don't Repeat Yourself 48 Structured Programming 48 How Do You Write Functions Like This? 49 Conclusion 49 SetupTeardownIncluder 50 Bibliography 52 Chapter 4: Comments 53 Comments Do Not Make Up for Bad Code 55 Explain Yourself in Code 55 Good Comments 55 Bad Comments 59 Bibliography 74 Chapter 5: Formatting 75 The Purpose of Formatting 76 Vertical Formatting 76 Horizontal Formatting 85 Team Rules 90 Uncle Bob's Formatting Rules 90 Chapter 6: Objects and Data Structures 93 Data Abstraction 93 Data/Object Anti-Symmetry 95 The Law of Demeter 97 Data Transfer Objects 100 Conclusion 101 Bibliography 101 Chapter 7: Error Handling 103 Use Exceptions Rather Than Return Codes 104 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 Chapter 8: Boundaries 113 Using Third-Party Code 114 Exploring and Learning Boundaries 116 Learning log4j 116 Learning Tests Are Better Than Free 118 Using Code That Does Not Yet Exist 118 Clean Boundaries 120 Bibliography 120 Chapter 9: Unit Tests 121 The Three Laws of TDD 122 Keeping Tests Clean 123 Clean Tests 124 One Assert per Test 130 F.I.R.S.T. 132 Conclusion 133 Bibliography 133 Chapter 10: Classes 135 Class Organization 136 Classes Should Be Small! 136 Organizing for Change 147 Bibliography 151 Chapter 11: Systems 153 How Would You Build a City? 154 Separate Constructing a System from Using It 154 Scaling Up 157 Java Proxies 161 Pure Java AOP Frameworks 163 AspectJ Aspects 166 Test Drive the System Architecture 166 Optimize Decision Making 167 Use Standards Wisely, When They Add Demonstrable Value 168 Systems Need Domain-Specific Languages 168 Conclusion 169 Bibliography 169 Chapter 12: Emergence 171 Getting Clean via Emergent Design 171 Simple Design Rule 1: Runs All the Tests 172 Simple Design Rules 2-4: Refactoring 172 No Duplication 173 Expressive 175 Minimal Classes and Methods 176 Conclusion 176 Bibliography 176 Chapter 13: Concurrency 177 Why Concurrency? 178 Challenges 180 Concurrency Defense Principles 180 Know Your Library 182 Know Your Execution Models 183 Beware Dependencies Between Synchronized Methods 185 Keep Synchronized Sections Small 185 Writing Correct Shut-Down Code Is Hard 186 Testing Threaded Code 186 Conclusion 190 Bibliography 191 Chapter 14: Successive Refinement 193 Args Implementation 194 Args: The Rough Draft 201 String Arguments 214 Conclusion 250 Chapter 15: JUnit Internals 251 The JUnit Framework 252 Conclusion 265 Chapter 16: Refactoring SerialDate 267 First, Make It Work 268 Then Make It Right 270 Conclusion 284 Bibliography 284 Chapter 17: Smells and Heuristics 285 Comments 286 Environment 287 Functions 288 General 288 Java 307 Names 309 Tests 313 Conclusion 314 Bibliography 315 Appendix A: Concurrency II 317 Client/Server Example 317 Possible Paths of Execution 321 Knowing Your Library 326 Dependencies Between Methods Can Break Concurrent Code 329 Increasing Throughput 333 Deadlock 335 Testing Multithreaded Code 339 Tool Support for Testing Thread-Based Code 342 Conclusion 342 Tutorial: Full Code Examples 343 Appendix B: org.jfree.date.SerialDate 349 Appendix C: Cross References of Heuristics 409 Epilogue 411 Index 413