The following are the chapter and section headers of the book Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, et. al..
by Robert C. Martin
- Bjarne Stroustrup
- Grady Booch
- "Big" Dave Thomas
- Michael Feathers
- Ron Jeffries
- Ward Cunningham
by Tim Ottinger
- Hungarian Notation
- Member Prefixes
- Interfaces and Implementations
by Robert C. Martin
- Blocks and Indenting
- Sections within Functions
- Reading Code from Top to Bottom: The Stepdown Rule
- Common Monadic Forms
- Flag Arguments
- Dyadic Functions
- Triads
- Argument Objects
- Argument Lists
- Verbs and Keywords
- Output Arguments
- Extract Try/Catch Blocks
- Error Handling is One Thing
- The Error.java Dependency Magnet
by Robert C. Martin
- Legal Comments
- Informative Comments
- Explanation of Intent
- Clarification
- Warning of Consequences
- TODO Comments
- Amplification
- Javadocs in Public APIs
- Mumbling
- Redundant Comments
- Misleading Comments
- Mandated Comments
- Journal Comments
- Noise Comments
- Scary Noise
- Don't Use a Comment When You Can Use a Function or a Variable
- Position Markers
- Closing Brace Comments
- Nonlocal Information
- Too Much Information
- Inobvious Connection
- Function Headers
- Javadocs in Nonpublic Code
by Robert C. Martin
- The Newspaper Metaphor
- Vertical Openness Between Concepts
- Vertical Density
- Vertical Distance
- Variable Declarations
- Instance Variables
- Dependent Functions
- Conceptual Affinity
- Vertical Ordering
- Horizontal Openness and Density
- Horizontal Alignment
- Indentation
- Breaking Indentation
by Robert C. Martin
- Train Wrecks
- Hybrids
- Hiding Structure
- Active Record
by Michael Feathers
by James Grenning
by Robert C. Martin
- First Law
- Second Law
- Third Law
- Tests Enable the -ilities
- Domain-Specific Testing Language
- A Dual Standard
- Single Concept per Test
- Fast
- Independent
- Repeatable
- Self-Validating
- Timely
by Robert C. Martin with Jeff Langr
- Encapsulation
- Isolating from Change
by Dr. Kevin Dean Wampler
- Separation of Main
- Factories
- Dependency Injection
- Cross-Cutting Concerns
- AspectJ Aspects
by Jeff Langr
by Brett L. Schuchert
- Single Responsibility Principle
- Corollary: Limit the Scope of Data
- Corollary: Use Copies of Data
- Corollary: Threads Should Be as Independent as Possible
- Thread-Safe Collections
- Producer-Consumer
- Readers-Writers
- Dining Philosophers
- Treat Spurious Failures as Candidate Threading Issues
- Get Your Nonthreaded Code Working First
- Make Your Threaded Code Pluggable
- Make Your Threaded Code Tunable
- Run with More Threads Than Processors
- Run on Different Platforms
- Instrument Your Code to Try and Force Failures
- Hand-Coded
- Automated
by Robert C. Martin
- How Did I Do This?
- So I Stopped
- On Incrementalism
by Robert C. Martin
by Robert C. Martin
by Robert C. Martin
- C1: Inappropriate Information
- C2: Obsolete Comment
- C3: Redundant Comment
- C4: Poorly Written Comment
- C5: Commented-Out Code
- E1: Build Requires More Than One Step
- E2: Tests Require More Than One Step
- F1: Too Many Arguments
- F2: Output Arguments
- F3: Flag Arguments
- F4: Dead Function
- G1: Multiple Languages in One Source File
- G2: Obvious Behavior is Unimplemented
- G3: Incorrect Behavior at the Boundaries
- G4: Overridden Safeties
- G5: Duplication
- G6: Code at Wrong Level of Abstraction
- G7: Base Classes Depending on Their Derivatives
- G8: Too Much Information
- G9: Dead Code
- G10: Vertical Separation
- G11: Inconsistency
- G12: Clutter
- G13: Artificial Coupling
- G14: Feature Envy
- G15: Selector Arguments
- G16: Obscured Intent
- G17: Misplaced Responsibility
- G18: Inappropriate Static
- G19: Use Explanatory Variables
- G20: Function Names Should Say What They Do
- G21: Understand the Algorithm
- G22: Make Logical Dependencies Physical
- G23: Prefer Polymorphism to If/Else or Switch/Case
- G24: Follow Standard Conventions
- G25: Replace Magic Numbers with Named Constants
- G26: Be Precise
- G27: Structure over Convention
- G28: Encapsulate Conditionals
- G29: Avoid Negative Conditionals
- G30: Functions Should Do One Thing
- G31: Hidden Temporal Couplings
- G32: Don't Be Arbitrary
- G33: Encapsulate Boundary Conditions
- G34: Functions Should Descend Only One Level of Abstraction
- G35: Keep Configurable Data at High Levels
- G36: Avoid Transitive Navigation
- J1: Avoid Long Import Lists by Using Wildcards
- J2: Don't Inherit Constants
- J3: Constants versus Enums
- N1: Choose Descriptive Names
- N2: Choose Names at the Appropriate Level of Abstraction
- N3: Use Standard Nomenclature Where Possible
- N4: Unambiguous Names
- N5: Use Long Names for Long Scopes
- N6: Avoid Encodings
- N7: Names Should Describe Side-Effects
- T1: Insufficient Tests
- T2: Use a Coverage Tool!
- T3: Don't Skip Trivial Tests
- T4: An Ignored Test Is a Question about an Ambiguity
- T5: Test Boundary Conditions
- T6: Exhaustively Test Near Bugs
- T7: Patterns of Failure Are Revealing
- T8: Test Coverage Patterns Can Be Revealing
- T9: Tests Should Be Fast