book

Code Complete, 2nd Edition

by Steve McConnell

June 2004

Intermediate to advanced

992 pages

37h 55m

English

Cisco Press

Read now

Unlock full access

Who Should Read This Book?Experienced ProgrammersTechnical LeadsSelf-Taught ProgrammersStudents
The Topic of Construction Has Been NeglectedConstruction Is ImportantNo Comparable Book Is Available
Steve McConnell

1.1. What Is Software Construction?
2.1. The Importance of Metaphors
Software Penmanship: Writing CodeSoftware Farming: Growing a SystemSoftware Oyster Farming: System AccretionSoftware Construction: Building SoftwareApplying Software Techniques: The Intellectual ToolboxCombining MetaphorsAdditional Resources
3.1. Importance of PrerequisitesDo Prerequisites Apply to Modern Software Projects?Causes of Incomplete PreparationUtterly Compelling and Foolproof Argument for Doing Prerequisites Before ConstructionAppeal to LogicAppeal to AnalogyAppeal to DataBoss-Readiness Test
Iterative Approaches' Effect on PrerequisitesChoosing Between Iterative and Sequential Approaches
Why Have Official Requirements?The Myth of Stable RequirementsHandling Requirements Changes During Construction
Typical Architectural ComponentsProgram OrganizationMajor ClassesData DesignBusiness RulesUser Interface DesignResource ManagementSecurityPerformanceScalabilityInteroperabilityInternationalization/LocalizationInput/OutputError ProcessingFault ToleranceArchitectural FeasibilityOverengineeringBuy-vs.-Build DecisionsReuse DecisionsChange StrategyGeneral Architectural Quality
RequirementsSoftware ArchitectureGeneral Software-Development Approaches
4.1. Choice of Programming LanguageLanguage DescriptionsAdaAssembly LanguageCC++C#CobolFortranJavaJavaScriptPerlPHPPythonSQLVisual Basic
Example of Programming into a Language
5.1. Design ChallengesDesign Is a Wicked ProblemDesign Is a Sloppy Process (Even If it Produces a Tidy Result)Design Is About Tradeoffs and PrioritiesDesign Involves RestrictionsDesign Is NondeterministicDesign Is a Heuristic ProcessDesign Is Emergent
Software's Primary Technical Imperative: Managing ComplexityAccidental and Essential DifficultiesImportance of Managing ComplexityHow to Attack ComplexityDesirable Characteristics of a DesignLevels of DesignLevel 1: Software SystemLevel 2: Division into Subsystems or PackagesLevel 3: Division into ClassesLevel 4: Division into RoutinesLevel 5: Internal Routine Design
Find Real-World ObjectsForm Consistent AbstractionsEncapsulate Implementation DetailsInherit—When Inheritance Simplifies the DesignHide Secrets (Information Hiding)Secrets and the Right to PrivacyAn Example of Information HidingTwo Categories of SecretsBarriers to Information HidingValue of Information HidingIdentify Areas Likely to ChangeAnticipating Different Degrees of ChangeKeep Coupling LooseCoupling CriteriaKinds of CouplingLook for Common Design PatternsOther HeuristicsAim for Strong CohesionBuild HierarchiesFormalize Class ContractsAssign ResponsibilitiesDesign for TestAvoid FailureChoose Binding Time ConsciouslyMake Central Points of ControlConsider Using Brute ForceDraw a DiagramKeep Your Design ModularSummary of Design HeuristicsGuidelines for Using Heuristics
IterateDivide and ConquerTop-Down and Bottom-Up Design ApproachesArgument for Top DownArgument for Bottom UpNo Argument, ReallyExperimental PrototypingCollaborative DesignHow Much Design Is Enough?Capturing Your Design Work
Software Design, GeneralSoftware Design TheoryDesign PatternsDesign in GeneralStandards
6.1. Class Foundations: Abstract Data Types (ADTs)Example of the Need for an ADTBenefits of Using ADTsMore Examples of ADTsHandling Multiple Instances of Data with ADTs in Non-Object-Oriented EnvironmentsADTs and Classes
Good AbstractionGood Encapsulation
Containment ("has a" Relationships)Inheritance ("is a" Relationships)Multiple InheritanceWhy Are There So Many Rules for Inheritance?Member Functions and DataConstructors
Classes to AvoidSummary of Reasons to Create a Class
Classes in GeneralC++JavaVisual Basic
7.1. Valid Reasons to Create a RoutineOperations That Seem Too Simple to Put Into RoutinesSummary of Reasons to Create a Routine
When to Use a Function and When to Use a ProcedureSetting the Function's Return Value
Limitations on the Use of Macro RoutinesInline Routines
8.1. Protecting Your Program from Invalid Inputs
Building Your Own Assertion MechanismGuidelines for Using Assertions
Robustness vs. CorrectnessHigh-Level Design Implications of Error Processing
Relationship Between Barricades and Assertions
Don't Automatically Apply Production Constraints to the Development VersionIntroduce Debugging Aids EarlyUse Offensive ProgrammingPlan to Remove Debugging Aids
SecurityAssertionsExceptions
9.1. Summary of Steps in Building Classes and RoutinesSteps in Creating a ClassSteps in Building a Routine
Design the RoutineCode the RoutineCheck the CodeClean Up LeftoversRepeat Steps as Needed
10.1. Data LiteracyThe Data Literacy TestAdditional Resources on Data Types
Implicit Declarations
Localize References to VariablesKeep Variables "Live" for as Short a Time as PossibleMeasuring the Live Time of a VariableGeneral Guidelines for Minimizing ScopeComments on Minimizing Scope
11.1. Considerations in Choosing Good NamesThe Most Important Naming ConsiderationProblem OrientationOptimum Name LengthThe Effect of Scope on Variable NamesComputed-Value Qualifiers in Variable NamesCommon Opposites in Variable Names
Naming Loop IndexesNaming Status VariablesNaming Temporary VariablesNaming Boolean VariablesNaming Enumerated TypesNaming Constants
Why Have Conventions?When You Should Have a Naming ConventionDegrees of Formality
Guidelines for a Language-Independent ConventionGuidelines for Language-Specific ConventionsC ConventionsC++ ConventionsJava ConventionsVisual Basic ConventionsMixed-Language Programming ConsiderationsSample Naming Conventions
User-Defined Type AbbreviationsSemantic PrefixesAdvantages of Standardized Prefixes
General Abbreviation GuidelinesPhonetic AbbreviationsComments on Abbreviations
12.1. Numbers in General
Strings in C
If Your Language Doesn't Have Enumerated Types
Why Are the Examples of Creating Your Own Types in Pascal and Ada?Guidelines for Creating Your Own Types
13.1. Structures
Paradigm for Understanding PointersLocation in MemoryKnowledge of How to Interpret the ContentsGeneral Tips on PointersC++-Pointer PointersC-Pointer Pointers
Common Problems with Global DataReasons to Use Global DataUse Global Data Only as a Last ResortUsing Access Routines Instead of Global DataAdvantages of Access RoutinesHow to Use Access RoutinesHow to Reduce the Risks of Using Global Data
14.1. Statements That Must Be in a Specific Order
Making Code Read from Top to BottomGrouping Related Statements
15.1. if StatementsPlain if-then StatementsChains of if-then-else Statements
Choosing the Most Effective Ordering of CasesTips for Using case Statements
16.1. Selecting the Kind of LoopWhen to Use a while LoopLoop with Test at the BeginningLoop with Test at the EndWhen to Use a Loop-With-Exit LoopNormal Loop-With-Exit LoopsAbnormal Loop-With-Exit LoopsWhen to Use a for LoopWhen to Use a foreach Loop
Entering the LoopProcessing the Middle of the LoopExiting the LoopExiting Loops EarlyChecking EndpointsUsing Loop VariablesHow Long Should a Loop Be?
17.1. Multiple Returns from a Routine
Example of RecursionTips for Using Recursion
The Argument Against gotosThe Argument for gotosThe Phony goto DebateError Processing and gotosComparison of the Approachesgotos and Sharing Code in an else ClauseSummary of Guidelines for Using gotos
Returnsgotos
18.1. General Considerations in Using Table-Driven MethodsTwo Issues in Using Table-Driven Methods
Days-in-Month ExampleInsurance Rates ExampleFlexible-Message-Format ExampleLogic-Based ApproachObject-Oriented ApproachTable-Driven ApproachFudging Lookup Keys
19.1. Boolean ExpressionsUsing true and false for Boolean TestsMaking Complicated Expressions SimpleForming Boolean Expressions PositivelyUsing Parentheses to Clarify Boolean ExpressionsKnowing How Boolean Expressions Are EvaluatedWriting Numeric Expressions in Number-Line OrderGuidelines for Comparisons to 0Common Problems with Boolean Expressions
Summary of Techniques for Reducing Deep Nesting
The Three Components of Structured ProgrammingSequenceSelectionIteration
How Important Is Complexity?General Guidelines for Reducing ComplexityHow to Measure ComplexityWhat to Do with Your Complexity MeasurementOther Kinds of Complexity
20.1. Characteristics of Software Quality
Development ProcessSetting Objectives
Percentage of Defects DetectedCost of Finding DefectsCost of Fixing Defects
Relevant Standards
21.1. Overview of Collaborative Development PracticesCollaborative Construction Complements Other Quality-Assurance TechniquesCollaborative Construction Provides Mentoring in Corporate Culture and Programming ExpertiseCollective Ownership Applies to All Forms of Collaborative ConstructionCollaboration Applies As Much Before Construction As After
Keys to Success with Pair ProgrammingBenefits of Pair Programming
What Results Can You Expect from Inspections?Roles During an InspectionGeneral Procedure for an InspectionFine-Tuning the InspectionEgos in InspectionsInspections and Code CompleteInspection Summary
Walk-ThroughsWhat Results Can You Expect from a Walk-Through?Code ReadingDog-and-Pony Shows
Pair ProgrammingInspectionsRelevant Standards
22.1. Role of Developer Testing in Software QualityTesting During Construction
Test First or Test Last?Limitations of Developer Testing
Incomplete TestingStructured Basis TestingData-Flow TestingCombinations of Data StatesEquivalence PartitioningError GuessingBoundary AnalysisCompound BoundariesClasses of Bad DataClasses of Good DataUse Test Cases That Make Hand-Checks Convenient
Which Classes Contain the Most Errors?Errors by ClassificationProportion of Errors Resulting from Faulty ConstructionHow Many Errors Should You Expect to Find?Errors in Testing Itself
Building Scaffolding to Test Individual ClassesDiff ToolsTest-Data GeneratorsCoverage MonitorsData Recorder/LoggingSymbolic DebuggersSystem PerturbersError Databases
Planning to TestRetesting (Regression Testing)Automated Testing
Personal Test RecordsAdditional ResourcesTestingTest ScaffoldingTest First DevelopmentRelevant Standards
23.1. Overview of Debugging IssuesRole of Debugging in Software QualityVariations in Debugging PerformanceDefects as OpportunitiesAn Ineffective ApproachThe Devil's Guide to DebuggingDebugging by Superstition
The Scientific Method of DebuggingStabilize the ErrorLocate the Source of the ErrorTips for Finding DefectsBrute-Force DebuggingSyntax Errors
How "Psychological Set" Contributes to Debugging BlindnessHow "Psychological Distance" Can Help
Source-Code ComparatorsCompiler Warning MessagesExtended Syntax and Logic CheckingExecution ProfilersTest Frameworks/ScaffoldingDebuggers
24.1. Kinds of Software EvolutionPhilosophy of Software Evolution
Reasons to RefactorReasons Not to Refactor
Data-Level RefactoringsStatement-Level RefactoringsRoutine-Level RefactoringsClass Implementation RefactoringsClass Interface RefactoringsSystem-Level Refactorings
Bad Times to Refactor
25.1. Performance OverviewQuality Characteristics and PerformancePerformance and Code TuningProgram RequirementsProgram DesignClass and Routine DesignOperating-System InteractionsCode CompilationHardwareCode Tuning
The Pareto PrincipleOld Wives' TalesWhen to TuneCompiler Optimizations
Common Sources of InefficiencyRelative Performance Costs of Common Operations
Measurements Need to Be Precise
PerformanceAlgorithms and Data Types
26.1. LogicStop Testing When You Know the AnswerOrder Tests by FrequencyCompare Performance of Similar Logic StructuresSubstitute Table Lookups for Complicated ExpressionsUse Lazy Evaluation
UnswitchingJammingUnrollingMinimizing the Work Inside LoopsSentinel ValuesPutting the Busiest Loop on the InsideStrength Reduction
Use Integers Rather Than Floating-Point NumbersUse the Fewest Array Dimensions PossibleMinimize Array ReferencesUse Supplementary IndexesString-Length IndexIndependent, Parallel Index StructureUse Caching
Exploit Algebraic IdentitiesUse Strength ReductionInitialize at Compile TimeBe Wary of System RoutinesUse the Correct Type of ConstantsPrecompute ResultsEliminate Common Subexpressions
Rewrite Routines Inline
27.1. Communication and Size
Activity Proportions and SizePrograms, Products, Systems, and System ProductsMethodology and Size
28.1. Encouraging Good CodingConsiderations in Setting StandardsTechniques for Encouraging Good CodingThe Role of This Book
What Is Configuration Management?Requirements and Design ChangesSoftware Code ChangesTool VersionsMachine ConfigurationsBackup PlanAdditional Resources on Configuration Management
Estimation ApproachesEstimating the Amount of ConstructionInfluences on ScheduleEstimation vs. ControlWhat to Do If You're BehindAdditional Resources on Software Estimation
Additional Resources on Software Measurement
How Do Programmers Spend Their Time?Variation in Performance and QualityIndividual VariationTeam VariationReligious IssuesPhysical EnvironmentAdditional Resources on Programmers as Human Beings
Additional Resources on Managing ConstructionRelevant Standards
29.1. Importance of the Integration Approach
Phased IntegrationIncremental IntegrationBenefits of Incremental Integration
Top-Down IntegrationBottom-Up IntegrationSandwich IntegrationRisk-Oriented IntegrationFeature-Oriented IntegrationT-Shaped IntegrationSummary of Integration Approaches
What Kinds of Projects Can Use the Daily Build Process?Continuous Integration
IntegrationIncrementalism
30.1. Design Tools
EditingIntegrated Development Environments (IDEs)Multiple-File String Searching and ReplacingDiff ToolsMerge ToolsSource-Code BeautifiersInterface Documentation ToolsTemplatesCross-Reference ToolsClass Hierarchy GeneratorsAnalyzing Code QualityPicky Syntax and Semantics CheckersMetrics ReportersRefactoring Source CodeRefactorersRestructurersCode TranslatorsVersion ControlData Dictionaries
Code CreationCompilers and LinkersBuild ToolsCode LibrariesCode-Generation WizardsSetup and InstallationPreprocessorsDebuggingTestingCode TuningExecution ProfilersAssembler Listings and Disassemblers
Project-Specific ToolsScripts
31.1. Layout FundamentalsLayout ExtremesThe Fundamental Theorem of FormattingHuman and Computer Interpretations of a ProgramHow Much Is Good Layout Worth?Layout as ReligionObjectives of Good LayoutHow to Put the Layout Objectives to Use
White SpaceParentheses
Pure BlocksEmulating Pure BlocksUsing begin-end Pairs (Braces) to Designate Block BoundariesEndline LayoutWhich Style Is Best?
Fine Points of Formatting Control-Structure BlocksOther Considerations
Statement LengthUsing Spaces for ClarityFormatting Continuation LinesUsing Only One Statement Per LineLaying Out Data Declarations
Laying Out Class InterfacesLaying Out Class ImplementationsLaying Out Files and Programs
32.1. External Documentation
Kinds of CommentsRepeat of the CodeExplanation of the CodeMarker in the CodeSummary of the CodeDescription of the Code's IntentInformation That Cannot Possibly Be Expressed by the Code ItselfCommenting EfficientlyOptimum Number of Comments
Commenting Individual LinesEndline Comments and Their ProblemsWhen to Use Endline CommentsCommenting Paragraphs of CodeCommenting Data DeclarationsCommenting Control StructuresCommenting RoutinesCommenting Classes, Files, and ProgramsGeneral Guidelines for Class DocumentationGeneral Guidelines for File DocumentationThe Book Paradigm for Program Documentation
Software-Development StandardsSoftware Quality-Assurance StandardsManagement StandardsOverview of Standards
33.1. Isn't Personal Character Off the Topic?
PersistenceExperienceGonzo Programming
34.1. Conquer Complexity
Separating a Program into Levels of AbstractionLevel 0: Operating-System Operations and Machine InstructionsLevel 1: Programming-Language Structures and ToolsLevel 2: Low-Level Implementation StructuresLevel 3: Low-Level Problem-Domain TermsLevel 4: High-Level Problem-Domain TermsLow-Level Techniques for Working in the Problem Domain
Software OraclesEclecticismExperimentation
35.1. Information About Software Construction
Overview MaterialSoftware-Engineering OverviewsOther Annotated Bibliographies
Lowbrow Programmer MagazinesHighbrow Programmer JournalsSpecial-Interest PublicationsProfessional PublicationsPopular-Market Publications
Introductory LevelPractitioner LevelProfessional Level

Content preview from Code Complete, 2nd Edition

The General Principle of Software Quality

There's no such thing as a free lunch, and even if there were, there's no guarantee that it would be any good. Software development is a far cry from haute cuisine, however, and software quality is unusual in a significant way. The General Principle of Software Quality is that improving quality reduces development costs.

Understanding this principle depends on understanding a key observation: the best way to improve productivity and quality is to reduce the time spent reworking code, whether the rework arises from changes in requirements, changes in design, or debugging. The industry-average productivity ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Start your free trial

Designing Data-Intensive Applications, 2nd Edition

Publisher Resources

ISBN: 0735619670Publisher Website

Code Complete, 2nd Edition

by Steve McConnell

The General Principle of Software Quality

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

You might also like

Designing Data-Intensive Applications, 2nd Edition

Fundamentals of Software Architecture, 2nd Edition

Learning Go, 2nd Edition

Ultimate Go Programming, Second Edition

Publisher Resources