book

Clean Code: A Handbook of Agile Software Craftsmanship

by Robert C. Martin

August 2008

Intermediate to advanced

464 pages

13h 48m

English

Pearson

Read now

Unlock full access

Includes

Has Sandbox

On the Cover
There Will Be CodeBad CodeThe Total Cost of Owning a MessSchools of ThoughtWe Are AuthorsThe Boy Scout RulePrequel and PrinciplesConclusionBibliography
IntroductionUse Intention-Revealing NamesAvoid DisinformationMake Meaningful DistinctionsUse Pronounceable NamesUse Searchable NamesAvoid EncodingsAvoid Mental MappingClass NamesMethod NamesDon’t Be CutePick One Word per ConceptDon’t PunUse Solution Domain NamesUse Problem Domain NamesAdd Meaningful ContextDon’t Add Gratuitous ContextFinal Words

Small!Do One ThingOne Level of Abstraction per FunctionSwitch StatementsUse Descriptive NamesFunction ArgumentsHave No Side EffectsCommand Query SeparationPrefer Exceptions to Returning Error CodesDon’t Repeat YourselfStructured ProgrammingHow Do You Write Functions Like This?ConclusionSetupTeardownIncluderBibliography
Comments Do Not Make Up for Bad CodeExplain Yourself in CodeGood CommentsBad CommentsBibliography
The Purpose of FormattingVertical FormattingHorizontal FormattingTeam RulesUncle Bob’s Formatting Rules
Data AbstractionData/Object Anti-SymmetryThe Law of DemeterData Transfer ObjectsConclusionBibliography
Use Exceptions Rather Than Return CodesWrite Your Try-Catch-Finally Statement FirstUse Unchecked ExceptionsProvide Context with ExceptionsDefine Exception Classes in Terms of a Caller’s NeedsDefine the Normal FlowDon’t Return NullDon’t Pass NullConclusionBibliography
Using Third-Party CodeExploring and Learning BoundariesLearning log4jLearning Tests Are Better Than FreeUsing Code That Does Not Yet ExistClean BoundariesBibliography
The Three Laws of TDDKeeping Tests CleanClean TestsOne Assert per TestF.I.R.S.T.ConclusionBibliography
Class OrganizationClasses Should Be Small!Organizing for ChangeBibliography
How Would You Build a City?Separate Constructing a System from Using ItScaling UpJava ProxiesPure Java AOP FrameworksAspectJ AspectsTest Drive the System ArchitectureOptimize Decision MakingUse Standards Wisely, When They Add Demonstrable ValueSystems Need Domain-Specific LanguagesConclusionBibliography
Getting Clean via Emergent DesignSimple Design Rule 1: Runs All the TestsSimple Design Rules 2–4: RefactoringNo DuplicationExpressiveMinimal Classes and MethodsConclusionBibliography
Why Concurrency?ChallengesConcurrency Defense PrinciplesKnow Your LibraryKnow Your Execution ModelsBeware Dependencies Between Synchronized MethodsKeep Synchronized Sections SmallWriting Correct Shut-Down Code Is HardTesting Threaded CodeConclusionBibliography
Args ImplementationArgs: The Rough DraftString ArgumentsConclusion
The JUnit FrameworkConclusion
First, Make It WorkThen Make It RightConclusionBibliography
CommentsEnvironmentFunctionsGeneralJavaNamesTestsConclusionBibliography
Client/Server ExamplePossible Paths of ExecutionKnowing Your LibraryDependencies Between Methods Can Break Concurrent CodeIncreasing ThroughputDeadlockTesting Multithreaded CodeTool Support for Testing Thread-Based CodeConclusionTutorial: Full Code Examples

Content preview from Clean Code: A Handbook of Agile Software Craftsmanship

Epilogue

In 2005, while attending the Agile conference in Denver, Elisabeth Hedrickson¹ handed me a green wrist band similar to the kind that Lance Armstrong made so popular. This one said “Test Obsessed” on it. I gladly put it on and wore it proudly. Since learning TDD from Kent Beck in 1999, I have indeed become obsessed with test-driven development.

1. http://www.qualitytree.com/

But then something strange happened. I found I could not take the band off. Not because it was physically stuck, but because it was morally stuck. The band made an overt statement about my professional ethics. It was a visible indication of my commitment to writing the best code I could write. Taking it off seemed like a betrayal of those ethics and of that commitment. ...