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

3Functions

In the early days of programming we composed our systems of routines and subroutines. Then, in the era of Fortran and PL/1 we composed our systems of programs, subprograms, and functions. Nowadays only the function survives from those early days. Functions are the first line of organization in any program. Writing them well is the topic of this chapter.

Consider the code in Listing 3-1. It’s hard to find a long function in FitNesse,¹ but after a bit of searching I came across this one. Not only is it long, but it’s got duplicated code, lots of odd strings, and many strange and inobvious data types and APIs. See how much sense you can ...