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

8Boundaries

by James Grenning

We seldom control all the software in our systems. Sometimes we buy third-party packages or use open source. Other times we depend on teams in our own company to produce components or subsystems for us. Somehow we must cleanly integrate this foreign code with our own. In this chapter we look at practices and techniques to keep the boundaries of our software clean.

Using Third-Party Code

There is a natural tension between the provider of an interface and the user of an interface. Providers of third-party packages and frameworks strive for broad applicability so they can work in many environments and appeal to a wide ...