Clean Code (A Handbook of Agile Software Craftsmanship)

Clean 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.


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
1.
2.
3.
4.
5.
6.
7.

Title Page
Copyright Page
Contents
Foreword
Introduction
On the Cover
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


5. 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
20. Don’t Add Gratuitous 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

2. 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
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
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


3. 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
8. Don’t Pass 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


17. 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


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
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


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
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