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

14Successive Refinement

Case Study of a Command-Line Argument Parser

This chapter is a case study in successive refinement. You will see a module that started well but did not scale. Then you will see how the module was refactored and cleaned.

Most of us have had to parse command-line arguments from time to time. If we don’t have a convenient utility, then we simply walk the array of strings that is passed into the main function. There are several good utilities available from various sources, but none of them do exactly what I want. So, of course, I decided to write my own. I call it: Args.

Args is very simple to use. You simply construct the ...