Clean Code (A Handbook of Agile Software Craftsmanship)

Clean Code được chia thành ba phần. Đầu tiên mô tả các nguyên tắc, mẫu và thực tiễn của việc viết mã sạch. Phần thứ hai bao gồm một số nghiên cứu điển hình về sự phức tạp ngày càng tăng. Mỗi nghiên cứu tình huống là một bài tập trong việc làm sạch code-chuyển đổi một cơ sở mã có một số vấn đề thành một trong đó là âm thanh và hiệu quả. Phần thứ ba là hoàn trả: một chương có chứa một danh sách các chẩn đoán và "mùi" thu thập được trong khi tạo ra các nghiên cứu tình huống. Kết quả là một cơ sở tri thức mô tả cách chúng ta nghĩ khi viết, đọc và làm sạch mã.

Clean Code Sau mua xin tải file đính kèm Clean Code.rar để tiến hành đọc Xin cám ơn! 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 Table of Contents Title Page Copyright Page Contents Foreword Introduction On the Cover Chapter 1: Clean Code There Will Be Code Bad Code The Total Cost of Owning a Mess The Grand Redesign in the Sky Attitude The Primal Conundrum The Art of Clean Code? What Is Clean Code? Schools of Thought 10 We Are Authors 11 The Boy Scout Rule 12 Prequel and Principles 13 Conclusion 14 Bibliography Chapter 2: Meaningful Names Introduction Use Intention-Revealing Names Avoid Disinformation Make Meaningful Distinctions Use Pronounceable Names Use Searchable Names Avoid Encodings Hungarian Notation Member Prefixes 10 Interfaces and Implementations 11 Avoid Mental Mapping 12 Class Names 13 Method Names 14 Don’t Be Cute 15 Pick One Word per Concept 16 Don’t Pun 17 Use Solution Domain Names 18 Use Problem Domain Names 19 Add Meaningful Context 20 Don’t Add Gratuitous Context 21 Final Words Chapter 3: Functions Small! Blocks and Indenting Do One Thing Sections within Functions One Level of Abstraction per Function Reading Code from Top to Bottom: The Stepdown Rule Switch Statements Use Descriptive Names Function Arguments 10 Common Monadic Forms 11 Flag Arguments 12 Dyadic Functions 13 Triads 14 Argument Objects 15 Argument Lists 16 Verbs and Keywords 17 Have No Side Effects 18 Output Arguments 19 Command Query Separation 20 Prefer Exceptions to Returning Error Codes 21 Extract Try/Catch Blocks 22 Error Handling Is One Thing 23 The Error.java Dependency Magnet 24 Don’t Repeat Yourself 25 Structured Programming 26 How Do You Write Functions Like This? 27 Conclusion 28 SetupTeardownIncluder 29 Bibliography 10 Chapter 4: Comments Comments Do Not Make Up for Bad Code Explain Yourself in Code Good Comments Legal Comments Informative Comments Explanation of Intent Clarification Warning of Consequences TODO Comments 10 Amplification 11 Javadocs in Public APIs 12 Bad Comments 13 Mumbling 14 Redundant Comments 15 Misleading Comments 16 Mandated Comments 17 Journal Comments 18 Noise Comments 19 Scary Noise 20 Don’t Use a Comment When You Can Use a Function or a Variable 21 Position Markers 22 Closing Brace Comments 23 Attributions and Bylines 24 Commented-Out Code 25 HTML Comments 26 Nonlocal Information 27 Too Much Information 28 Inobvious Connection 29 Function Headers 30 Javadocs in Nonpublic Code 31 Example 32 Bibliography 11 Chapter 5: Formatting The Purpose of Formatting Vertical Formatting The Newspaper Metaphor Vertical Openness Between Concepts Vertical Density Vertical Distance Vertical Ordering Horizontal Formatting Horizontal Openness and Density 10 Horizontal Alignment 11 Indentation 12 Dummy Scopes 13 Team Rules 14 Uncle Bob’s Formatting Rules 12 Chapter 6: Objects and Data Structures Data Abstraction Data/Object Anti-Symmetry The Law of Demeter Train Wrecks Hybrids Hiding Structure Data Transfer Objects Active Record Conclusion 10 Bibliography 13 Chapter 7: Error Handling Use Exceptions Rather Than Return Codes Write Your Try-Catch-Finally Statement First Use Unchecked Exceptions Provide Context with Exceptions Define Exception Classes in Terms of a Caller’s Needs Define the Normal Flow Don’t Return Null Don’t Pass Null Conclusion 10 Bibliography 14 Chapter 8: Boundaries Using Third-Party Code Exploring and Learning Boundaries Learning log4j Learning Tests Are Better Than Free Using Code That Does Not Yet Exist Clean Boundaries Bibliography 15 Chapter 9: Unit Tests The Three Laws of TDD Keeping Tests Clean Tests Enable the -ilities Clean Tests Domain-Specific Testing Language A Dual Standard One Assert per Test Single Concept per Test F.I.R.S.T 10 Conclusion 11 Bibliography 16 Chapter 10: Classes Class Organization Encapsulation Classes Should Be Small! The Single Responsibility Principle Cohesion Maintaining Cohesion Results in Many Small Classes Organizing for Change Isolating from Change Bibliography 17 Chapter 11: Systems How Would You Build a City? Separate Constructing a System from Using It Separation of Main Factories Dependency Injection Scaling Up Cross-Cutting Concerns Java Proxies Pure Java AOP Frameworks 10 AspectJ Aspects 11 Test Drive the System Architecture 12 Optimize Decision Making 13 Use Standards Wisely, When They Add Demonstrable Value 14 Systems Need Domain-Specific Languages 15 Conclusion 16 Bibliography 18 Chapter 12: Emergence Getting Clean via Emergent Design Simple Design Rule 1: Runs All the Tests Simple Design Rules 2–4: Refactoring No Duplication Expressive Minimal Classes and Methods Conclusion Bibliography 19 Chapter 13: Concurrency Why Concurrency? Myths and Misconceptions Challenges Concurrency Defense Principles Single Responsibility Principle Corollary: Limit the Scope of Data Corollary: Use Copies of Data Corollary: Threads Should Be as Independent as Possible Know Your Library 10 Thread-Safe Collections 11 Know Your Execution Models 12 Producer-Consumer 13 Readers-Writers 14 Dining Philosophers 15 Beware Dependencies Between Synchronized Methods 16 Keep Synchronized Sections Small 17 Writing Correct Shut-Down Code Is Hard 18 Testing Threaded Code 19 Treat Spurious Failures as Candidate Threading Issues 20 Get Your Nonthreaded Code Working First 21 Make Your Threaded Code Pluggable 22 Make Your Threaded Code Tunable 23 Run with More Threads Than Processors 24 Run on Different Platforms 25 Instrument Your Code to Try and Force Failures 26 Hand-Coded 27 Automated 28 Conclusion 29 Bibliography 20 Chapter 14: Successive Refinement Args Implementation How Did I Do This? Args: The Rough Draft So I Stopped On Incrementalism String Arguments Conclusion 21 Chapter 15: JUnit Internals The JUnit Framework Conclusion 22 Chapter 16: Refactoring SerialDate First, Make It Work Then Make It Right Conclusion Bibliography 23 Chapter 17: Smells and Heuristics Comments C1: Inappropriate Information C2: Obsolete Comment C3: Redundant Comment C4: Poorly Written Comment C5: Commented-Out Code Environment E1: Build Requires More Than One Step E2: Tests Require More Than One Step 10 Functions 11 F1: Too Many Arguments 12 F2: Output Arguments 13 F3: Flag Arguments 14 F4: Dead Function 15 General 16 G1: Multiple Languages in One Source File 17 G2: Obvious Behavior Is Unimplemented 18 G3: Incorrect Behavior at the Boundaries 19 G4: Overridden Safeties 20 G5: Duplication 21 G6: Code at Wrong Level of Abstraction 22 G7: Base Classes Depending on Their Derivatives 23 G8: Too Much Information 24 G9: Dead Code 25 G10: Vertical Separation 26 G11: Inconsistency 27 G12: Clutter 28 G13: Artificial Coupling 29 G14: Feature Envy 30 G15: Selector Arguments 31 G16: Obscured Intent 32 G17: Misplaced Responsibility 33 G18: Inappropriate Static 34 G19: Use Explanatory Variables 35 G20: Function Names Should Say What They Do 36 G21: Understand the Algorithm 37 G22: Make Logical Dependencies Physical 38 G23: Prefer Polymorphism to If/Else or Switch/Case 39 G24: Follow Standard Conventions 40 G25: Replace Magic Numbers with Named Constants 41 G26: Be Precise 42 G27: Structure over Convention 43 G28: Encapsulate Conditionals 44 G29: Avoid Negative Conditionals 45 G30: Functions Should Do One Thing 46 G31: Hidden Temporal Couplings 47 G32: Don’t Be Arbitrary 48 G33: Encapsulate Boundary Conditions 49 G34: Functions Should Descend Only One Level of Abstraction 50 G35: Keep Configurable Data at High Levels 51 G36: Avoid Transitive Navigation 52 Java 53 J1: Avoid Long Import Lists by Using Wildcards 54 J2: Don’t Inherit Constants 55 J3: Constants versus Enums 56 Names 57 N1: Choose Descriptive Names 58 N2: Choose Names at the Appropriate Level of Abstraction 59 N3: Use Standard Nomenclature Where Possible 60 N4: Unambiguous Names 61 N5: Use Long Names for Long Scopes 62 N6: Avoid Encodings 63 N7: Names Should Describe Side-Effects 64 Tests 65 T1: Insufficient Tests 66 T2: Use a Coverage Tool! 67 T3: Don’t Skip Trivial Tests 68 T4: An Ignored Test Is a Question about an Ambiguity 69 T5: Test Boundary Conditions 70 T6: Exhaustively Test Near Bugs 71 T7: Patterns of Failure Are Revealing 72 T8: Test Coverage Patterns Can Be Revealing 73 T9: Tests Should Be Fast 74 Conclusion 75 Bibliography 24 Appendix A: Concurrency II Client/Server Example The Server Adding Threading Server Observations Conclusion Possible Paths of Execution Number of Paths Digging Deeper Conclusion 10 Knowing Your Library 11 Executor Framework 12 Nonblocking Solutions 13 Nonthread-Safe Classes 14 Dependencies Between Methods Can Break Concurrent Code 15 Tolerate the Failure 16 Client-Based Locking 17 Server-Based Locking 18 Increasing Throughput 19 Single-Thread Calculation of Throughput 20 Multithread Calculation of Throughput 21 Deadlock 22 Mutual Exclusion 23 Lock & Wait 24 No Preemption 25 Circular Wait 26 Breaking Mutual Exclusion 27 Breaking Lock & Wait 28 Breaking Preemption 29 Breaking Circular Wait 30 Testing Multithreaded Code 31 Tool Support for Testing Thread-Based Code 32 Conclusion 33 Tutorial: Full Code Examples 34 Client/Server Nonthreaded 35 Client/Server Using Threads 25 Appendix B: org.jfree.date.SerialDate 26 Appendix C: Cross References of Heuristics 27 Epilogue 28 Index ... 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... interest in producing better code Table of Contents Title Page Copyright Page Contents Foreword Introduction On the Cover Chapter 1: Clean Code There Will Be Code Bad Code The Total Cost of Owning... Owning a Mess The Grand Redesign in the Sky Attitude The Primal Conundrum The Art of Clean Code? What Is Clean Code? Schools of Thought 10 We Are Authors 11 The Boy Scout Rule 12 Prequel and Principles