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ã.
Trang 1Clean Code Sau khi 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
Trang 2Readers 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
1 Title Page
2 Copyright Page
3 Contents
4 Foreword
5 Introduction
6 On the Cover
7 Chapter 1: Clean Code
1 There Will Be Code
2 Bad Code
3 The Total Cost of Owning a Mess
4 The Grand Redesign in the Sky
5 Attitude
6 The Primal Conundrum
7 The Art of Clean Code?
8 What Is Clean Code?
9 Schools of Thought
10 We Are Authors
11 The Boy Scout Rule
12 Prequel and Principles
13 Conclusion
14 Bibliography
8 Chapter 2: Meaningful Names
1 Introduction
2 Use Intention-Revealing Names
3 Avoid Disinformation
4 Make Meaningful Distinctions
Trang 35 Use Pronounceable Names
6 Use Searchable Names
7 Avoid Encodings
8 Hungarian Notation
9 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
21 Final Words
9 Chapter 3: Functions
1 Small!
2 Blocks and Indenting
3 Do One Thing
4 Sections within Functions
5 One Level of Abstraction per Function
6 Reading Code from Top to Bottom: The Stepdown Rule
7 Switch Statements
8 Use Descriptive Names
9 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
1 Comments Do Not Make Up for Bad Code
Trang 42 Explain Yourself in Code
3 Good Comments
4 Legal Comments
5 Informative Comments
6 Explanation of Intent
7 Clarification
8 Warning of Consequences
9 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
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
1 The Purpose of Formatting
2 Vertical Formatting
3 The Newspaper Metaphor
4 Vertical Openness Between Concepts
5 Vertical Density
6 Vertical Distance
7 Vertical Ordering
8 Horizontal Formatting
9 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
1 Data Abstraction
2 Data/Object Anti-Symmetry
Trang 53 The Law of Demeter
4 Train Wrecks
5 Hybrids
6 Hiding Structure
7 Data Transfer Objects
8 Active Record
9 Conclusion
10 Bibliography
13 Chapter 7: Error Handling
1 Use Exceptions Rather Than Return Codes
2 Write Your Try-Catch-Finally Statement First
3 Use Unchecked Exceptions
4 Provide Context with Exceptions
5 Define Exception Classes in Terms of a Caller’s Needs
6 Define the Normal Flow
7 Don’t Return Null
9 Conclusion
10 Bibliography
14 Chapter 8: Boundaries
1 Using Third-Party Code
2 Exploring and Learning Boundaries
3 Learning log4j
4 Learning Tests Are Better Than Free
5 Using Code That Does Not Yet Exist
6 Clean Boundaries
7 Bibliography
15 Chapter 9: Unit Tests
1 The Three Laws of TDD
2 Keeping Tests Clean
3 Tests Enable the -ilities
4 Clean Tests
5 Domain-Specific Testing Language
6 A Dual Standard
7 One Assert per Test
8 Single Concept per Test
9 F.I.R.S.T
10 Conclusion
11 Bibliography
16 Chapter 10: Classes
1 Class Organization
2 Encapsulation
3 Classes Should Be Small!
4 The Single Responsibility Principle
5 Cohesion
6 Maintaining Cohesion Results in Many Small Classes
7 Organizing for Change
8 Isolating from Change
9 Bibliography
Trang 617 Chapter 11: Systems
1 How Would You Build a City?
2 Separate Constructing a System from Using It
3 Separation of Main
4 Factories
5 Dependency Injection
6 Scaling Up
7 Cross-Cutting Concerns
8 Java Proxies
9 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
1 Getting Clean via Emergent Design
2 Simple Design Rule 1: Runs All the Tests
3 Simple Design Rules 2–4: Refactoring
4 No Duplication
5 Expressive
6 Minimal Classes and Methods
7 Conclusion
8 Bibliography
19 Chapter 13: Concurrency
1 Why Concurrency?
2 Myths and Misconceptions
3 Challenges
4 Concurrency Defense Principles
5 Single Responsibility Principle
6 Corollary: Limit the Scope of Data
7 Corollary: Use Copies of Data
8 Corollary: Threads Should Be as Independent as Possible
9 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
Trang 723 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
1 Args Implementation
2 How Did I Do This?
3 Args: The Rough Draft
4 So I Stopped
5 On Incrementalism
6 String Arguments
7 Conclusion
21 Chapter 15: JUnit Internals
1 The JUnit Framework
2 Conclusion
22 Chapter 16: Refactoring SerialDate
1 First, Make It Work
2 Then Make It Right
3 Conclusion
4 Bibliography
23 Chapter 17: Smells and Heuristics
1 Comments
2 C1: Inappropriate Information
3 C2: Obsolete Comment
4 C3: Redundant Comment
5 C4: Poorly Written Comment
6 C5: Commented-Out Code
7 Environment
8 E1: Build Requires More Than One Step
9 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
Trang 826 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
Trang 975 Bibliography
24 Appendix A: Concurrency II
1 Client/Server Example
2 The Server
3 Adding Threading
4 Server Observations
5 Conclusion
6 Possible Paths of Execution
7 Number of Paths
8 Digging Deeper
9 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