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

4Comments

“Don’t comment bad code—rewrite it.”

—Brian W. Kernighan and P. J. Plaugher¹

1. [KP78], p. 144.

Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.

Comments are not like Schindler’s List. They are not “pure good.” Indeed, comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much—perhaps not at all.

The proper use ...