Index

A note on the digital index

A link in an index entry is displayed as the section title in which that entry appears. Because some sections have multiple index markers, it is not unusual for an entry to have several links to the same section. Clicking on any link will take you directly to the place in the text in which the marker appears.

Symbols

& (pointer reference symbol), General Tips on Pointers
* (pointer declaration symbol), General Tips on Pointers, C++-Pointer Pointers, Laying Out Data Declarations
80/20 rule, Introduction to Code Tuning
–> (pointer symbol), General Tips on Pointers

A

abbreviation of names, Phonetic Abbreviations
abstract data types, More Examples of ADTs
Abstract Factory pattern, Look for Common Design Patterns
abstraction, Find Real-World Objects, Find Real-World Objects, Look for Common Design Patterns, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Inheritance ("is a" Relationships), Constructors, Beyond Classes: Packages, Beyond Classes: Packages, Valid Reasons to Create a Routine, Advantages of Access Routines, Conquer Complexity, Focus Your Attention with the Help of Conventions, Level 0: Operating-System Operations and Machine Instructions, Level 0: Operating-System Operations and Machine Instructions, Level 0: Operating-System Operations and Machine Instructions, Level 0: Operating-System Operations and Machine Instructions, Level 3: Low-Level Problem-Domain Terms
access routines for, Advantages of Access Routines
air lock analogy, Good Abstraction
checklist, Beyond Classes: Packages
classes for, Constructors, Beyond Classes: Packages
cohesion with, Good Abstraction
complexity, for handling, Conquer Complexity
consistent level for class interfaces, Good Abstraction
defined, Find Real-World Objects
erosion under modification problem, Good Abstraction
evaluating, Good Abstraction
exactness goal, Good Abstraction
forming consistently, Find Real-World Objects
good example for class interfaces, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
guidelines for creating class interfaces, Good Abstraction
high-level problem domain terms, Level 3: Low-Level Problem-Domain Terms
implementation structures, low-level, Level 0: Operating-System Operations and Machine Instructions
inconsistent, Good Abstraction, Good Abstraction
interfaces, goals for, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
levels of, Focus Your Attention with the Help of Conventions
opposites, pairs of, Good Abstraction
OS level, Level 0: Operating-System Operations and Machine Instructions
patterns for, Look for Common Design Patterns
placing items in inheritance trees, Inheritance ("is a" Relationships)
poor example for class interfaces, Good Abstraction
problem domain terms, low-level, Level 0: Operating-System Operations and Machine Instructions
programming-language level, Level 0: Operating-System Operations and Machine Instructions
routines for, Valid Reasons to Create a Routine
access routines, Use Global Data Only as a Last Resort, Use Global Data Only as a Last Resort, Use Global Data Only as a Last Resort, Advantages of Access Routines, Advantages of Access Routines, Advantages of Access Routines, Advantages of Access Routines, Advantages of Access Routines, Advantages of Access Routines, How to Use Access Routines, How to Use Access Routines, How to Use Access Routines
abstraction benefit, Advantages of Access Routines (see ; )
abstraction, level of, How to Use Access Routines
advantages of, Use Global Data Only as a Last Resort
barricaded variables benefit, Use Global Data Only as a Last Resort
centralized control from, Use Global Data Only as a Last Resort
creating, Advantages of Access Routines
g_ prefix guideline, Advantages of Access Routines
information hiding benefit, Advantages of Access Routines
lack of support for, overcoming, Advantages of Access Routines
locking, How to Use Access Routines
parallelism from, How to Use Access Routines
requiring, Advantages of Access Routines
accidental problems, Design Is Emergent
accreting a system metaphor, Software Farming: Growing a System
accuracy, Characteristics of Software Quality
Ada, Choice of Programming Language, How Long Can a Routine Be?
description of, Choice of Programming Language
parameter order, How Long Can a Routine Be?
adaptability, Characteristics of Software Quality
Adapter pattern, Look for Common Design Patterns
addition, dangers of, Integers
ADTs (abstract data types), Class Foundations: Abstract Data Types (ADTs), Class Foundations: Abstract Data Types (ADTs), Class Foundations: Abstract Data Types (ADTs), Class Foundations: Abstract Data Types (ADTs), Class Foundations: Abstract Data Types (ADTs), Example of the Need for an ADT, Benefits of Using ADTs, Benefits of Using ADTs, Benefits of Using ADTs, Benefits of Using ADTs, Benefits of Using ADTs, Benefits of Using ADTs, Benefits of Using ADTs, Benefits of Using ADTs, Benefits of Using ADTs, More Examples of ADTs, More Examples of ADTs, More Examples of ADTs, More Examples of ADTs, More Examples of ADTs, More Examples of ADTs, More Examples of ADTs, More Examples of ADTs, More Examples of ADTs, More Examples of ADTs, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Use Global Data Only as a Last Resort
abstraction with, More Examples of ADTs (see ; ; )
access routines, Use Global Data Only as a Last Resort
benefits of, Class Foundations: Abstract Data Types (ADTs)
changes not propagating benefit, Benefits of Using ADTs
classes based on, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
cooling system example, Benefits of Using ADTs
data, meaning of, Class Foundations: Abstract Data Types (ADTs)
defined, Class Foundations: Abstract Data Types (ADTs)
documentation benefit, Benefits of Using ADTs
explicit instancing, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
files as, More Examples of ADTs
guidelines, More Examples of ADTs
hiding information with, Example of the Need for an ADT
implicit instancing, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
instancing, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
interfaces, making more informative, Benefits of Using ADTs
low-level data types as, More Examples of ADTs
media independence with, More Examples of ADTs
multiple instances, handling, More Examples of ADTs
need for, example of, Class Foundations: Abstract Data Types (ADTs)
non-object-oriented languages with, More Examples of ADTs
objects as, More Examples of ADTs
operations examples, table of, Benefits of Using ADTs
passing of data, minimization of, Benefits of Using ADTs
performance improvements with, Benefits of Using ADTs
purpose of, Class Foundations: Abstract Data Types (ADTs)
real-world entities, working with, Benefits of Using ADTs
representation question, More Examples of ADTs
simple items as, More Examples of ADTs
verification of code benefit, Benefits of Using ADTs
agile development, General Software-Development Approaches, Methodology and Size
algebraic identities, Expressions
algorithms, The Importance of Metaphors, How to Use Software Metaphors, Design the Routine, Performance, Commenting Routines
commenting, Commenting Routines
heuristics compared to, How to Use Software Metaphors
metaphors serving as, The Importance of Metaphors
resources on, Performance
routines, planning for, Design the Routine
aliasing, Arrays
analysis skills development, Curiosity
approaches to development, Choosing Between Iterative and Sequential Approaches, General Software-Development Approaches, General Software-Development Approaches, General Software-Development Approaches, Iterate, Argument for Top Down, Percentage of Defects Detected, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise, Methodology and Size, Benefits of Incremental Integration, Bottom-Up Integration, Integration, Conquer Complexity, Conquer Complexity, Pick Your Process, Pick Your Process, Information About Software Construction
agile development, General Software-Development Approaches, Methodology and Size (see )
bottom-up approaches, Argument for Top Down, Bottom-Up Integration
Extreme Programming, General Software-Development Approaches, Percentage of Defects Detected, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise, Integration, Information About Software Construction
importance of, Conquer Complexity
premature optimization problem, Pick Your Process
quality control, Pick Your Process
(see also )
resources for, General Software-Development Approaches
sequential approach, Choosing Between Iterative and Sequential Approaches
team processes, Conquer Complexity
top-down approaches, Iterate, Benefits of Incremental Integration
architecture, Handling Requirements Changes During Construction, Architecture Prerequisite, Architecture Prerequisite, Architecture Prerequisite, Typical Architectural Components, Typical Architectural Components, Program Organization, Program Organization, Program Organization, Business Rules, Business Rules, Business Rules, Business Rules, Performance, Performance, Performance, Performance, Performance, Input/Output, Input/Output, Error Processing, Error Processing, Architectural Feasibility, Architectural Feasibility, Architectural Feasibility, Reuse Decisions, Reuse Decisions, Reuse Decisions, Reuse Decisions, Reuse Decisions, General Architectural Quality, General Architectural Quality, General Architectural Quality, General Architectural Quality, Amount of Time to Spend on Upstream Prerequisites, Requirements, Key Points, Program Design, Effect of Project Size on Development Activities
building block definition, Typical Architectural Components (see )
business rules, Program Organization
buying vs. building components, Architectural Feasibility
changes, Architecture Prerequisite, Reuse Decisions
checklist for, General Architectural Quality
class design, Program Organization
commitment delay strategy, Reuse Decisions
conceptual integrity of, Reuse Decisions
data design, Program Organization
defined, Handling Requirements Changes During Construction
error handling, Input/Output
fault tolerance, Error Processing
GUIs, Business Rules
importance of, Architecture Prerequisite
input/output, Input/Output
internationalization planning, Performance
interoperability, Performance
key point for, Key Points
localization planning, Performance
machine independence, General Architectural Quality
overengineering, Architectural Feasibility
percent of total activity, by size of project, Effect of Project Size on Development Activities
performance goals, Performance
performance-oriented, Program Design
prerequisite nature of, Architecture Prerequisite
program organization, Typical Architectural Components
quality, Reuse Decisions, General Architectural Quality
resource management, Business Rules
resources on developing, Requirements
reuse decisions, Reuse Decisions
risky areas, identifying, General Architectural Quality
scalability, Performance
security design, Business Rules
technical feasibility, Architectural Feasibility
time allowed for, Amount of Time to Spend on Upstream Prerequisites
user interface design, Business Rules
validation design, Error Processing
arithmetic expressions, Integers, Floating-Point Numbers, Sentinel Values, Human and Computer Interpretations of a Program
magnitudes, greatly different, Integers
misleading precedence example, Human and Computer Interpretations of a Program
multiplication, changing to addition, Sentinel Values
rounding errors, Floating-Point Numbers
arrays, User-Defined Type Abbreviations, User-Defined Type Abbreviations, Named Constants, Named Constants, Named Constants, Named Constants, Named Constants, Named Constants, Arrays, Arrays, Guidelines for Creating Your Own Types, When to Use a for Loop, Creating Loops Easily—From the Inside Out, Data-Level Refactorings, Old Wives' Tales, Relative Performance Costs of Common Operations, Relative Performance Costs of Common Operations, Minimizing the Work Inside Loops, Use Integers Rather Than Floating-Point Numbers, Use the Fewest Array Dimensions Possible, Using Spaces for Clarity
C language macro for, Arrays (see )
checklist, Guidelines for Creating Your Own Types
containers as an alternative, Named Constants
costs of operations, Relative Performance Costs of Common Operations
cross-talk, Arrays
defined, Named Constants
dimensions, minimizing, Use Integers Rather Than Floating-Point Numbers
end points, checking, Named Constants
foreach loops with, When to Use a for Loop
indexes of, Named Constants
layout of references, Using Spaces for Clarity
loops with, Creating Loops Easily—From the Inside Out
multidimensional, Named Constants
naming conventions for, User-Defined Type Abbreviations
performance tuning, Old Wives' Tales, Relative Performance Costs of Common Operations
refactoring, Data-Level Refactorings
references, minimizing, Use the Fewest Array Dimensions Possible
semantic prefixes for, User-Defined Type Abbreviations
sentinel tests for loops, Minimizing the Work Inside Loops
sequential access guideline, Named Constants
assembly language, Choice of Programming Language, Rewrite Routines Inline, Code Tuning
description of, Choice of Programming Language
listing tools, Code Tuning
recoding to, Rewrite Routines Inline
assertions, Assertions, Assertions, Assertions, Assertions, Assertions, Assertions, Building Your Own Assertion Mechanism, Building Your Own Assertion Mechanism, Building Your Own Assertion Mechanism, Building Your Own Assertion Mechanism, Building Your Own Assertion Mechanism, Guidelines for Using Assertions, Guidelines for Using Assertions, Guidelines for Using Assertions, Guidelines for Using Assertions, Guidelines for Using Assertions, Relationship Between Barricades and Assertions, Introduce Debugging Aids Early, Being Defensive About Defensive Programming, Statements That Must Be in a Specific Order
aborting program recommended, Introduce Debugging Aids Early
arguments for, Assertions
assumptions to check, list of, Assertions
barricades, relation to, Relationship Between Barricades and Assertions
benefits of, Assertions
building your own mechanism for, Building Your Own Assertion Mechanism
C++ example, Building Your Own Assertion Mechanism
dangerous use of example, Guidelines for Using Assertions
defined, Assertions
dependencies, checking for, Statements That Must Be in a Specific Order
error handling with, Building Your Own Assertion Mechanism, Guidelines for Using Assertions
executable code in, Building Your Own Assertion Mechanism
guidelines for, Building Your Own Assertion Mechanism
Java example of, Assertions
postcondition verification, Guidelines for Using Assertions
precondition verification, Guidelines for Using Assertions
removing from code, Assertions
resources for, Being Defensive About Defensive Programming
Visual Basic examples, Guidelines for Using Assertions
assignment statements, General Guidelines for Minimizing Scope, Formatting Continuation Lines
author role in inspections, What Results Can You Expect from Inspections?
automated testing, Improving Your Testing
auto_ptrs, C++-Pointer Pointers

B

backup plans, Machine Configurations, Backup Plan
bad data, testing for, Boundary Analysis
barricades, Exceptions, Exceptions, Barricade Your Program to Contain the Damage Caused by Errors, Barricade Your Program to Contain the Damage Caused by Errors, Barricade Your Program to Contain the Damage Caused by Errors, Relationship Between Barricades and Assertions
assertions, relation to, Relationship Between Barricades and Assertions
class-level, Barricade Your Program to Contain the Damage Caused by Errors
input data conversions, Barricade Your Program to Contain the Damage Caused by Errors
interfaces as boundaries, Exceptions
operating room analogy, Barricade Your Program to Contain the Damage Caused by Errors
purpose of, Exceptions
base classes, Find Real-World Objects, Good Encapsulation, Good Encapsulation, Containment ("has a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships)
abstract overridable routines, Inheritance ("is a" Relationships) (see )
abstraction aspect of, Find Real-World Objects
coupling, too tight, Good Encapsulation
Liskov Substitution Principle, Containment ("has a" Relationships)
overridable vs. non-overridable routines, Inheritance ("is a" Relationships)
protected data, Good Encapsulation
routines overridden to do nothing, Inheritance ("is a" Relationships)
single classes from, Inheritance ("is a" Relationships)
Basic, Java
(see also )
basis testing, structured, Testing During Construction, Bag of Testing Tricks
BCD (binary coded decimal) type, Floating-Point Numbers
BDUF (big design up front), Comments on Popular Methodologies
beauty, Desirable Characteristics of a Design
begin-end pairs, Using begin-end Pairs (Braces) to Designate Block Boundaries
bibliographies, software, Overview Material
big design up front (BDUF), Comments on Popular Methodologies
big-bang integration, Importance of the Integration Approach
binary searches, Stair-Step Access Tables
binding, Avoid Failure, Persistence, Persistence, Persistence, Binding Time, Binding Time, Binding Time, Using Each Variable for Exactly One Purpose
compile time, Persistence
heuristic design with, Avoid Failure
in code, Persistence
just in time, Binding Time
key point, Using Each Variable for Exactly One Purpose
load time, Binding Time
run time, Binding Time
variables, timing of, Persistence
black-box testing, Developer Testing
blank lines for formatting, Fine Points of Formatting Control-Structure Blocks, Laying Out Comments
blocks, Common Problems with Boolean Expressions, Common Problems with Boolean Expressions, Common Problems with Boolean Expressions, Parentheses, Pure Blocks, Other Considerations, When to Use Endline Comments
braces writing rule, Common Problems with Boolean Expressions
comments on, When to Use Endline Comments
conditionals, clarifying, Common Problems with Boolean Expressions
defined, Common Problems with Boolean Expressions
emulated pure layout style, Pure Blocks
pure, layout style, Parentheses
single statements, Other Considerations
Book Paradigm, The Book Paradigm for Program Documentation
boolean expressions, General Control Issues, Using true and false for Boolean Tests, Using true and false for Boolean Tests, Using true and false for Boolean Tests, Using true and false for Boolean Tests, Making Complicated Expressions Simple, Making Complicated Expressions Simple, Making Complicated Expressions Simple, Making Complicated Expressions Simple, Making Complicated Expressions Simple, Forming Boolean Expressions Positively, Using Parentheses to Clarify Boolean Expressions, Using Parentheses to Clarify Boolean Expressions, Using Parentheses to Clarify Boolean Expressions, Knowing How Boolean Expressions Are Evaluated, Knowing How Boolean Expressions Are Evaluated, Writing Numeric Expressions in Number-Line Order, Writing Numeric Expressions in Number-Line Order, Writing Numeric Expressions in Number-Line Order, Writing Numeric Expressions in Number-Line Order, Guidelines for Comparisons to 0, Guidelines for Comparisons to 0, Common Problems with Boolean Expressions, Other Kinds of Complexity, Data-Level Refactorings, Expressions, Other Considerations
0, comparisons to, Writing Numeric Expressions in Number-Line Order (see ; ; )
0s and 1s as values, Using true and false for Boolean Tests
breaking into partial tests, Using true and false for Boolean Tests
C languages syntax, Guidelines for Comparisons to 0
characters, comparisons to zero, Writing Numeric Expressions in Number-Line Order
checklist for, Other Kinds of Complexity
constants in comparisons, Guidelines for Comparisons to 0
decision tables, moving to, Making Complicated Expressions Simple
DeMorgan's Theorems, applying, Forming Boolean Expressions Positively
evaluation guidelines, Using Parentheses to Clarify Boolean Expressions
functions, moving to, Making Complicated Expressions Simple
identifiers for, General Control Issues
if statements, negatives in, Making Complicated Expressions Simple
implicit comparisons, Using true and false for Boolean Tests
Java syntax, Knowing How Boolean Expressions Are Evaluated, Common Problems with Boolean Expressions
layout guidelines, Other Considerations
logical identities, Expressions
negatives in, Making Complicated Expressions Simple
numeric, structuring, Knowing How Boolean Expressions Are Evaluated
parentheses for clarifying, Using Parentheses to Clarify Boolean Expressions
pointers, comparisons with, Writing Numeric Expressions in Number-Line Order
positive form recommended, Making Complicated Expressions Simple
refactoring, Data-Level Refactorings
short circuit evaluation, Using Parentheses to Clarify Boolean Expressions
simplifying, Using true and false for Boolean Tests
zero, comparisons to, Writing Numeric Expressions in Number-Line Order
boolean functions, Chains of if-then-else Statements, Making Complicated Expressions Simple
creating from expressions, Making Complicated Expressions Simple
if statements, used in, Chains of if-then-else Statements
boolean tests, Valid Reasons to Create a Routine, Strings in C, Using true and false for Boolean Tests, Writing Numeric Expressions in Number-Line Order
breaking into partial tests, Using true and false for Boolean Tests (see )
hiding with routines, Valid Reasons to Create a Routine
simplifying, Strings in C
zero, comparisons to, Writing Numeric Expressions in Number-Line Order
boolean variables, Naming Temporary Variables, Strings in C, Strings in C, Boolean Variables, Enumerated Types, Guidelines for Creating Your Own Types, General Control Issues, Using true and false for Boolean Tests, Using true and false for Boolean Tests
0s and 1s as values, Using true and false for Boolean Tests (see ; )
C, creating data type, Boolean Variables
checklist, Guidelines for Creating Your Own Types
documentation with, Strings in C
enumerated types as alternative, Enumerated Types
identifiers for, General Control Issues
naming, Naming Temporary Variables
simplifying tests with, Strings in C
zeros and ones as values, Using true and false for Boolean Tests
boss readiness test on prerequisites, Appeal to Data
bottom-up approach to design, Argument for Top Down
bottom-up integration, Bottom-Up Integration
boundary analysis, Error Guessing
braces, How Much Is Good Layout Worth?, Pure Blocks
block layout with, Pure Blocks
styles compared, How Much Is Good Layout Worth?
break statements, Normal Loop-With-Exit Loops, Exiting the Loop, Exiting the Loop, Exiting Loops Early, Exiting Loops Early, Exiting Loops Early, Taming Dangerously Deep Nesting
C++ loops, Normal Loop-With-Exit Loops
caution about, Exiting Loops Early
guidelines, Exiting the Loop
labeled, Exiting Loops Early
multiple in one loop, Exiting Loops Early
nested-if simplification with, Taming Dangerously Deep Nesting
while loops with, Exiting the Loop
bridge failure, Tacoma Narrows, Design in Construction
Bridge pattern, Look for Common Design Patterns
brute-force debugging, Tips for Finding Defects
buffer overruns, Error-Handling Techniques
bugs, Typical Errors, Which Classes Contain the Most Errors?, Tips for Finding Defects
build tools, Executable-Code Tools
(see also )
building metaphor, Software Oyster Farming: System Accretion
building vs. buying components, Software Construction: Building Software
builds, daily, Daily Build and Smoke Test
business rules, Boss-Readiness Test, Program Organization, Level 2: Division into Subsystems or Packages, Identify Areas Likely to Change
architecture prerequisites, Program Organization
change, identifying areas of, Identify Areas Likely to Change
good practices table for, Boss-Readiness Test
subsystem design, Level 2: Division into Subsystems or Packages
buying components, Software Construction: Building Software, Architectural Feasibility

C

C language, C, More Examples of ADTs, Guidelines for Language-Specific Conventions, Sample Naming Conventions, Characters and Strings, Characters and Strings, Guidelines for Creating Your Own Types, C++-Pointer Pointers, Guidelines for Comparisons to 0
ADTs with, More Examples of ADTs
boolean expression syntax, Guidelines for Comparisons to 0
description of, C
naming conventions for, Guidelines for Language-Specific Conventions, Sample Naming Conventions
pointers, C++-Pointer Pointers
string data types, Characters and Strings, Guidelines for Creating Your Own Types
string index errors, Characters and Strings
C#, C
C++, C, Good Encapsulation, Classes in General, When to Use a Function and When to Use a Procedure, Macro Routines and Inline Routines, Building Your Own Assertion Mechanism, Exceptions, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Guidelines for Language-Specific Conventions, Knowledge of How to Interpret the Contents, General Tips on Pointers, C++-Pointer Pointers, Guidelines for Comparisons to 0, Null Statements, Null Statements, Endline Layout, Using Only One Statement Per Line, Laying Out Data Declarations, Laying Out Files and Programs
assertion example, Building Your Own Assertion Mechanism
boolean expression syntax, Guidelines for Comparisons to 0
debugging stubs with, Plan to Remove Debugging Aids
description of, C
DoNothing() macros, Null Statements
exceptions in, Exceptions
inline routines, Macro Routines and Inline Routines
interface considerations, Good Encapsulation
layout recommended, Endline Layout
macro routines, When to Use a Function and When to Use a Procedure
naming conventions for, Guidelines for Language-Specific Conventions
null statements, Null Statements
parameters, by reference vs. by value, C++-Pointer Pointers
pointers, Knowledge of How to Interpret the Contents, General Tips on Pointers, Laying Out Data Declarations
preprocessors, excluding debug code, Plan to Remove Debugging Aids
resources for, Classes in General
side effects, Using Only One Statement Per Line
source files, layout in, Laying Out Files and Programs
caching, code tuning with, Independent, Parallel Index Structure
Capability Maturity Model (CMM), Inspections and Code Complete
capturing design work, How Much Design Is Enough?
Cardinal Rule of Software Evolution, Philosophy of Software Evolution
CASE (computer-aided software engineering) tools, Programming Tools
case statements, Inheritance ("is a" Relationships), Introduce Debugging Aids Early, case Statements, case Statements, case Statements, case Statements, case Statements, case Statements, case Statements, case Statements, Tips for Using case Statements, Tips for Using case Statements, Tips for Using case Statements, Tips for Using case Statements, Tips for Using case Statements, Key Points, Table-Driven Approach, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Reasons to Refactor, Reasons to Refactor, Statement-Level Refactorings, Order Tests by Frequency, Compare Performance of Similar Logic Structures, Other Considerations
alpha ordering, case Statements (see ; ; )
checklist, Tips for Using case Statements
debugging, Introduce Debugging Aids Early
default clauses, Tips for Using case Statements
drop-throughs, Tips for Using case Statements
end of case statements, Tips for Using case Statements
endline layout, Other Considerations
error detection in, Tips for Using case Statements
frequency of execution ordering, case Statements, Order Tests by Frequency
if statements, comparing performance with, Compare Performance of Similar Logic Structures
key points, Key Points
language support for, case Statements
nested ifs, converting from, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting
normal case first rule, case Statements
numeric ordering, case Statements
ordering cases, case Statements
parallel modifications to, Reasons to Refactor
phony variables, case Statements
polymorphism preferable to, Inheritance ("is a" Relationships)
redesigning, Taming Dangerously Deep Nesting
refactoring, Reasons to Refactor, Statement-Level Refactorings
simple action guideline, case Statements
table-driven methods using, Table-Driven Approach
change control, Reuse Decisions
character arrays, Characters and Strings
(see also )
character data types, Floating-Point Numbers, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Guidelines for Creating Your Own Types
arrays vs. string pointers, 299 C language, Characters and Strings (see )
character sets, Characters and Strings
checklist, Guidelines for Creating Your Own Types
conversion strategies, Characters and Strings
magic (literal) characters, Floating-Point Numbers
Unicode, Characters and Strings, Characters and Strings
character, personal, Personal Character, Intelligence and Humility, Intelligence and Humility, Intelligence and Humility, Curiosity, Curiosity, Curiosity, Curiosity, Curiosity, Curiosity, Curiosity, Curiosity, Intellectual Honesty, Intellectual Honesty, Intellectual Honesty, Intellectual Honesty, Intellectual Honesty, Intellectual Honesty, Intellectual Honesty, Intellectual Honesty, Creativity and Discipline, Creativity and Discipline, Creativity and Discipline, Laziness, Persistence, Persistence, Experience, Habits, Habits, Habits, Additional Resources, Watch for Falling Rocks, Iterate, Repeatedly, Again and Again, Topics Beyond Construction
analysis skills, Curiosity
communication skills, Intellectual Honesty
compiler messages, treatment of, Intellectual Honesty
computer-science graduates, Creativity and Discipline
cooperation skills, Intellectual Honesty
creativity, Creativity and Discipline, Topics Beyond Construction
curiosity, Curiosity
development process awareness, Curiosity
discipline, Creativity and Discipline
estimations, Intellectual Honesty
experience, Persistence
experimentation, Curiosity
gonzo programming, Experience
habits, Habits
humility, Intelligence and Humility, Intellectual Honesty, Habits
importance of, Personal Character
intellectual honesty, Intellectual Honesty
intelligence, Intelligence and Humility
judgment, Watch for Falling Rocks
key points, Additional Resources
laziness, Laziness
mistakes, admitting to, Intellectual Honesty
persistence, Persistence
practices compensating for weakness, Intelligence and Humility
problem solving, Curiosity
professional development, Curiosity
reading, Curiosity
religion in programming, harmful effects of, Iterate, Repeatedly, Again and Again
resources on, Habits
status reporting, Intellectual Honesty
successful projects, learning from, Curiosity
checklists, The Myth of Stable Requirements, Handling Requirements Changes During Construction, Handling Requirements Changes During Construction, General Architectural Quality, General Software-Development Approaches, Example of Programming into a Language, Example of Programming into a Language, Selection of Major Construction Practices, Selection of Major Construction Practices, Standards, Beyond Classes: Packages, Beyond Classes: Packages, Beyond Classes: Packages, Beyond Classes: Packages, Inline Routines, Inline Routines, Being Defensive About Defensive Programming, Alternatives to the PPP, Alternatives to the PPP, Using Each Variable for Exactly One Purpose, Using Each Variable for Exactly One Purpose, Kinds of Names to Avoid, Kinds of Names to Avoid, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types, How to Reduce the Risks of Using Global Data, How to Reduce the Risks of Using Global Data, Additional Resources, Grouping Related Statements, Tips for Using case Statements, Tips for Using case Statements, Tips for Using case Statements, Correspondence Between Loops and Arrays, gotos, Stair-Step Access Tables, Other Kinds of Complexity, Other Kinds of Complexity, The General Principle of Software Quality, Keys to Success with Pair Programming, General Procedure for an Inspection, General Procedure for an Inspection, Inspections and Code Complete, Testing During Construction, Relevant Standards, Debuggers, Debuggers, Debuggers, Reasons to Refactor, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, Refactoring Strategies, Performance, Performance, Recoding in a Low-Level Language, Recoding in a Low-Level Language, Machine Configurations, Backup Plan, Continuous Integration, Continuous Integration, Additional Resources, Laying Out Files and Programs, Laying Out Files and Programs, Laying Out Files and Programs, Laying Out Files and Programs, Laying Out Files and Programs, Laying Out Files and Programs, Laying Out Files and Programs, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Additional Resources, Additional Resources
abstraction, Beyond Classes: Packages
architecture, General Architectural Quality
arrays, Guidelines for Creating Your Own Types
backups, Backup Plan
boolean expressions, Other Kinds of Complexity
case statements, Tips for Using case Statements
character data types, Guidelines for Creating Your Own Types
classes, Beyond Classes: Packages, Alternatives to the PPP, System-Level Refactorings, Laying Out Files and Programs, Programming Style as Documentation
code tuning, Performance, Recoding in a Low-Level Language
coding practices, Example of Programming into a Language
comments, Laying Out Files and Programs, Additional Resources
conditional statements, Tips for Using case Statements
configuration management, Machine Configurations
constants, Guidelines for Creating Your Own Types
construction practices, Example of Programming into a Language
control structures, Other Kinds of Complexity, Laying Out Files and Programs, Programming Style as Documentation
daily build and smoke tests, Continuous Integration
data organization, Programming Style as Documentation
data types, Guidelines for Creating Your Own Types
debugging, Debuggers
defects, General Procedure for an Inspection, Debuggers
defensive programming, Being Defensive About Defensive Programming
design, Standards, Programming Style as Documentation
documentation, Programming Style as Documentation, Additional Resources
encapsulation, Beyond Classes: Packages
enumerated types, Guidelines for Creating Your Own Types
fixing defects, Debuggers
formal inspections, General Procedure for an Inspection, Inspections and Code Complete
formatting, Laying Out Files and Programs
goto statements, gotos
if statements, Tips for Using case Statements
inheritance, Beyond Classes: Packages
initialization, Using Each Variable for Exactly One Purpose
integration, Continuous Integration
interfaces, System-Level Refactorings
layout, Laying Out Files and Programs
loops, Correspondence Between Loops and Arrays
names, Kinds of Names to Avoid, Programming Style as Documentation
pair programming, Keys to Success with Pair Programming
parameters, Inline Routines
performance tuning, Performance
pointers, Additional Resources
prerequisites, General Software-Development Approaches
programming tools, Additional Resources
pseudocoding, Alternatives to the PPP
quality assurance, Handling Requirements Changes During Construction, Selection of Major Construction Practices, The General Principle of Software Quality
refactoring, Reasons to Refactor, System-Level Refactorings, Refactoring Strategies
requirements, The Myth of Stable Requirements, Handling Requirements Changes During Construction
routines, Inline Routines, Laying Out Files and Programs, Programming Style as Documentation
speed, tuning for, Recoding in a Low-Level Language
statements, Laying Out Files and Programs
straight-line code, Grouping Related Statements
strings, Guidelines for Creating Your Own Types
structures, How to Reduce the Risks of Using Global Data
table-driven methods, Stair-Step Access Tables
testing, Testing During Construction, Relevant Standards
tools, Selection of Major Construction Practices
type creation, Guidelines for Creating Your Own Types
variables, Using Each Variable for Exactly One Purpose, Kinds of Names to Avoid, How to Reduce the Risks of Using Global Data
circular dependencies, Two Categories of Secrets
class-hierarchy generators, Interface Documentation Tools
classes, Program Organization, Level 3: Division into Classes, Level 3: Division into Classes, Inherit—When Inheritance Simplifies the Design, Secrets and the Right to Privacy, Keep Coupling Loose, Build Hierarchies, Working Classes, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Containment ("has a" Relationships), Containment ("has a" Relationships), Containment ("has a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Multiple Inheritance, Member Functions and Data, Member Functions and Data, Member Functions and Data, Member Functions and Data, Member Functions and Data, Constructors, Constructors, Constructors, Constructors, Constructors, Constructors, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Reasons to Create a Class, Summary of Reasons to Create a Class, Summary of Reasons to Create a Class, Beyond Classes: Packages, Beyond Classes: Packages, Beyond Classes: Packages, Beyond Classes: Packages, Beyond Classes: Packages, Classes in General, Key Points, Valid Reasons to Create a Routine, Summary of Steps in Building Classes and Routines, Summary of Steps in Building Classes and Routines, Steps in Creating a Class, Steps in Creating a Class, Pseudocode for Pros, Design the Routine, Clean Up Leftovers, Clean Up Leftovers, Alternatives to the PPP, Alternatives to the PPP, Alternatives to the PPP, Alternatives to the PPP, Guidelines for Initializing Variables, Informal Naming Conventions, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Sample Naming Conventions, Standardized Prefixes, Test-Support Tools, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Routine-Level Refactorings, Routine-Level Refactorings, Class Implementation Refactorings, Class Implementation Refactorings, Class Implementation Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, Bad Times to Refactor, Importance of the Integration Approach, Benefits of Incremental Integration, Bottom-Up Integration, Laying Out Routines, Laying Out Routines, Laying Out Class Implementations, Laying Out Class Implementations, Laying Out Class Implementations, Laying Out Files and Programs, Programming Style as Documentation, Programming Style as Documentation, General Guidelines for Class Documentation, Watch for Falling Rocks, Watch for Falling Rocks
abstract objects, modeling, Constructors (see )
abstraction checklist, Beyond Classes: Packages
alternates to PPP, Clean Up Leftovers
architecture prerequisites, Program Organization
assumptions about users, Good Encapsulation
bidirectional associations, System-Level Refactorings
calls to, refactoring, Class Implementation Refactorings
case statements vs. inheritance, Inheritance ("is a" Relationships)
centralizing control with, Reasons to Create a Class
changes, limiting effects of, Reasons to Create a Class
checklists, Beyond Classes: Packages, Laying Out Files and Programs, Programming Style as Documentation
coding routines from pseudocode, Design the Routine
cohesion as refactoring indicator, Reasons to Refactor
complexity issues, Constructors
constant values returned, Routine-Level Refactorings
constructors, Constructors
containment, Good Encapsulation
coupling considerations, Keep Coupling Loose, Good Encapsulation
data-free, Reasons to Create a Class
deep inheritance trees, Inheritance ("is a" Relationships)
defined, Working Classes
delegation vs. inheritance, refactoring, Class Interface Refactorings
descendants, refactoring indicator for, Reasons to Refactor
designing, Level 3: Division into Classes, Summary of Steps in Building Classes and Routines, Pseudocode for Pros, Alternatives to the PPP
disallowing functions and operators, Member Functions and Data
documenting, Programming Style as Documentation, General Guidelines for Class Documentation
encapsulation, Good Encapsulation, Beyond Classes: Packages
extension, refactoring with, Class Interface Refactorings
factoring, benefit of, Reasons to Create a Class
files containing, Laying Out Class Implementations
foreign routines, refactoring with, Class Interface Refactorings
formalizing contracts for interfaces, Build Hierarchies
formatting, Laying Out Routines
friend, encapsulation violation concern, Good Encapsulation
global data, hiding, Reasons to Create a Class
god classes, Reasons to Create a Class
hacking approach to, Alternatives to the PPP
hiding implementation details, Reasons to Create a Class
implementation checklist, Beyond Classes: Packages
indirect calls to other classes, Member Functions and Data
information hiding, Inherit—When Inheritance Simplifies the Design
inheritance, Containment ("has a" Relationships), Beyond Classes: Packages
initializing members, Guidelines for Initializing Variables
integration, Importance of the Integration Approach, Benefits of Incremental Integration, Bottom-Up Integration
irrelevant classes, Reasons to Create a Class
is a relationships, Containment ("has a" Relationships)
key points for, Key Points, Alternatives to the PPP
language-specific issues, Summary of Reasons to Create a Class
layout of, Laying Out Routines
limiting collaboration, Member Functions and Data
Liskov Substitution Principle, Containment ("has a" Relationships)
member variables, naming, Guidelines for a Language-Independent Convention, Standardized Prefixes
minimizing accessibility rule, Good Encapsulation
mixins, Multiple Inheritance
modeling real-world objects, Constructors
multiple per file, layout of, Laying Out Class Implementations
naming, Sample Naming Conventions, Sample Naming Conventions
number of members, Good Encapsulation
number of routines, Member Functions and Data
object names, differentiating from, Informal Naming Conventions
objects, contrasted with, Level 3: Division into Classes
overformatting, Laying Out Class Implementations
overriding routines, Inheritance ("is a" Relationships), Summary of Reasons to Create a Class
packages, Reasons to Create a Class
parallel modifications refactoring indicator, Reasons to Refactor
planning for program families, Reasons to Create a Class
private vs. protected data, Inheritance ("is a" Relationships)
private, declaring members as, Member Functions and Data
protected data, Inheritance ("is a" Relationships)
pseudocode for designing, Clean Up Leftovers
public members, Good Encapsulation, Good Encapsulation, Class Interface Refactorings
read-time convenience rule, Good Encapsulation
reasons for creating, Constructors
refactoring, Reasons to Create a Class, Routine-Level Refactorings, System-Level Refactorings, Bad Times to Refactor
resources, Classes in General
reusability benefit of, Reasons to Create a Class
review and test step, Steps in Creating a Class
routine construction step, Steps in Creating a Class
routines, unused, Inheritance ("is a" Relationships), Class Interface Refactorings
semantic violations of encapsulation, Good Encapsulation
Set() routines, unnecessary, Class Interface Refactorings
similar sub and superclasses, Class Interface Refactorings
single-instance, Inheritance ("is a" Relationships)
singleton property, enforcing, Constructors
steps in creating, Summary of Steps in Building Classes and Routines
streamlining parameter passing, Reasons to Create a Class
subclasses, Valid Reasons to Create a Routine, Class Implementation Refactorings
superclasses for common code, Class Implementation Refactorings
test-first development, Alternatives to the PPP
testing with stub objects, Test-Support Tools
unidirectional associations, System-Level Refactorings
visibility of, Secrets and the Right to Privacy
warning signs for, Watch for Falling Rocks, Watch for Falling Rocks
cleanroom development, How Many Errors Should You Expect to Find?
cleanup steps, PPP, Clean Up Leftovers
CMM (Capability Maturity Model), Inspections and Code Complete
Cobol, C
code coverage testing, Structured Basis Testing
code libraries, Design the Routine, Build Tools
code quality analysis tools, Interface Documentation Tools
code reading method, Code Reading
code tuning, Performance and Code Tuning, Performance and Code Tuning, Program Design, Program Design, Program Design, Program Design, Hardware, Hardware, Hardware, Hardware, Hardware, Introduction to Code Tuning, Introduction to Code Tuning, Introduction to Code Tuning, Introduction to Code Tuning, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Relative Performance Costs of Common Operations, Relative Performance Costs of Common Operations, Iteration, Iteration, Iteration, Iteration, Performance, Algorithms and Data Types, Algorithms and Data Types, Code-Tuning Techniques, Code-Tuning Techniques, Code-Tuning Techniques, Order Tests by Frequency, Compare Performance of Similar Logic Structures, Compare Performance of Similar Logic Structures, Substitute Table Lookups for Complicated Expressions, Use Lazy Evaluation, Use Lazy Evaluation, Unswitching, Jamming, Unrolling, Minimizing the Work Inside Loops, Sentinel Values, Sentinel Values, Sentinel Values, Strength Reduction, Use Integers Rather Than Floating-Point Numbers, Use Integers Rather Than Floating-Point Numbers, Minimize Array References, Independent, Parallel Index Structure, Expressions, Expressions, Expressions, Use Strength Reduction, Initialize at Compile Time, Be Wary of System Routines, Use the Correct Type of Constants, Use the Correct Type of Constants, Use the Correct Type of Constants, Use the Correct Type of Constants, Precompute Results, Eliminate Common Subexpressions, Eliminate Common Subexpressions, Rewrite Routines Inline, Rewrite Routines Inline, Recoding in a Low-Level Language, Recoding in a Low-Level Language, The More Things Change, the More They Stay the Same, The More Things Change, the More They Stay the Same, The More Things Change, the More They Stay the Same, Additional Resources, Code Tuning, Code Tuning, Code Tuning, Code Tuning, Watch for Falling Rocks
80/20 rule, Introduction to Code Tuning (see )
advantages from, Hardware
algebraic identities, Expressions
appeal of, Hardware
arrays, Old Wives' Tales, Relative Performance Costs of Common Operations, Use Integers Rather Than Floating-Point Numbers
assembler, listing tools, Code Tuning
assembler, recoding to, Rewrite Routines Inline
bottleneck identification, Old Wives' Tales
caching data, Independent, Parallel Index Structure
checklists, Performance, Recoding in a Low-Level Language
comparing logic structures, Compare Performance of Similar Logic Structures
competing objectives dilemma, Old Wives' Tales
compiler considerations, Program Design, Old Wives' Tales
converting data types, Use the Correct Type of Constants
correctness, importance of, Old Wives' Tales
data transformations, Strength Reduction
data type choices, Use the Correct Type of Constants
database indexing, Common Sources of Inefficiency
defects in code, Common Sources of Inefficiency
defined, Hardware
DES example, Iteration
design view, Performance and Code Tuning
disadvantages of, Hardware
disassemblers, Code Tuning
execution profiler tools, Code Tuning
expressions, Expressions
feature specific, Old Wives' Tales
frequency, testing in order of, Order Tests by Frequency
frequently used code spots, Introduction to Code Tuning
hardware considerations, Hardware
improvements possible, Iteration
indexing data, Minimize Array References
inefficiency, sources of, Common Sources of Inefficiency
initializing at compile time, Use Strength Reduction
inline routines, Eliminate Common Subexpressions
input/output, Common Sources of Inefficiency
integers preferred to floating, Use Integers Rather Than Floating-Point Numbers
interpreted vs. compiled languages, Introduction to Code Tuning, Common Sources of Inefficiency
iteration of, Algorithms and Data Types, Watch for Falling Rocks
jamming loops, Unswitching
key points, Algorithms and Data Types, Additional Resources
language specificity, The More Things Change, the More They Stay the Same
lazy evaluation, Substitute Table Lookups for Complicated Expressions
lines of code, minimizing number of, Old Wives' Tales
logic manipulation guidelines, Code-Tuning Techniques
lookup tables for, Compare Performance of Similar Logic Structures, Use the Correct Type of Constants
loops, Use Lazy Evaluation
low-level language, recoding to, Rewrite Routines Inline
measurement to locate hot spots, Relative Performance Costs of Common Operations, The More Things Change, the More They Stay the Same
memory vs. file operations, Common Sources of Inefficiency
minimizing work inside loops, Unrolling
multiplication, changing to addition, Sentinel Values
nested loop order, Sentinel Values
old wives' tales, Old Wives' Tales
operating system considerations, Program Design
operation speeds, presumptions about, Old Wives' Tales
operations, costs of common, Common Sources of Inefficiency
optimizing as you go, Old Wives' Tales
overview of, Recoding in a Low-Level Language
paging operations, Common Sources of Inefficiency
Pareto Principle, Introduction to Code Tuning
precomputing results, Use the Correct Type of Constants
program requirements view of, Performance and Code Tuning
refactoring, compared to, Code-Tuning Techniques
resource goals, Program Design
resources on, Iteration, The More Things Change, the More They Stay the Same
right shifting, Be Wary of System Routines
routines, Program Design, Eliminate Common Subexpressions
sentinel tests for loops, Minimizing the Work Inside Loops
short-circuit evaluation, Code-Tuning Techniques
speed, importance of, Old Wives' Tales
strength reduction, Sentinel Values, Expressions
subexpression elimination, Precompute Results
summary of approach for, Iteration
system calls, Common Sources of Inefficiency, Initialize at Compile Time
tools, Code Tuning
unrolling loops, Jamming
unswitching loops, Use Lazy Evaluation
variations in environments for, Old Wives' Tales
when to tune, Old Wives' Tales
code-generation wizards, Code-Generation Wizards
coding, What Is Software Construction?, What Is Software Construction?, Visual Basic, Example of Programming into a Language
practices checklist, Example of Programming into a Language
software construction as, What Is Software Construction?
cohesion, Good Abstraction, Design at the Routine Level, Sentinel Values, Expressions
interfaces, class, Good Abstraction
routines, designing with, Design at the Routine Level
strength reduction, Sentinel Values, Expressions
coincidental cohesion, Design at the Routine Level
collaboration, Experimental Prototyping, Collaborative Construction, Overview of Collaborative Development Practices, Overview of Collaborative Development Practices, Overview of Collaborative Development Practices, Overview of Collaborative Development Practices, Collaborative Construction Complements Other Quality-Assurance Techniques, Collaborative Construction Complements Other Quality-Assurance Techniques, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise, Collaboration Applies As Much Before Construction As After, Inspection Summary, Code Reading, Dog-and-Pony Shows, Dog-and-Pony Shows, Inspections, Inspections
code reading, Code Reading (see ; )
collective ownership benefits, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise
comparisons of techniques, table of, Dog-and-Pony Shows
cost advantage, Overview of Collaborative Development Practices
defined, Collaborative Construction, Overview of Collaborative Development Practices
design phase, Experimental Prototyping
development time benefit, Overview of Collaborative Development Practices
dog-and-pony shows, Dog-and-Pony Shows
extending beyond construction, Collaboration Applies As Much Before Construction As After
Extreme Programming method, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise
General Principle of Software Quality, Collaborative Construction Complements Other Quality-Assurance Techniques
key points, Inspections
mentoring aspect of, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise
purpose of, Overview of Collaborative Development Practices
standards, IEEE, Inspections
testing, compared to, Collaborative Construction Complements Other Quality-Assurance Techniques
walk-throughs, Inspection Summary
collections, refactoring, Data-Level Refactorings
collective ownership, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise
(see also )
comments, Pseudocode for Pros, Pseudocode for Pros, Comments on Abbreviations, Reasons to Refactor, Team Variation, Laying Out Data Declarations, Laying Out Comments, Laying Out Comments, Laying Out Files and Programs, Programming Style as Documentation, To Comment or Not to Comment, To Comment or Not to Comment, To Comment or Not to Comment, Keys to Effective Comments, Keys to Effective Comments, Keys to Effective Comments, Marker in the Code, Marker in the Code, Marker in the Code, Description of the Code's Intent, Description of the Code's Intent, Description of the Code's Intent, Commenting Efficiently, Commenting Efficiently, Commenting Efficiently, Commenting Efficiently, Optimum Number of Comments, Optimum Number of Comments, Endline Comments and Their Problems, Endline Comments and Their Problems, Endline Comments and Their Problems, When to Use Endline Comments, When to Use Endline Comments, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Paragraphs of Code, Commenting Data Declarations, Commenting Data Declarations, Commenting Data Declarations, Commenting Data Declarations, Commenting Data Declarations, Commenting Data Declarations, Commenting Data Declarations, Commenting Control Structures, Commenting Control Structures, Commenting Control Structures, Commenting Routines, Commenting Routines, Commenting Routines, Commenting Routines, Commenting Routines, Commenting Routines, Commenting Routines, Commenting Routines, Commenting Routines, Commenting Routines, Commenting Routines, General Guidelines for Class Documentation, General Guidelines for Class Documentation, General Guidelines for Class Documentation, General Guidelines for File Documentation, General Guidelines for File Documentation, General Guidelines for File Documentation, The Book Paradigm for Program Documentation, The Book Paradigm for Program Documentation, Additional Resources, Additional Resources, Additional Resources, Additional Resources, Additional Resources, Additional Resources, Additional Resources, Additional Resources
/* vs. //, Commenting Efficiently (see )
abbreviations in, Commenting Paragraphs of Code
algorithms, Commenting Routines
argument against, To Comment or Not to Comment
authorship, General Guidelines for File Documentation
bad code, on, Reasons to Refactor
blank lines around, Laying Out Comments
Book Paradigm for, The Book Paradigm for Program Documentation
categories of, Keys to Effective Comments
checklists, Laying Out Files and Programs, Additional Resources
classes, General Guidelines for Class Documentation
coded meanings, Commenting Data Declarations
control structures, Commenting Control Structures, Additional Resources
declarations with, Endline Comments and Their Problems, Commenting Data Declarations, Additional Resources
descriptions of code intent, Marker in the Code
distance to code guideline, Commenting Routines
efficient creation of, Description of the Code's Intent
endline comments, Endline Comments and Their Problems
errors, marking workarounds, Commenting Paragraphs of Code
explanatory, Keys to Effective Comments
files, General Guidelines for Class Documentation
flags, bit level, Commenting Data Declarations
global variables, Commenting Data Declarations, Commenting Routines
indentation guidelines, Laying Out Comments
individual lines with, Optimum Number of Comments
input data, Commenting Data Declarations, Commenting Routines
integrating into development, Commenting Efficiently
interfaces, class, General Guidelines for Class Documentation
interfaces, routine, Commenting Routines
Javadoc, Commenting Routines, Additional Resources
key points, Additional Resources
layout guidelines, Laying Out Data Declarations
legal notices, General Guidelines for File Documentation
length of descriptions, Commenting Routines
level of code intent, When to Use Endline Comments
loops, Commenting Control Structures
maintenance of, Pseudocode for Pros, Description of the Code's Intent, Endline Comments and Their Problems
major vs. minor, Commenting Paragraphs of Code
markers, Marker in the Code
non-code essential information, Description of the Code's Intent
numerical data, Commenting Data Declarations
optimum density of, Optimum Number of Comments
output data, Commenting Routines
paragraphs of code with, When to Use Endline Comments, Additional Resources
parameter declarations, Commenting Routines
parts of programs, Commenting Routines
performance considerations, Commenting Efficiently
preceding code rule, Commenting Paragraphs of Code
proportionality of, Commenting Routines
pseudocode, deriving from, Pseudocode for Pros, To Comment or Not to Comment, Commenting Efficiently
purpose of, To Comment or Not to Comment
repeating code with, Keys to Effective Comments
resources on, Additional Resources
routines with, Commenting Control Structures, Additional Resources
self-commenting code, Commenting Paragraphs of Code
Socratic dialog about, Programming Style as Documentation
standards, IEEE, The Book Paradigm for Program Documentation
style differences, managing, Team Variation
style violations, Commenting Paragraphs of Code
summaries of code, Marker in the Code
surprises, Commenting Paragraphs of Code
tricky code, Commenting Paragraphs of Code, Commenting Paragraphs of Code
undocumented features, Commenting Paragraphs of Code
variables, Commenting Data Declarations
version control, General Guidelines for File Documentation
why vs. how, Commenting Paragraphs of Code
workarounds, Commenting Paragraphs of Code
commitment delay strategy, Reuse Decisions
communication skills, importance of, Intellectual Honesty
communicational cohesion, Design at the Routine Level
communications, development team, Communication and Size
comparisons, Numbers in General, Integers
floating-point equality, Integers
mixed data types, Numbers in General
compilers, Check the Code, Check the Code, Persistence, Numbers in General, Numbers in General, Brute-Force Debugging, Brute-Force Debugging, Syntax Errors, Compiler Warning Messages, Compiler Warning Messages, Compiler Warning Messages, Program Design, Old Wives' Tales, Compiler Optimizations, Compiler Optimizations, Daily Build and Smoke Test, Executable-Code Tools, Intellectual Honesty, Intellectual Honesty
binding during compilation, Persistence (see )
broken builds, Daily Build and Smoke Test
data type warnings, Numbers in General
debugging tools, as, Compiler Warning Messages, Intellectual Honesty
errors, finding in routines, Check the Code
line numbers, debugging with, Brute-Force Debugging
messages, treatment of, Brute-Force Debugging, Intellectual Honesty
multiple error messages, Syntax Errors
optimizations by, Old Wives' Tales
performance tuning considerations, Program Design
project-wide standards for, Compiler Warning Messages
speeds from optimization, table of, Compiler Optimizations
tools for, Executable-Code Tools
tricky code optimization, Compiler Optimizations
validators with, Check the Code
warnings, Numbers in General, Compiler Warning Messages
completeness of requirements checklist, Handling Requirements Changes During Construction
complex data types, Structures
complexity, Design Is Emergent, Desirable Characteristics of a Design, Look for Common Design Patterns, Constructors, Reasons to Create a Class, Valid Reasons to Create a Routine, Iteration, Control Structures and Complexity, Control Structures and Complexity, Control Structures and Complexity, Control Structures and Complexity, How to Measure Complexity, Other Kinds of Complexity, Other Kinds of Complexity, Programs, Products, Systems, and System Products, Themes in Software Craftsmanship, Conquer Complexity, Conquer Complexity, Focus Your Attention with the Help of Conventions, Focus Your Attention with the Help of Conventions, Focus Your Attention with the Help of Conventions
abstraction for handling, Conquer Complexity
classes for reducing, Constructors
coding conventions for reducing, Conquer Complexity
control structure contributions to, Iteration
conventions for managing, Focus Your Attention with the Help of Conventions
decision points, counting, How to Measure Complexity
importance of, Control Structures and Complexity
isolation, classes for, Reasons to Create a Class
live time, Other Kinds of Complexity
management, Design Is Emergent, Focus Your Attention with the Help of Conventions
McCabe's metric, Control Structures and Complexity
mental objects held, measure of, Control Structures and Complexity
methods for handling, Themes in Software Craftsmanship
minimization goal, Desirable Characteristics of a Design
patterns, reducing with, Look for Common Design Patterns
problem domain, working at, Focus Your Attention with the Help of Conventions
reliability correlated with, Control Structures and Complexity
routines for reducing, Valid Reasons to Create a Routine
size of projects, effect on, Programs, Products, Systems, and System Products
span, Other Kinds of Complexity
component testing, Developer Testing
components, buying, Software Construction: Building Software, Architectural Feasibility
Composite pattern, Look for Common Design Patterns
compound boundaries, Boundary Analysis
compound statements, Common Problems with Boolean Expressions
computed-value qualifiers of variable names, The Effect of Scope on Variable Names
computer-aided software engineering (CASE) tools, Programming Tools
conditional statements, Strings in C, Using Conditionals, Using Conditionals, Using Conditionals, Using Conditionals, Plain if-then Statements, Plain if-then Statements, Plain if-then Statements, Plain if-then Statements, Plain if-then Statements, Chains of if-then-else Statements, Chains of if-then-else Statements, Chains of if-then-else Statements, Tips for Using case Statements, Key Points, Statement-Level Refactorings, Code-Tuning Techniques, Code-Tuning Techniques, Order Tests by Frequency, Compare Performance of Similar Logic Structures, Compare Performance of Similar Logic Structures
boolean function calls with, Chains of if-then-else Statements (see )
boolean variables recommended, Strings in C
chained if-then-else statements, Plain if-then Statements
checklist, Tips for Using case Statements
common cases first guideline, Chains of if-then-else Statements
comparing performance of, Compare Performance of Similar Logic Structures
covering all cases, Chains of if-then-else Statements
defined, Using Conditionals
eliminating testing redundancy, Code-Tuning Techniques
else clauses, Plain if-then Statements
equality, branching on, Using Conditionals
error processing examples, Plain if-then Statements
frequency, testing in order of, Order Tests by Frequency
key points, Key Points
lookup tables, substituting, Compare Performance of Similar Logic Structures
normal case first guideline, Plain if-then Statements
normal path first guideline, Using Conditionals
null if clauses, Plain if-then Statements
plain if-then statements, Using Conditionals
refactoring, Statement-Level Refactorings
short-circuit evaluation, Code-Tuning Techniques
confessional debugging, Tips for Finding Defects
configuration management, Handling Requirements Changes During Construction, Reuse Decisions, Value of Information Hiding, Techniques for Encouraging Good Coding, Techniques for Encouraging Good Coding, Techniques for Encouraging Good Coding, What Is Configuration Management?, Requirements and Design Changes, Requirements and Design Changes, Requirements and Design Changes, Requirements and Design Changes, Requirements and Design Changes, Requirements and Design Changes, Requirements and Design Changes, Requirements and Design Changes, Requirements and Design Changes, Software Code Changes, Software Code Changes, Software Code Changes, Machine Configurations, Machine Configurations, Backup Plan, Backup Plan
architectural anticipation of change, Reuse Decisions (see ; )
backup plans, Machine Configurations, Backup Plan
boards, change-control, Requirements and Design Changes
bureaucratic considerations, Requirements and Design Changes
checklist, Machine Configurations
code changes, Requirements and Design Changes
cost, estimating, Requirements and Design Changes
defined, Techniques for Encouraging Good Coding
design changes, Requirements and Design Changes
estimating change costs, Requirements and Design Changes
grouping change requests, Requirements and Design Changes
high change volumes, Requirements and Design Changes
identifying areas of change, Value of Information Hiding
machine configurations, reproducing, Software Code Changes
purpose of, Techniques for Encouraging Good Coding
requirements changes, Handling Requirements Changes During Construction, Techniques for Encouraging Good Coding, Requirements and Design Changes
resources on, Backup Plan
SCM, What Is Configuration Management?
tool version control, Software Code Changes
version-control software, Software Code Changes
const keyword, C++, How to Use Routine Parameters, How to Use Routine Parameters, Guidelines for Initializing Variables, Guidelines for a Language-Independent Convention, C++-Pointer Pointers
constants, Guidelines for Initializing Variables, Naming Constants, Guidelines for a Language-Independent Convention, Sample Naming Conventions, If Your Language Doesn't Have Enumerated Types, If Your Language Doesn't Have Enumerated Types, Named Constants, Named Constants, Named Constants, Named Constants, Guidelines for Creating Your Own Types, Common Problems with Global Data, Reasons Not to Refactor
checklist, Guidelines for Creating Your Own Types
consistency rule, Named Constants
declarations using, Named Constants
defined, If Your Language Doesn't Have Enumerated Types
emulation by global variables, Common Problems with Global Data
initializing, Guidelines for Initializing Variables
literals, avoiding with, Named Constants
naming, Naming Constants, Guidelines for a Language-Independent Convention, Sample Naming Conventions
purpose of, If Your Language Doesn't Have Enumerated Types
refactoring, Reasons Not to Refactor
simulating in languages lacking, Named Constants
construction, What Is Software Construction?, Visual Basic, Effect of Project Size on Development Activities, Information About Software Construction
guidelines, Visual Basic
percent of total activity, by size of project, Effect of Project Size on Development Activities
resources on, Information About Software Construction
construction decisions, Visual Basic, Visual Basic, Your Location on the Technology Wave, Your Location on the Technology Wave, Your Location on the Technology Wave, Example of Programming into a Language, Example of Programming into a Language, Example of Programming into a Language, Example of Programming into a Language, Selection of Major Construction Practices, Selection of Major Construction Practices, Selection of Major Construction Practices
checklist of major construction practices, Example of Programming into a Language (see )
coding practices checklist, Example of Programming into a Language
early-wave environments, Your Location on the Technology Wave
key points for, Selection of Major Construction Practices
major construction practices, selecting, Example of Programming into a Language
mature technology environments, Your Location on the Technology Wave
programming conventions, Visual Basic
programming into languages, Your Location on the Technology Wave
quality assurance checklist, Selection of Major Construction Practices
teamwork checklist, Example of Programming into a Language
technology waves, determining your location in, Visual Basic
tools checklist, Selection of Major Construction Practices
construction schedules, estimating, Estimating a Construction Schedule, Estimating a Construction Schedule, Estimating a Construction Schedule, Estimating a Construction Schedule, Estimation Approaches, Estimation Approaches, Estimation Approaches, Estimation Approaches, Influences on Schedule, Influences on Schedule, Influences on Schedule, Influences on Schedule, What to Do If You're Behind, What to Do If You're Behind, Additional Resources on Software Estimation
approaches to, list of, Estimating a Construction Schedule (see )
catching up from behind, Influences on Schedule
controlling vs. estimating, Influences on Schedule
factors influencing, Influences on Schedule
level of detail for, Estimation Approaches
multiple techniques with comparisons, Estimation Approaches
objectives, establishing, Estimating a Construction Schedule
optimism, Influences on Schedule
overview, Estimating a Construction Schedule
planning estimation time, Estimating a Construction Schedule
reduction of scope, What to Do If You're Behind
reestimating, Estimation Approaches
requirements specification, Estimation Approaches
resources for, Additional Resources on Software Estimation
teams, expanding, What to Do If You're Behind
constructors, Constructors, Constructors, Constructors, Constructors, Exceptions, System-Level Refactorings
deep vs. shallow copies, Constructors
exceptions with, Exceptions
guidelines for, Constructors
initializing data members, Constructors
refactoring, System-Level Refactorings
singleton property, enforcing, Constructors
container classes, Named Constants
containment, Find Real-World Objects, Good Encapsulation
continuation lines, Using Spaces for Clarity
continue statements, Exiting the Loop, Exiting Loops Early, Exiting Loops Early
continuous integration, Daily Build and Smoke Test
control structures, Binding Time, Binding Time, Binding Time, Relationship Between Data Types and Control Structures, Unusual Control Structures, Summary of Guidelines for Using gotos, Common Problems with Boolean Expressions, Null Statements, Summary of Techniques for Reducing Deep Nesting, Iteration, Iteration, Control Structures and Complexity, Other Kinds of Complexity, Key Points, Endline Layout, Fine Points of Formatting Control-Structure Blocks, Fine Points of Formatting Control-Structure Blocks, Formatting Continuation Lines, Laying Out Files and Programs, Programming Style as Documentation, Programming Style as Documentation, Commenting Control Structures, Additional Resources
checklists, Other Kinds of Complexity, Laying Out Files and Programs, Programming Style as Documentation
commenting, Commenting Control Structures, Additional Resources
complexity, contributions to, Iteration
compound statements, Common Problems with Boolean Expressions
continuation lines in, Formatting Continuation Lines
data types, relationship to, Binding Time
documentation, Programming Style as Documentation
double indented begin-end pairs, Fine Points of Formatting Control-Structure Blocks
iteration, Relationship Between Data Types and Control Structures, Iteration
key points, Key Points
layout styles, Endline Layout
multiple returns from routines, Unusual Control Structures
null statements, Null Statements
reliability correlated with complexity, Control Structures and Complexity
selective data with, Binding Time
sequential data with, Binding Time
structured programming, Summary of Techniques for Reducing Deep Nesting
unindented begin-end pairs, Fine Points of Formatting Control-Structure Blocks
unusual, overview of, Summary of Guidelines for Using gotos
conventions, coding, Example of Programming into a Language, Focus Your Attention with the Help of Conventions, Focus Your Attention with the Help of Conventions, Focus Your Attention with the Help of Conventions
benefits of, Focus Your Attention with the Help of Conventions (see )
checklist, Example of Programming into a Language
hazards, avoiding with, Focus Your Attention with the Help of Conventions
predictability benefit, Focus Your Attention with the Help of Conventions
converting data types, Use the Correct Type of Constants
cooperation skills, importance of, Intellectual Honesty
correctness, Robustness vs. Correctness, The Software-Quality Landscape
costs, Cost of Finding Defects, Cost of Finding Defects, The General Principle of Software Quality, The General Principle of Software Quality, Overview of Collaborative Development Practices, Overview of Collaborative Development Practices, Which Classes Contain the Most Errors?, Errors by Classification, Errors by Classification, How Many Errors Should You Expect to Find?, Program Design, Methodology and Size, Methodology and Size, Requirements and Design Changes, Intellectual Honesty
change estimates, Requirements and Design Changes
collaboration benefits, Overview of Collaborative Development Practices
debugging, time consumed by, The General Principle of Software Quality
defects contributing to, Errors by Classification
detection of defects, Cost of Finding Defects
error-prone routines, Which Classes Contain the Most Errors?
estimating, Methodology and Size, Intellectual Honesty
fixing of defects, Cost of Finding Defects, Errors by Classification
General Principle of Software Quality, The General Principle of Software Quality, How Many Errors Should You Expect to Find?
pair programming vs. inspections, Overview of Collaborative Development Practices
resources on, Methodology and Size
counted loops, Entering the Loop
coupling, Desirable Characteristics of a Design, Keep Coupling Loose, Keep Coupling Loose, Keep Coupling Loose, Keep Coupling Loose, Keep Coupling Loose, Keep Coupling Loose, Coupling Criteria, Coupling Criteria, Coupling Criteria, Kinds of Coupling, Good Encapsulation, Good Encapsulation
base classes to derived classes, Good Encapsulation
classes, too tightly, Good Encapsulation
design considerations, Keep Coupling Loose
flexibility of, Keep Coupling Loose
goals of, Keep Coupling Loose
loose, Desirable Characteristics of a Design, Keep Coupling Loose
object-parameter type, Coupling Criteria
semantic type, Kinds of Coupling
simple-data-parameter type, Coupling Criteria
simple-object type, Coupling Criteria
size of, Keep Coupling Loose
visibility of, Keep Coupling Loose
coverage, Bag of Testing Tricks, Coverage Monitors
monitoring tools, Coverage Monitors
structured basis testing, Bag of Testing Tricks
CRC (Class, Responsibility, Collaboration) cards, Capturing Your Design Work
creativity, importance of, Creativity and Discipline, Topics Beyond Construction
cross-reference tools, Interface Documentation Tools
curiosity, role in character, Curiosity
Currency data types, Floating-Point Numbers
customization, building metaphor for, Software Construction: Building Software

D

daily build and smoke tests, Summary of Integration Approaches, Summary of Integration Approaches, Summary of Integration Approaches, Summary of Integration Approaches, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Continuous Integration
automation of, Daily Build and Smoke Test
benefits of, Summary of Integration Approaches
broken builds, Daily Build and Smoke Test, Daily Build and Smoke Test
build groups, Daily Build and Smoke Test
checklist, Continuous Integration
defined, Summary of Integration Approaches
diagnosis benefit, Summary of Integration Approaches
holding area for additions, Daily Build and Smoke Test
importance of, Daily Build and Smoke Test
morning releases, Daily Build and Smoke Test
pressure, Daily Build and Smoke Test
pretest requirement, Daily Build and Smoke Test
revisions, Daily Build and Smoke Test
smoke tests, Daily Build and Smoke Test
unsurfaced work, Summary of Integration Approaches
data, Program Organization, Program Organization, Identify Areas Likely to Change, Structured Basis Testing, Structured Basis Testing, Structured Basis Testing, Structured Basis Testing, Structured Basis Testing, Structured Basis Testing, Combinations of Data States, Boundary Analysis, Classes of Bad Data, Classes of Bad Data, Classes of Good Data, Building Scaffolding to Test Individual Classes
architecture prerequisites, Program Organization
bad classes, testing for, Boundary Analysis
change, identifying areas of, Identify Areas Likely to Change
combined states, Structured Basis Testing
defined state, Structured Basis Testing
defined-used paths, testing, Combinations of Data States
design, Program Organization
entered state, Structured Basis Testing
exited state, Structured Basis Testing
good classes, testing, Classes of Bad Data
killed state, Structured Basis Testing
legacy, compatibility with, Classes of Good Data
nominal case errors, Classes of Bad Data
test, generators for, Building Scaffolding to Test Individual Classes
used state, Structured Basis Testing
data dictionaries, Restructurers
data flow testing, Structured Basis Testing
data literacy test, General Issues in Using Variables
data recorder tools, Coverage Monitors
data structures, Structures
data transformations for code tuning, Strength Reduction, Use Integers Rather Than Floating-Point Numbers, Use Integers Rather Than Floating-Point Numbers, Use the Fewest Array Dimensions Possible, Minimize Array References, Independent, Parallel Index Structure
array dimension minimization, Use Integers Rather Than Floating-Point Numbers (see )
array reference minimization, Use the Fewest Array Dimensions Possible
caching data, Independent, Parallel Index Structure
floating point to integers, Use Integers Rather Than Floating-Point Numbers
indexing data, Minimize Array References
purpose of, Strength Reduction
data types, Identify Areas Likely to Change, The Data Literacy Test, Binding Time, Binding Time, Binding Time, Relationship Between Data Types and Control Structures, Informal Naming Conventions, Informal Naming Conventions, Informal Naming Conventions, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Sample Naming Conventions, Sample Naming Conventions, Floating-Point Numbers, Floating-Point Numbers, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types, Reasons to Refactor, Reasons to Refactor, Data-Level Refactorings
"a" prefix convention, Informal Naming Conventions (see ; )
BCD, Floating-Point Numbers
change, identifying areas of, Identify Areas Likely to Change
checklist, Guidelines for Creating Your Own Types
control structures, relationship to, Binding Time
Currency, Floating-Point Numbers
definitions, Sample Naming Conventions
iterative data, Relationship Between Data Types and Control Structures
key points for, Guidelines for Creating Your Own Types
naming, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Sample Naming Conventions
overloaded primitives, Reasons to Refactor
refactoring to classes, Reasons to Refactor, Data-Level Refactorings
resources on, The Data Literacy Test
selective data, Binding Time
sequential data, Binding Time
t_ prefix convention, Informal Naming Conventions
variables of, differentiating from, Informal Naming Conventions
data-level refactoring, Reasons Not to Refactor, System-Level Refactorings
databases, Java, Level 2: Division into Subsystems or Packages, Common Sources of Inefficiency
performance issues, Common Sources of Inefficiency
SQL, Java
subsystem design, Level 2: Division into Subsystems or Packages
days-in-month, determining, Two Issues in Using Table-Driven Methods
deallocation, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, The Argument Against gotos
goto statements for, The Argument Against gotos
pointers, of, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers
Debug.Assert statements, Building Your Own Assertion Mechanism
debugging, Appeal to Data, The General Principle of Software Quality, Developer Testing, Coverage Monitors, Coverage Monitors, Coverage Monitors, Debugging, Debugging, Overview of Debugging Issues, Overview of Debugging Issues, Variations in Debugging Performance, Variations in Debugging Performance, Defects as Opportunities, Defects as Opportunities, An Ineffective Approach, An Ineffective Approach, An Ineffective Approach, An Ineffective Approach, An Ineffective Approach, An Ineffective Approach, Debugging by Superstition, Debugging by Superstition, The Scientific Method of Debugging, Stabilize the Error, Stabilize the Error, Stabilize the Error, Locate the Source of the Error, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Tips for Finding Defects, Brute-Force Debugging, Brute-Force Debugging, Brute-Force Debugging, Brute-Force Debugging, Syntax Errors, Syntax Errors, Syntax Errors, Syntax Errors, Fixing a Defect, Fixing a Defect, How "Psychological Distance" Can Help, How "Psychological Distance" Can Help, How "Psychological Distance" Can Help, How "Psychological Distance" Can Help, Compiler Warning Messages, Compiler Warning Messages, Compiler Warning Messages, Compiler Warning Messages, Compiler Warning Messages, Compiler Warning Messages, Compiler Warning Messages, Execution Profilers, Execution Profilers, Execution Profilers, Debuggers, Debuggers, Debuggers, Debuggers, Key Points, Preprocessors, Preprocessors
binary searches of code, Tips for Finding Defects (see ; )
blindness, sources of, Fixing a Defect
breakpoints, Execution Profilers
breaks, taking, Tips for Finding Defects
brute-force, Tips for Finding Defects
changes, recent, Tips for Finding Defects
checklist, Debuggers
comments, misplaced, Syntax Errors
common defects lists, Tips for Finding Defects
compilers as tools for, Brute-Force Debugging, Compiler Warning Messages
confessional debugging, Tips for Finding Defects
costs of, Appeal to Data, The General Principle of Software Quality
debugger tools, Coverage Monitors, Tips for Finding Defects, How "Psychological Distance" Can Help, Preprocessors
(see also )
defects as opportunities, Variations in Debugging Performance
defined, Debugging
Diff tool, How "Psychological Distance" Can Help
execution profilers for, Compiler Warning Messages
expanding suspicious regions, Tips for Finding Defects
experience of programmers, effects of, Variations in Debugging Performance
finding defects, Debugging by Superstition, Debuggers
fixing defects, Syntax Errors
guessing, An Ineffective Approach
history of, Debugging
hypothesis testing, Stabilize the Error, Tips for Finding Defects
incremental approach, Tips for Finding Defects
ineffective approach to, An Ineffective Approach
key points, Key Points
line numbers from compilers, Brute-Force Debugging
lint tool, Compiler Warning Messages
listing possibilities, Tips for Finding Defects
locating error sources, Stabilize the Error
logic checking tools, Compiler Warning Messages
multiple compiler messages, Syntax Errors
narrowing code searches, Tips for Finding Defects
obvious fixes, An Ineffective Approach
performance variations, Overview of Debugging Issues
project-wide compilers settings, Compiler Warning Messages
psychological considerations, Fixing a Defect
quality of software, role in, Overview of Debugging Issues
quotation marks, misplaced, Syntax Errors
readability improvements, Defects as Opportunities
recommended approach, The Scientific Method of Debugging
reexamining defect-prone code, Tips for Finding Defects
resources for, Debuggers
Satan's helpers, An Ineffective Approach
scaffolding for, Execution Profilers
scientific method of, Debugging by Superstition
self-knowledge from, Defects as Opportunities
source-code comparators, How "Psychological Distance" Can Help
stabilizing errors, Stabilize the Error
superstitious approaches, An Ineffective Approach
symbolic debuggers, Coverage Monitors
syntax checking, Brute-Force Debugging, Compiler Warning Messages, Debuggers
system debuggers, Execution Profilers
test case creation, Locate the Source of the Error
testing, compared to, Developer Testing
time for, setting maximums, Brute-Force Debugging
tools for, Coverage Monitors, Tips for Finding Defects, How "Psychological Distance" Can Help, Preprocessors
(see also )
understanding the problems, An Ineffective Approach
unit tests, Tips for Finding Defects
varying test cases, Tips for Finding Defects
warnings, treating as errors, Compiler Warning Messages
debugging aids, Relationship Between Barricades and Assertions, Relationship Between Barricades and Assertions, Introduce Debugging Aids Early, Introduce Debugging Aids Early, Introduce Debugging Aids Early, Introduce Debugging Aids Early, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids
C++ preprocessors, Plan to Remove Debugging Aids (see ; )
case statements, Introduce Debugging Aids Early
early introduction recommended, Introduce Debugging Aids Early
offensive programming, Introduce Debugging Aids Early
planning removal of, Introduce Debugging Aids Early
pointers, checking, Plan to Remove Debugging Aids
preprocessors, Plan to Remove Debugging Aids
production constraints in development versions, Relationship Between Barricades and Assertions
purpose of, Relationship Between Barricades and Assertions
stubs, Plan to Remove Debugging Aids
version control tools, Plan to Remove Debugging Aids
decision tables, Table-Driven Approach
declarations, The Data Literacy Test, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Using Each Variable for Exactly One Purpose, Knowledge of How to Interpret the Contents, Using Only One Statement Per Line, Using Only One Statement Per Line, Laying Out Data Declarations, Laying Out Data Declarations, Laying Out Data Declarations, Endline Comments and Their Problems, Commenting Data Declarations, Commenting Data Declarations, Additional Resources
commenting, Endline Comments and Their Problems, Commenting Data Declarations, Additional Resources (see )
const recommended, Guidelines for Initializing Variables
declare and define near first use rule, Guidelines for Initializing Variables
define near first use rule, Guidelines for Initializing Variables
final recommended, Guidelines for Initializing Variables
formatting, Using Only One Statement Per Line
implicit declarations, The Data Literacy Test
multiple on one line, Using Only One Statement Per Line
numerical data, commenting, Commenting Data Declarations
order of, Laying Out Data Declarations
placement of, Laying Out Data Declarations
pointers, Knowledge of How to Interpret the Contents, Laying Out Data Declarations
using all declared, Using Each Variable for Exactly One Purpose
Decorator pattern, Look for Common Design Patterns
defects in code, Setting Objectives, Percentage of Defects Detected, Cost of Finding Defects, Cost of Finding Defects, General Procedure for an Inspection, Egos in Inspections, Typical Errors, Typical Errors, Which Classes Contain the Most Errors?, Which Classes Contain the Most Errors?, Errors by Classification, Errors by Classification, Errors by Classification, Errors by Classification, Errors by Classification, Errors by Classification, Errors by Classification, How Many Errors Should You Expect to Find?, Symbolic Debuggers, Variations in Debugging Performance, Defects as Opportunities, Defects as Opportunities, Stabilize the Error, Stabilize the Error, Debuggers, Bad Times to Refactor, Common Sources of Inefficiency, Range of Project Sizes
classes prone to error, Typical Errors (see )
classifications of, Which Classes Contain the Most Errors?
clerical errors (typos), Errors by Classification
Code Complete example, Egos in Inspections
construction, proportion resulting from, Errors by Classification
cost of detection, Cost of Finding Defects
cost of fixing, Cost of Finding Defects
databases of, Symbolic Debuggers
detection by various techniques, table of, Percentage of Defects Detected
distribution of, Typical Errors
ease of fixing defects, Errors by Classification
error checklists, General Procedure for an Inspection
expected rate of, How Many Errors Should You Expect to Find?
finding, checklist, Debuggers
intermittent, Stabilize the Error
misunderstood designs as sources for, Errors by Classification
opportunities presented by, Variations in Debugging Performance
outside of construction domain, Errors by Classification
percentage of, measurement, Setting Objectives
performance issues, Common Sources of Inefficiency
programmers at fault for, Errors by Classification
readability improvements, Defects as Opportunities
refactoring after fixing, Bad Times to Refactor
scope of, Errors by Classification
self-knowledge from, Defects as Opportunities
size of projects, effects on, Range of Project Sizes
sources of, table, Which Classes Contain the Most Errors?
stabilizing, Stabilize the Error
defensive programming, Defensive Programming, Protecting Your Program from Invalid Inputs, Protecting Your Program from Invalid Inputs, Assertions, Assertions, Guidelines for Using Assertions, Robustness vs. Correctness, Exceptions, Exceptions, Relationship Between Barricades and Assertions, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Determining How Much Defensive Programming to Leave in Production Code, Determining How Much Defensive Programming to Leave in Production Code, Determining How Much Defensive Programming to Leave in Production Code, Determining How Much Defensive Programming to Leave in Production Code, Being Defensive About Defensive Programming, Being Defensive About Defensive Programming, Being Defensive About Defensive Programming, Exceptions
assertions, Assertions
assumptions to check, list of, Assertions
barricades, Exceptions
checklist, Being Defensive About Defensive Programming
debugging aids, Relationship Between Barricades and Assertions
defined, Defensive Programming
error handling for, Guidelines for Using Assertions
exceptions, Exceptions, Being Defensive About Defensive Programming
friendly messages guideline, Determining How Much Defensive Programming to Leave in Production Code
graceful crashing guideline, Determining How Much Defensive Programming to Leave in Production Code
guidelines for production code, Plan to Remove Debugging Aids
hard crash errors guideline, Plan to Remove Debugging Aids
important errors guideline, Plan to Remove Debugging Aids
key points for, Exceptions
logging guideline, Determining How Much Defensive Programming to Leave in Production Code
problems caused by, Determining How Much Defensive Programming to Leave in Production Code
quality improvement techniques, other, Protecting Your Program from Invalid Inputs
robustness vs. correctness, Robustness vs. Correctness
security issues, Being Defensive About Defensive Programming
trivial errors guideline, Plan to Remove Debugging Aids
validating input, Protecting Your Program from Invalid Inputs
defined data state, Structured Basis Testing
defining variables, Endline Comments and Their Problems
Delphi, recoding to assembler, Rewrite Routines Inline
DeMorgan's Theorems, applying, Forming Boolean Expressions Positively
dependencies, code-ordering, Two Categories of Secrets, Organizing Straight-Line Code, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Executable-Code Tools
checker tools, Executable-Code Tools (see )
circular, Two Categories of Secrets
clarifying, Statements That Must Be in a Specific Order
concept of, Organizing Straight-Line Code
documentation, Statements That Must Be in a Specific Order
error checking, Statements That Must Be in a Specific Order
hidden, Statements That Must Be in a Specific Order
initialization order, Statements That Must Be in a Specific Order
naming routines, Statements That Must Be in a Specific Order
non-obvious, Statements That Must Be in a Specific Order
organization of code, Statements That Must Be in a Specific Order
parameters, effective, Statements That Must Be in a Specific Order
design, Boss-Readiness Test, Design in Construction, Design in Construction, Design in Construction, Design Is a Wicked Problem, Design Is a Sloppy Process (Even If it Produces a Tidy Result), Design Is a Sloppy Process (Even If it Produces a Tidy Result), Design Is a Sloppy Process (Even If it Produces a Tidy Result), Design Is a Sloppy Process (Even If it Produces a Tidy Result), Design Is a Sloppy Process (Even If it Produces a Tidy Result), Design Is Emergent, Design Is Emergent, Design Is Emergent, Importance of Managing Complexity, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Desirable Characteristics of a Design, Levels of Design, Levels of Design, Levels of Design, Levels of Design, Level 2: Division into Subsystems or Packages, Level 2: Division into Subsystems or Packages, Level 2: Division into Subsystems or Packages, Level 2: Division into Subsystems or Packages, Level 2: Division into Subsystems or Packages, Level 3: Division into Classes, Level 3: Division into Classes, Level 5: Internal Routine Design, Level 5: Internal Routine Design, Find Real-World Objects, Form Consistent Abstractions, Inherit—When Inheritance Simplifies the Design, Inherit—When Inheritance Simplifies the Design, Value of Information Hiding, Keep Coupling Loose, Look for Common Design Patterns, Look for Common Design Patterns, Build Hierarchies, Avoid Failure, Avoid Failure, Guidelines for Using Heuristics, Iterate, Iterate, Iterate, Argument for Top Down, Experimental Prototyping, Experimental Prototyping, Experimental Prototyping, Experimental Prototyping, Experimental Prototyping, How Much Design Is Enough?, How Much Design Is Enough?, How Much Design Is Enough?, How Much Design Is Enough?, Capturing Your Design Work, Capturing Your Design Work, Capturing Your Design Work, Comments on Popular Methodologies, Comments on Popular Methodologies, Comments on Popular Methodologies, Software Design, General, Standards, Standards, Standards, Standards, Standards, Standards, Alternatives to the PPP, Testing During Construction, Performance and Code Tuning, Requirements and Design Changes, Programming Tools, Programming Style as Documentation, Programming Style as Documentation, Watch for Falling Rocks
abstractions, forming consistent, Find Real-World Objects
accidental problems, Design Is Emergent
BDUF, Comments on Popular Methodologies
beauty, Desirable Characteristics of a Design
bottom-up approach to design, Argument for Top Down
business logic subsystem, Level 2: Division into Subsystems or Packages
capturing work, How Much Design Is Enough?
central points of control, Avoid Failure
change, identifying areas of, Value of Information Hiding
changes, management of, Requirements and Design Changes
characteristics of high quality, Desirable Characteristics of a Design
checklists, Standards, Programming Style as Documentation
classes, division into, Level 3: Division into Classes
collaboration, Experimental Prototyping
communications among subsystems, Level 2: Division into Subsystems or Packages
completion of, determining, Experimental Prototyping
complexity management, Design Is Emergent
construction activity, as, Design in Construction
contract, by, Alternatives to the PPP
coupling considerations, Keep Coupling Loose
database access subsystem, Level 2: Division into Subsystems or Packages
defined, Design in Construction
diagrams, drawing, Avoid Failure
discussion, summarizing, How Much Design Is Enough?
divide and conquer technique, Iterate
documentation overkill, How Much Design Is Enough?
documentation, as, Programming Style as Documentation
emergent nature of, Design Is a Sloppy Process (Even If it Produces a Tidy Result)
encapsulation, Form Consistent Abstractions
enough, determining, Capturing Your Design Work
essential problems, Design Is Emergent
extensibility goal, Desirable Characteristics of a Design
formality of, determining, Experimental Prototyping
formalizing class contracts, Build Hierarchies
goals checklist, Standards
good practices table for, Boss-Readiness Test
hierarchies for, Look for Common Design Patterns
high fan-in goal, Desirable Characteristics of a Design
IEEE standards, Standards
information hiding, Inherit—When Inheritance Simplifies the Design, Software Design, General
inheritance, Inherit—When Inheritance Simplifies the Design
iteration practice, Iterate
key points, Standards
leanness goal, Desirable Characteristics of a Design
level of detail needed, Experimental Prototyping
levels of, Levels of Design
loose coupling goal, Desirable Characteristics of a Design
low-to-medium fan-out goal, Desirable Characteristics of a Design
maintenance goals, Desirable Characteristics of a Design
mental limitations of humans, Importance of Managing Complexity
metrics, warning signs from, Watch for Falling Rocks
nondeterministic nature of, Design Is a Sloppy Process (Even If it Produces a Tidy Result), Level 5: Internal Routine Design
object-oriented, resource for, Comments on Popular Methodologies
objects, real world, finding, Level 5: Internal Routine Design
packages level, Levels of Design
performance tuning considerations, Performance and Code Tuning
portability goal, Desirable Characteristics of a Design
practices, Guidelines for Using Heuristics, Standards
prioritizing during, Design Is a Sloppy Process (Even If it Produces a Tidy Result)
prototyping, Experimental Prototyping
resources for, Comments on Popular Methodologies
restrictive nature of, Design Is a Sloppy Process (Even If it Produces a Tidy Result)
reusability goal, Desirable Characteristics of a Design
routines, of, Level 3: Division into Classes
sloppy process nature of, Design Is a Wicked Problem
software system level, Levels of Design
standard techniques goal, Desirable Characteristics of a Design
standards, IEEE, Standards
stratification goal, Desirable Characteristics of a Design
strong cohesion, Look for Common Design Patterns
subsystem level, Levels of Design
system dependencies subsystem, Level 2: Division into Subsystems or Packages
testing for implementation, Testing During Construction
tools for, Programming Tools
top-down approach, Iterate
tradeoffs, Design Is a Sloppy Process (Even If it Produces a Tidy Result)
UML diagrams, Capturing Your Design Work
user interface subsystem, Level 2: Division into Subsystems or Packages
visual documentation of, Capturing Your Design Work
wicked problem nature of, Design in Construction
Wikis, capturing on, How Much Design Is Enough?
destructors, exceptions with, Exceptions
detailed-design documents, External Documentation
developer testing, Improving Your Testing
development processes, General Software-Development Approaches
development standards, IEEE, The Book Paradigm for Program Documentation
diagrams, Avoid Failure, Capturing Your Design Work
heuristic design use of, Avoid Failure
UML, Capturing Your Design Work
Diff tools, How "Psychological Distance" Can Help, Multiple-File String Searching and Replacing
direct access tables, Two Issues in Using Table-Driven Methods, Two Issues in Using Table-Driven Methods, Days-in-Month Example, Insurance Rates Example, Insurance Rates Example, Table-Driven Approach, Table-Driven Approach, Table-Driven Approach, Table-Driven Approach, Table-Driven Approach, Table-Driven Approach, Fudging Lookup Keys
advantages of, Table-Driven Approach (see )
arrays for, Days-in-Month Example
case statement approach, Table-Driven Approach
days-in-month example, Two Issues in Using Table-Driven Methods
defined, Two Issues in Using Table-Driven Methods
design method for, Table-Driven Approach
flexible-message-format example, Insurance Rates Example
fudging keys for, Table-Driven Approach
insurance rates example, Insurance Rates Example
keys for, Table-Driven Approach
object approach, Table-Driven Approach
transforming keys, Fudging Lookup Keys
disassemblers, Code Tuning
discipline, importance of, Creativity and Discipline
discourse rules, Human and Computer Interpretations of a Program
disposing of objects, Introduce Debugging Aids Early
divide and conquer technique, Iterate
division, Numbers in General
Do loops, Loop with Test at the Beginning
(see also )
documentation, Why Is Software Construction Important?, How Much Design Is Enough?, How Much Design Is Enough?, Capturing Your Design Work, Capturing Your Design Work, Benefits of Using ADTs, How to Use Routine Parameters, How to Use Routine Parameters, Pseudocode for Pros, Comments on Abbreviations, Comments on Abbreviations, Statements That Must Be in a Specific Order, Reasons to Refactor, Programs, Products, Systems, and System Products, Team Variation, Self-Documenting Code, External Documentation, External Documentation, External Documentation, External Documentation, External Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Programming Style as Documentation, Commenting Paragraphs of Code, Commenting Routines, The Book Paradigm for Program Documentation, The Book Paradigm for Program Documentation, Additional Resources, Additional Resources, Additional Resources, Additional Resources
abbreviation of names, Comments on Abbreviations
ADTs for, Benefits of Using ADTs
bad code, of, Reasons to Refactor
Book Paradigm for, The Book Paradigm for Program Documentation
capturing work, How Much Design Is Enough?
checklists, Programming Style as Documentation, Additional Resources
classes, Programming Style as Documentation
control structures, Programming Style as Documentation
CRC cards for, Capturing Your Design Work
dependencies, clarifying, Statements That Must Be in a Specific Order
design as, How Much Design Is Enough?, Programming Style as Documentation
detailed-design documents, External Documentation
external, Self-Documenting Code
Javadoc, Commenting Routines, Additional Resources
key points, Additional Resources
names as, Comments on Abbreviations, External Documentation, Programming Style as Documentation
organization of data, Programming Style as Documentation
parameter assumptions, How to Use Routine Parameters
pseudocode, deriving from, Pseudocode for Pros
resources on, Additional Resources
routine parameter assumptions, How to Use Routine Parameters
routines, Programming Style as Documentation
SDFs, External Documentation
self-documenting code, External Documentation
size of projects, effects of, Programs, Products, Systems, and System Products
source code as, Why Is Software Construction Important?
standards, IEEE, The Book Paradigm for Program Documentation
style differences, managing, Team Variation
UDFs, External Documentation
visual, of designs, Capturing Your Design Work
why vs. how, Commenting Paragraphs of Code
dog tag fields, General Tips on Pointers
dog-and-pony shows, Dog-and-Pony Shows
DoNothing() macros, Null Statements
DRY (Don't Repeat Yourself) principle, Philosophy of Software Evolution
duplication, Valid Reasons to Create a Routine, Philosophy of Software Evolution
avoiding with routines, Valid Reasons to Create a Routine
code as refactoring indicator, Philosophy of Software Evolution

E

early-wave environments, Your Location on the Technology Wave
ease of maintenance design goal, Desirable Characteristics of a Design
eclecticism, Iterate, Repeatedly, Again and Again
editing tools, Programming Tools, Integrated Development Environments (IDEs), Integrated Development Environments (IDEs), Multiple-File String Searching and Replacing, Multiple-File String Searching and Replacing, Multiple-File String Searching and Replacing, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools
beautifiers, Multiple-File String Searching and Replacing (see )
class-hierarchy generators, Interface Documentation Tools
cross-reference tools, Interface Documentation Tools
Diff tools, Multiple-File String Searching and Replacing
grep, Integrated Development Environments (IDEs)
IDEs, Programming Tools
interface documentation, Interface Documentation Tools
merge tools, Multiple-File String Searching and Replacing
multiple-file string searches, Integrated Development Environments (IDEs)
templates, Interface Documentation Tools
efficiency, Characteristics of Software Quality
eighty/twenty (80/20) rule, Introduction to Code Tuning
else clauses, Plain if-then Statements, Plain if-then Statements, Plain if-then Statements, Chains of if-then-else Statements, Chains of if-then-else Statements, Chains of if-then-else Statements, Chains of if-then-else Statements, gotos and Sharing Code in an else Clause
boolean function calls with, Chains of if-then-else Statements
case statements instead of, Chains of if-then-else Statements
chains, in, Plain if-then Statements
common cases first guideline, Chains of if-then-else Statements
correctness testing, Plain if-then Statements
default for covering all cases, Chains of if-then-else Statements
gotos with, gotos and Sharing Code in an else Clause
null, Plain if-then Statements
embedded life-critical systems, Boss-Readiness Test
emergent nature of design process, Design Is a Sloppy Process (Even If it Produces a Tidy Result)
emulated pure blocks layout style, Pure Blocks
encapsulation, Form Consistent Abstractions, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Beyond Classes: Packages, Reasons to Refactor, Reasons to Refactor, Routine-Level Refactorings
assumptions about users, Good Encapsulation
checklist, Beyond Classes: Packages
classes, role for, Good Encapsulation
coupling classes too tightly, Good Encapsulation
downcast objects, Routine-Level Refactorings
friend class concern, Good Encapsulation
heuristic design with, Form Consistent Abstractions
minimizing accessibility, Good Encapsulation
private details in class interfaces, Good Encapsulation
public data members, Reasons to Refactor
public members of classes, Good Encapsulation
public routines in interfaces concern, Good Encapsulation
semantic violations of, Good Encapsulation
weak, Reasons to Refactor
endless loops, Controlling Loops, Entering the Loop
endline comments, Endline Comments and Their Problems
endline layout, Using begin-end Pairs (Braces) to Designate Block Boundaries, Other Considerations, Laying Out Routines
enumerated types, Naming Boolean Variables, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Boolean Variables, Boolean Variables, Boolean Variables, Boolean Variables, Boolean Variables, Boolean Variables, Boolean Variables, Enumerated Types, Enumerated Types, Enumerated Types, Enumerated Types, Enumerated Types, Enumerated Types, Enumerated Types, Enumerated Types, Enumerated Types, Enumerated Types, If Your Language Doesn't Have Enumerated Types, If Your Language Doesn't Have Enumerated Types, Guidelines for Creating Your Own Types, Common Problems with Global Data, Commenting Data Declarations
benefits of, Boolean Variables (see )
booleans, alternative to, Enumerated Types
C++, Boolean Variables, Enumerated Types
changes benefit, Enumerated Types
checklist, Guidelines for Creating Your Own Types
comments substituting for, Commenting Data Declarations
creating for Java, If Your Language Doesn't Have Enumerated Types
defined, Boolean Variables
emulation by global variables, Common Problems with Global Data
explicit value pitfalls, Enumerated Types
first entry invalid trick, Enumerated Types
iterating through, Enumerated Types
Java, creating for, If Your Language Doesn't Have Enumerated Types
languages available in, Boolean Variables
loop limits with, Enumerated Types
naming, Naming Boolean Variables, Guidelines for a Language-Independent Convention, Sample Naming Conventions
parameters using, Boolean Variables
readability from, Boolean Variables
reliability benefit, Enumerated Types
standard for, Enumerated Types
validation with, Enumerated Types
Visual Basic, Boolean Variables
equality, floating-point, Integers
equivalence partitioning, Combinations of Data States
error codes, Error-Handling Techniques
error detection, doing early, Appeal to Data
error guessing, Error Guessing
error handling, Input/Output, Input/Output, Input/Output, Error Processing, Architectural Feasibility, Building Your Own Assertion Mechanism, Guidelines for Using Assertions, Guidelines for Using Assertions, Error-Handling Techniques, Error-Handling Techniques, Error-Handling Techniques, Error-Handling Techniques, Error-Handling Techniques, Error-Handling Techniques, Error-Handling Techniques, Error-Handling Techniques, Error-Handling Techniques, Error-Handling Techniques, Robustness vs. Correctness, Robustness vs. Correctness, Exceptions, Exceptions, Determining How Much Defensive Programming to Leave in Production Code, Design the Routine, System-Level Refactorings
architecture prerequisites, Input/Output (see )
assertions, compared to, Building Your Own Assertion Mechanism
barricades, Exceptions
buffer overruns compromising, Error-Handling Techniques
closest legal value, Error-Handling Techniques
defensive programming, techniques for, Guidelines for Using Assertions
error codes, returning, Error-Handling Techniques
error-processing routines, calling, Error-Handling Techniques
high-level design implication, Robustness vs. Correctness
local handling, Error-Handling Techniques
logging warning messages, Error-Handling Techniques
messages, Input/Output, Error-Handling Techniques, Determining How Much Defensive Programming to Leave in Production Code
next valid data, returning, Error-Handling Techniques
previous answers, reusing, Error-Handling Techniques
propagation design, Input/Output
refactoring, System-Level Refactorings
returning neutral values, Guidelines for Using Assertions
robustness, Architectural Feasibility, Robustness vs. Correctness
routines, designing along with, Design the Routine
shutting down, Error-Handling Techniques
validation design, Error Processing
error messages, Input/Output, Error-Handling Techniques, Error-Handling Techniques, Determining How Much Defensive Programming to Leave in Production Code
codes, returning, Error-Handling Techniques
design, Input/Output
displaying, Error-Handling Techniques
friendly messages guideline, Determining How Much Defensive Programming to Leave in Production Code
errors, Exceptions, General Tips on Pointers, The Phony goto Debate, Typical Errors, Which Classes Contain the Most Errors?, Which Classes Contain the Most Errors?
classifications of, Which Classes Contain the Most Errors?
dog tag fields, General Tips on Pointers
goto statements for processing, The Phony goto Debate
sources of, table, Which Classes Contain the Most Errors?
essential problems, Design Is Emergent
estimating schedules, Requirements and Design Changes, Estimating a Construction Schedule, Estimating a Construction Schedule, Estimating a Construction Schedule, Estimating a Construction Schedule, Estimation Approaches, Estimation Approaches, Estimation Approaches, Estimation Approaches, Influences on Schedule, Influences on Schedule, Influences on Schedule, What to Do If You're Behind, What to Do If You're Behind, Additional Resources on Software Estimation, Intellectual Honesty
approaches to, list of, Estimating a Construction Schedule
change costs, Requirements and Design Changes
control, compared to, Influences on Schedule
factors influencing, Influences on Schedule
inaccuracy, character-based, Intellectual Honesty
level of detail for, Estimation Approaches
multiple techniques with comparisons, Estimation Approaches
objectives, establishing, Estimating a Construction Schedule
optimism, Influences on Schedule
overview, Estimating a Construction Schedule
planning for estimation time, Estimating a Construction Schedule
redoing periodically, Estimation Approaches
reduction of scope, What to Do If You're Behind
requirements specification, Estimation Approaches
resources for, Additional Resources on Software Estimation
teams, expanding, What to Do If You're Behind
event handlers, Design at the Routine Level
evolution, Refactoring
Evolutionary Delivery, Software Farming: Growing a System
exceptions, Input/Output, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Exceptions, Being Defensive About Defensive Programming, Being Defensive About Defensive Programming, System-Level Refactorings (see )
abstraction issues, Exceptions
alternatives to, Exceptions
base classes for, project specific, Exceptions
C++, Exceptions
centralized reporters, Exceptions
constructors with, Exceptions
defensive programming checklist, Being Defensive About Defensive Programming
destructors with, Exceptions
empty catch blocks rule, Exceptions
encapsulation, breaking, Exceptions
full information rule, Exceptions
Java, Exceptions
languages, table comparing, Exceptions
level of abstraction rule, Exceptions
library code generation of, Exceptions
local handling rule, Exceptions
non-exceptional conditions, Exceptions
purpose of, Exceptions, Exceptions
readability of code using, Exceptions
refactoring, System-Level Refactorings
resources for, Being Defensive About Defensive Programming
standardizing use of, Exceptions
Visual Basic, Exceptions, Exceptions
executable-code tools, Executable-Code Tools, Executable-Code Tools, Build Tools, Code-Generation Wizards, Code-Generation Wizards, Code-Generation Wizards, Code-Generation Wizards
build tools, Executable-Code Tools
code libraries, Build Tools
code-generation wizards, Code-Generation Wizards
installation tools, Code-Generation Wizards
linkers, Executable-Code Tools
preprocessors, Code-Generation Wizards
setup tools, Code-Generation Wizards
execution profilers, Compiler Warning Messages, Code Tuning
Exit Function, Unusual Control Structures
(see also )
Exit statements, Normal Loop-With-Exit Loops
Exit Sub, Multiple Returns from a Routine
(see also )
exiting loops, Loop with Test at the Beginning, Exiting the Loop
experience, personal, Persistence
experimental prototyping, Experimental Prototyping
experimentation as learning, Curiosity, Eclecticism
exponential expressions, Use Strength Reduction
expressions, Expressions, Use Strength Reduction, Initialize at Compile Time, Be Wary of System Routines, Use the Correct Type of Constants, Use the Correct Type of Constants, Precompute Results, Other Considerations
constants, data types for, Use the Correct Type of Constants
initializing at compile time, Use Strength Reduction
layout guidelines, Other Considerations
precomputing results, Use the Correct Type of Constants
right shifting, Be Wary of System Routines
strength reduction, Expressions
subexpression elimination, Precompute Results
system calls, performance of, Initialize at Compile Time
extensibility design goal, Desirable Characteristics of a Design
external audits, Techniques for Improving Software Quality
external documentation, Self-Documenting Code
Extreme Programming, General Software-Development Approaches, Percentage of Defects Detected, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise, Integration, Information About Software Construction
collaboration component of, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise
defect detection, Percentage of Defects Detected
defined, General Software-Development Approaches
resources on, Integration, Information About Software Construction

F

Facade pattern, Look for Common Design Patterns
factorials, Tips for Using Recursion
factoring, Reasons to Create a Class
(see also )
factory methods, Look for Common Design Patterns, Taming Dangerously Deep Nesting, System-Level Refactorings
Factory Method pattern, Look for Common Design Patterns
nested ifs refactoring example, Taming Dangerously Deep Nesting
refactoring to, System-Level Refactorings
fan-in, Desirable Characteristics of a Design
fan-out, Desirable Characteristics of a Design
farming metaphor, Software Penmanship: Writing Code
fault tolerance, Error Processing
feature-oriented integration, Feature-Oriented Integration
Fibonacci numbers, Tips for Using Recursion
files, More Examples of ADTs, The Phony goto Debate, Laying Out Class Implementations, Laying Out Files and Programs, Laying Out Files and Programs, Laying Out Files and Programs, General Guidelines for Class Documentation, General Guidelines for File Documentation, General Guidelines for File Documentation
ADTs, treating as, More Examples of ADTs
authorship records for, General Guidelines for File Documentation
C++ source file order, Laying Out Files and Programs
deleting multiple example, The Phony goto Debate
documenting, General Guidelines for Class Documentation
layout within, Laying Out Class Implementations
naming, Laying Out Files and Programs, General Guidelines for File Documentation
routines in, Laying Out Files and Programs
final keyword, Java, Guidelines for Initializing Variables
finally statements, Error Processing and gotos
fixing defects, Syntax Errors, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Fixing a Defect, Debuggers
checking fixes, Fixing a Defect (see )
checklist, Debuggers
diagnosis confirmation, Fixing a Defect
hurrying, impact of, Fixing a Defect
initialization defects, Fixing a Defect
maintenance issues, Fixing a Defect
one change at a time rule, Fixing a Defect
reasoning for changes, Fixing a Defect
saving unfixed code, Fixing a Defect
similar defects, looking for, Fixing a Defect
special cases, Fixing a Defect
symptoms, fixing instead of problems, Fixing a Defect
understand first guideline, Syntax Errors
unit tests for, Fixing a Defect
flags, Identify Areas Likely to Change, Kinds of Coupling, Naming Status Variables, Naming Status Variables, Error Processing and gotos, Commenting Data Declarations
change, identifying areas of, Identify Areas Likely to Change
comments for bit-level meanings, Commenting Data Declarations
enumerated types for, Naming Status Variables
gotos, rewriting with, Error Processing and gotos
names for, Naming Status Variables
semantic coupling with, Kinds of Coupling
flexibility, Keep Coupling Loose, Characteristics of Software Quality
coupling criteria for, Keep Coupling Loose
defined, Characteristics of Software Quality
floating-point data types, Integers, Integers, Integers, Floating-Point Numbers, Floating-Point Numbers, Floating-Point Numbers, Guidelines for Creating Your Own Types, Relative Performance Costs of Common Operations
accuracy limitations, Integers (see )
BCD, Floating-Point Numbers
checklist, Guidelines for Creating Your Own Types
costs of operations, Relative Performance Costs of Common Operations
equality comparisons, Integers
magnitudes, greatly different, operations with, Integers
rounding errors, Floating-Point Numbers
Visual Basic types, Floating-Point Numbers
for loops, When to Use a for Loop, Entering the Loop, Exiting the Loop, Layout Extremes, Fine Points of Formatting Control-Structure Blocks
advantages of, Entering the Loop
formatting, Layout Extremes, Fine Points of Formatting Control-Structure Blocks
indexes, Exiting the Loop
purpose of, When to Use a for Loop
foreach loops, Controlling Loops, When to Use a for Loop
formal inspections, Formal Inspections, Formal Inspections, Formal Inspections, What Results Can You Expect from Inspections?, What Results Can You Expect from Inspections?, What Results Can You Expect from Inspections?, What Results Can You Expect from Inspections?, What Results Can You Expect from Inspections?, What Results Can You Expect from Inspections?, Roles During an Inspection, Roles During an Inspection, Roles During an Inspection, Roles During an Inspection, Roles During an Inspection, Roles During an Inspection, General Procedure for an Inspection, General Procedure for an Inspection, General Procedure for an Inspection, General Procedure for an Inspection, General Procedure for an Inspection, General Procedure for an Inspection, General Procedure for an Inspection, General Procedure for an Inspection, General Procedure for an Inspection, Egos in Inspections, Egos in Inspections, Egos in Inspections, Inspections and Code Complete, Inspections and Code Complete, Inspections and Code Complete, Dog-and-Pony Shows, Comparison of Collaborative Construction Techniques, Inspections
author role, What Results Can You Expect from Inspections? (see ; ; )
benefit summary, Inspections and Code Complete
blame game, Egos in Inspections
checklist, Inspections and Code Complete
CMM, Inspections and Code Complete
Code Complete example, Egos in Inspections
compared to other collaboration, Dog-and-Pony Shows
defined, Formal Inspections
egos in, Egos in Inspections
error checklists, General Procedure for an Inspection
expected results from, Formal Inspections
fine-tuning, General Procedure for an Inspection
follow-up stage, General Procedure for an Inspection
inspection meetings, General Procedure for an Inspection
key points, Inspections
management role, What Results Can You Expect from Inspections?
moderator role, What Results Can You Expect from Inspections?
overview stage, Roles During an Inspection
performance appraisals from, Roles During an Inspection
planning stage, Roles During an Inspection
preparation stage, Roles During an Inspection
procedure for, Roles During an Inspection
rate of code review, General Procedure for an Inspection
reports, General Procedure for an Inspection
resources for, Comparison of Collaborative Construction Techniques
reviewer role, What Results Can You Expect from Inspections?
reviews, compared to, Formal Inspections
rework stage, General Procedure for an Inspection
roles in, What Results Can You Expect from Inspections?
scenarios approach, General Procedure for an Inspection
scribe role, What Results Can You Expect from Inspections?
stages of, Roles During an Inspection
three-hour solutions meeting, General Procedure for an Inspection
formal technical reviews, Techniques for Improving Software Quality
formatting code, Using Spaces for Clarity
Fortran, C
functional cohesion, Design at the Routine Level
functional specification, Problem-Definition Prerequisite
functions, Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Member Functions and Data, Valid Reasons to Create a Routine, Good Routine Names, Special Considerations in the Use of Functions, Special Considerations in the Use of Functions, Special Considerations in the Use of Functions, Special Considerations in the Use of Functions, When to Use a Function and When to Use a Procedure, Key Points
calculations converted to example, Valid Reasons to Create a Routine (see )
defined, Special Considerations in the Use of Functions
disallowing, Member Functions and Data
key point for, Key Points
naming conventions for, Good Routine Names, Special Considerations in the Use of Functions
private, overriding, Inheritance ("is a" Relationships)
return values, setting, When to Use a Function and When to Use a Procedure
status as return value, Special Considerations in the Use of Functions
when to use, Special Considerations in the Use of Functions
Fundamental Theorem of Formatting, Layout Extremes

G

General Principle of Software Quality, The General Principle of Software Quality, Collaborative Construction Complements Other Quality-Assurance Techniques, How Many Errors Should You Expect to Find?, Variations in Debugging Performance
collaboration effects, Collaborative Construction Complements Other Quality-Assurance Techniques
costs, How Many Errors Should You Expect to Find?
debugging, Variations in Debugging Performance
defined, The General Principle of Software Quality
global variables, Two Categories of Secrets, Kinds of Coupling, Reasons to Create a Class, Comments on Minimizing Scope, The Effect of Scope on Variable Names, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Sample Naming Conventions, Standardized Prefixes, C-Pointer Pointers, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Common Problems with Global Data, Use Global Data Only as a Last Resort, Use Global Data Only as a Last Resort, Use Global Data Only as a Last Resort, Advantages of Access Routines, How to Use Access Routines, How to Use Access Routines, How to Use Access Routines, How to Reduce the Risks of Using Global Data, How to Reduce the Risks of Using Global Data, How to Reduce the Risks of Using Global Data, How to Reduce the Risks of Using Global Data, Additional Resources, Reasons to Refactor, Commenting Data Declarations, Commenting Routines
aliasing problems with, Common Problems with Global Data (see )
alternatives to, Use Global Data Only as a Last Resort
annotating, How to Reduce the Risks of Using Global Data
changes to, inadvertent, Common Problems with Global Data
checklist for, How to Reduce the Risks of Using Global Data
class variable alternatives, Use Global Data Only as a Last Resort
code reuse problems, Common Problems with Global Data
commenting, Commenting Data Declarations, Commenting Routines
enumerated types emulation by, Common Problems with Global Data
g_ prefix guideline, Advantages of Access Routines
hiding implementation in classes, Reasons to Create a Class
information hiding problems with, Two Categories of Secrets
initialization problems, Common Problems with Global Data
intermediate results, avoiding, How to Reduce the Risks of Using Global Data
key points, Additional Resources
local first guideline, Use Global Data Only as a Last Resort
locking, How to Use Access Routines
modularity damaged by, Common Problems with Global Data
named constants emulation by, Common Problems with Global Data
naming, The Effect of Scope on Variable Names, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Sample Naming Conventions, Standardized Prefixes, How to Use Access Routines
objects for, monster, How to Reduce the Risks of Using Global Data
overview of, C-Pointer Pointers
persistence of, Comments on Minimizing Scope
preservation of values with, Common Problems with Global Data
re-entrant code problems, Common Problems with Global Data
refactoring, Reasons to Refactor
risk reduction strategies, How to Use Access Routines
routines using as parameters, Common Problems with Global Data
semantic coupling with, Kinds of Coupling
streamlining data use with, Common Problems with Global Data
tramp data, eliminating with, Common Problems with Global Data
god classes, Reasons to Create a Class
gonzo programming, Experience
good data, testing, Classes of Bad Data
goto statements, Tips for Using Recursion, Tips for Using Recursion, Tips for Using Recursion, Tips for Using Recursion, The Argument Against gotos, The Argument Against gotos, The Argument Against gotos, The Argument Against gotos, The Argument Against gotos, The Phony goto Debate, The Phony goto Debate, The Phony goto Debate, Error Processing and gotos, Error Processing and gotos, Error Processing and gotos, Error Processing and gotos, gotos and Sharing Code in an else Clause, gotos and Sharing Code in an else Clause, gotos and Sharing Code in an else Clause, Summary of Guidelines for Using gotos, Summary of Guidelines for Using gotos, Returns, gotos, gotos, Other Considerations
Ada, inclusion in, The Argument Against gotos (see )
advantages of, The Argument Against gotos
alternatives compared with, Error Processing and gotos
checklist, gotos
deallocation with, The Argument Against gotos
disadvantages of, Tips for Using Recursion
duplicate code, eliminating with, The Argument Against gotos
else clauses with, gotos and Sharing Code in an else Clause
error processing with, The Phony goto Debate
Fortran's use of, The Argument Against gotos
forward direction guideline, Summary of Guidelines for Using gotos
guidelines, gotos and Sharing Code in an else Clause
indentation problem with, Tips for Using Recursion
key points, gotos
layout guidelines, Other Considerations
legitimate uses of, gotos and Sharing Code in an else Clause
optimization problem with, Tips for Using Recursion
phony debating about, The Phony goto Debate
readability issue, Tips for Using Recursion
resources for, Returns
rewritten with nested ifs, Error Processing and gotos
rewritten with status variables, Error Processing and gotos
rewritten with try-finally, Error Processing and gotos
trivial rewrite example, The Phony goto Debate
unused labels, Summary of Guidelines for Using gotos
graphical design tools, Programming Tools
grep, Integrated Development Environments (IDEs)
growing a system metaphor, Software Penmanship: Writing Code
GUIs (graphical user interfaces), Business Rules, Level 2: Division into Subsystems or Packages, Class Interface Refactorings
architecture prerequisites, Business Rules
refactoring data from, Class Interface Refactorings
subsystem design, Level 2: Division into Subsystems or Packages

H

habits of programmers, Habits
hacking approach to design, Alternatives to the PPP
hardware, Identify Areas Likely to Change, Hardware
dependencies, changing, Identify Areas Likely to Change
performance enhancement with, Hardware
has a relationships, Good Encapsulation
heuristic design, Design Is a Sloppy Process (Even If it Produces a Tidy Result), Level 5: Internal Routine Design, Level 5: Internal Routine Design, Find Real-World Objects, Form Consistent Abstractions, Inherit—When Inheritance Simplifies the Design, Inherit—When Inheritance Simplifies the Design, Value of Information Hiding, Keep Coupling Loose, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Build Hierarchies, Build Hierarchies, Build Hierarchies, Build Hierarchies, Build Hierarchies, Avoid Failure, Avoid Failure, Avoid Failure, Avoid Failure, Avoid Failure, Keep Your Design Modular, Guidelines for Using Heuristics, Guidelines for Using Heuristics, Guidelines for Using Heuristics, Iterate, Iterate, Iterate, Argument for Top Down, No Argument, Really, Experimental Prototyping, Experimental Prototyping, Experimental Prototyping, Experimental Prototyping, Experimental Prototyping, How Much Design Is Enough?, Comments on Popular Methodologies, Software Design, General, Software Design, General, Design in General, Standards, Standards, Standards, Standards
abstractions, forming consistent, Find Real-World Objects (see ; ; )
alternatives from patterns, Look for Common Design Patterns
avoiding failure, Build Hierarchies
binding time considerations, Avoid Failure
bottom-up approach to design, Argument for Top Down
brute force, Avoid Failure
capturing work, How Much Design Is Enough?
central points of control, Avoid Failure
change, identifying areas of, Value of Information Hiding
checklist for, Standards
collaboration, Experimental Prototyping
communications benefit from patterns, Look for Common Design Patterns
completion of, determining, Experimental Prototyping
coupling considerations, Keep Coupling Loose
diagrams, drawing, Avoid Failure
divide and conquer technique, Iterate
encapsulation, Form Consistent Abstractions
error reduction with patterns, Look for Common Design Patterns
formality of, determining, Experimental Prototyping
formalizing class contracts, Build Hierarchies
goals checklist, Standards
guidelines for using, Guidelines for Using Heuristics
hierarchies for, Look for Common Design Patterns
information hiding, Inherit—When Inheritance Simplifies the Design, Software Design, General
inheritance, Inherit—When Inheritance Simplifies the Design
interfaces, formalizing as contracts, Build Hierarchies
iteration practice, Iterate
key points, Standards
level of detail needed, Experimental Prototyping
modularity, Avoid Failure
multiple approach suggestion, Guidelines for Using Heuristics
nature of design process, Design Is a Sloppy Process (Even If it Produces a Tidy Result)
nondeterministic basis for, Level 5: Internal Routine Design
object-oriented, resource for, Comments on Popular Methodologies
objects, real world, finding, Level 5: Internal Routine Design
patterns, Look for Common Design Patterns, Software Design, General
practices, Guidelines for Using Heuristics, Standards
prototyping, Experimental Prototyping
resources for, Design in General
responsibilities, assigning to objects, Build Hierarchies
strong cohesion, Look for Common Design Patterns
summary list of rules, Keep Your Design Modular
testing, anticipating, Build Hierarchies
top-down approach, Iterate, No Argument, Really
heuristics, How to Use Software Metaphors, Error Guessing
algorithms compared to, How to Use Software Metaphors
error guessing, Error Guessing
hiding, Advantages of Access Routines
hierarchies, benefits of, Look for Common Design Patterns
high fan-in design goal, Desirable Characteristics of a Design
human aspects of software development, Curiosity
humility, role in character, Intelligence and Humility, Intellectual Honesty, Habits
Hungarian naming convention, Standardized Prefixes
hybrid coupling of variables, Using Each Variable for Exactly One Purpose

I

I/O (input/output), Input/Output, Identify Areas Likely to Change, Common Sources of Inefficiency
architecture prerequisites, Input/Output
change, identifying areas of, Identify Areas Likely to Change
performance considerations, Common Sources of Inefficiency
IDEs (Integrated Development Environments), Programming Tools
IEEE (Institute for Electric and Electrical Engineers), The Book Paradigm for Program Documentation
if statements, Using Conditionals, Using Conditionals, Using Conditionals, Using Conditionals, Plain if-then Statements, Plain if-then Statements, Plain if-then Statements, Plain if-then Statements, Plain if-then Statements, Plain if-then Statements, Chains of if-then-else Statements, Chains of if-then-else Statements, Chains of if-then-else Statements, Chains of if-then-else Statements, Tips for Using case Statements, Key Points, Multiple Returns from a Routine, Error Processing and gotos, gotos and Sharing Code in an else Clause, gotos and Sharing Code in an else Clause, Two Issues in Using Table-Driven Methods, Making Complicated Expressions Simple, Null Statements, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Statement-Level Refactorings, Order Tests by Frequency, Compare Performance of Similar Logic Structures, Compare Performance of Similar Logic Structures, Other Considerations, Formatting Continuation Lines
boolean function calls with, Chains of if-then-else Statements (see ; )
break blocks, simplification with, Taming Dangerously Deep Nesting
case statements, compared to, Chains of if-then-else Statements, Compare Performance of Similar Logic Structures
case statements, converting to, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting
chains of, Plain if-then Statements
checklist, Tips for Using case Statements
common cases first guideline, Chains of if-then-else Statements
continuation lines in, Formatting Continuation Lines
covering all cases, Chains of if-then-else Statements
else clauses, Plain if-then Statements, gotos and Sharing Code in an else Clause
equality, branching on, Using Conditionals
error processing examples, Plain if-then Statements
factoring to routines, Taming Dangerously Deep Nesting
flipped, Plain if-then Statements
frequency, testing in order of, Order Tests by Frequency
gotos rewritten with, Error Processing and gotos, gotos and Sharing Code in an else Clause
if-then-else statements, converting to, Taming Dangerously Deep Nesting
key points, Key Points
lookup tables, substituting, Compare Performance of Similar Logic Structures
multiple returns nested in, Multiple Returns from a Routine
negatives in, making positive, Making Complicated Expressions Simple
normal case first guideline, Plain if-then Statements
normal path first guideline, Using Conditionals
null if clauses, Plain if-then Statements
plain if-then statements, Using Conditionals
refactoring, Statement-Level Refactorings
simplification, Null Statements
single-statement layout, Other Considerations
tables, replacing with, Two Issues in Using Table-Driven Methods
types of, Using Conditionals
implicit declarations, The Data Literacy Test
implicit instancing, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
in keyword, creating, How to Use Routine Parameters
incomplete preparation, causes of, Do Prerequisites Apply to Modern Software Projects?
incremental development metaphor, Software Farming: Growing a System
incremental integration, Phased Integration, Phased Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Top-Down Integration, Top-Down Integration, Top-Down Integration, Top-Down Integration, Bottom-Up Integration, Bottom-Up Integration, Bottom-Up Integration, Bottom-Up Integration, Bottom-Up Integration, Bottom-Up Integration, Sandwich Integration, Feature-Oriented Integration, Feature-Oriented Integration, Summary of Integration Approaches, Integration
benefits of, Benefits of Incremental Integration (see )
bottom-up strategy, Bottom-Up Integration
classes, Benefits of Incremental Integration, Bottom-Up Integration
customer relations benefit, Benefits of Incremental Integration
defined, Phased Integration
disadvantages of top-down strategy, Top-Down Integration
errors, locating, Benefits of Incremental Integration
feature-oriented integration, Feature-Oriented Integration
interface specification, Top-Down Integration, Bottom-Up Integration
progress monitoring benefit, Benefits of Incremental Integration
resources on, Integration
results, early, Benefits of Incremental Integration
risk-oriented integration, Sandwich Integration
sandwich strategy, Bottom-Up Integration
scheduling benefits, Benefits of Incremental Integration
slices approach, Bottom-Up Integration
steps in, Phased Integration
strategies for, overview, Benefits of Incremental Integration
stubs, Benefits of Incremental Integration, Top-Down Integration
summary of approaches, Summary of Integration Approaches
T-shaped integration, Feature-Oriented Integration
test drivers, Bottom-Up Integration
top-down strategy for, Benefits of Incremental Integration
vertical-slice approach, Top-Down Integration
indentation, White Space, Laying Out Comments
indexed access tables, Indexed Access Tables, Stair-Step Access Tables
indexes, loop, Naming Loop Indexes, Enumerated Types, Exiting the Loop, Exiting the Loop, Using Loop Variables, Correspondence Between Loops and Arrays
alterations, Exiting the Loop
checklist, Correspondence Between Loops and Arrays
enumerated types for, Enumerated Types
final values, Exiting the Loop
scope of, Using Loop Variables
variable names, Naming Loop Indexes
indexes, supplementing data types with, Minimize Array References
infinite loops, Controlling Loops, Entering the Loop
informal reviews, Techniques for Improving Software Quality, Inspection Summary
information hiding, Inherit—When Inheritance Simplifies the Design, Inherit—When Inheritance Simplifies the Design, Inherit—When Inheritance Simplifies the Design, Secrets and the Right to Privacy, Secrets and the Right to Privacy, Secrets and the Right to Privacy, An Example of Information Hiding, Two Categories of Secrets, Two Categories of Secrets, Two Categories of Secrets, Two Categories of Secrets, Barriers to Information Hiding, Software Design, General, Example of the Need for an ADT, Reasons to Create a Class, Creating Your Own Types (Type Aliasing), Advantages of Access Routines
access routines for, Advantages of Access Routines (see )
ADTs for, Example of the Need for an ADT
barriers to, Two Categories of Secrets
categories of secrets, An Example of Information Hiding
circular dependencies problem, Two Categories of Secrets
class data mistaken for global data, Two Categories of Secrets
class design considerations, Secrets and the Right to Privacy
class implementation details, Reasons to Create a Class
example, Secrets and the Right to Privacy
excessive distribution problem, Two Categories of Secrets
importance of, Inherit—When Inheritance Simplifies the Design
interfaces, class, Secrets and the Right to Privacy
performance issues, Barriers to Information Hiding
privacy rights of classes, Inherit—When Inheritance Simplifies the Design
resources for, Software Design, General
secrets concept, Inherit—When Inheritance Simplifies the Design
type creation for, Creating Your Own Types (Type Aliasing)
inheritance, Find Real-World Objects, Inherit—When Inheritance Simplifies the Design, Good Abstraction, Good Encapsulation, Good Encapsulation, Containment ("has a" Relationships), Containment ("has a" Relationships), Containment ("has a" Relationships), Containment ("has a" Relationships), Containment ("has a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Multiple Inheritance, Multiple Inheritance, Multiple Inheritance, Beyond Classes: Packages, Key Points, Reasons to Refactor, Class Interface Refactorings
access privileges from, Inheritance ("is a" Relationships) (see )
case statements, Inheritance ("is a" Relationships)
checklist, Beyond Classes: Packages
containment compared to, Good Encapsulation
decisions involved in, Containment ("has a" Relationships)
deep trees, Inheritance ("is a" Relationships)
defined, Containment ("has a" Relationships)
design rule for, Containment ("has a" Relationships)
functions, private, overriding, Inheritance ("is a" Relationships)
guidelines, list of, Multiple Inheritance
heuristic design with, Inherit—When Inheritance Simplifies the Design
identifying as a design step, Find Real-World Objects
is a relationships, Containment ("has a" Relationships)
key points for, Key Points
Liskov Substitution Principle, Containment ("has a" Relationships)
main goal of, Good Abstraction
mixins, Multiple Inheritance
multiple, Inheritance ("is a" Relationships)
overridable vs. non-overridable routines, Inheritance ("is a" Relationships)
parallel modifications refactoring indicator, Reasons to Refactor
placement of common items in tree, Inheritance ("is a" Relationships)
private vs. protected data, Inheritance ("is a" Relationships)
private, avoiding, Good Encapsulation
recommended bias against, Multiple Inheritance
routines overridden to do nothing, Inheritance ("is a" Relationships)
similar sub and super classes, Class Interface Refactorings
single-instance classes, Inheritance ("is a" Relationships)
initializing variables, Implicit Declarations, Implicit Declarations, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, General Guidelines for Minimizing Scope, Using Each Variable for Exactly One Purpose, Using Each Variable for Exactly One Purpose, Strings in C, Knowledge of How to Interpret the Contents, Common Problems with Global Data, Symbolic Debuggers, Fixing a Defect
accumulators, Guidelines for Initializing Variables
at declaration guideline, Guidelines for Initializing Variables
C++ example, Guidelines for Initializing Variables
checklist for, Using Each Variable for Exactly One Purpose
class members, Guidelines for Initializing Variables
compiler settings, Guidelines for Initializing Variables
consequences of failing to, Implicit Declarations
const recommended, Guidelines for Initializing Variables
constants, Guidelines for Initializing Variables
counters, Guidelines for Initializing Variables
declare and define near first use rule, Guidelines for Initializing Variables
final recommended, Guidelines for Initializing Variables
first use guideline, Guidelines for Initializing Variables
fixing defects, Fixing a Defect
global variables, Common Problems with Global Data
importance of, Implicit Declarations
Java example, Guidelines for Initializing Variables
key point, Using Each Variable for Exactly One Purpose
loops, variables used in, General Guidelines for Minimizing Scope
parameter validity, Guidelines for Initializing Variables
pointer problems, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Knowledge of How to Interpret the Contents
Principle of Proximity, Guidelines for Initializing Variables
reinitialization, Guidelines for Initializing Variables
strings, Strings in C
system perturbers, testing with, Symbolic Debuggers
Visual Basic examples, Guidelines for Initializing Variables
initializing working memory, Guidelines for Initializing Variables
inline routines, Macro Routines and Inline Routines
input parameters, Guidelines for a Language-Independent Convention
input/output, Input/Output
inspections, What Results Can You Expect from Inspections?
installation tools, Code-Generation Wizards
instancing objects, Look for Common Design Patterns, Look for Common Design Patterns, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Constructors
ADTs, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
factory method, Look for Common Design Patterns
singleton, Look for Common Design Patterns, Constructors
integer data types, Numbers in General, Numbers in General, Integers, Guidelines for Creating Your Own Types, Relative Performance Costs of Common Operations
checklist, Guidelines for Creating Your Own Types (see )
costs of operations, Relative Performance Costs of Common Operations
division considerations, Numbers in General
overflows, Numbers in General
ranges of, Integers
Integrated Development Environments (IDEs), Programming Tools
integration, Developer Testing, Integration, Integration, Importance of the Integration Approach, Importance of the Integration Approach, Importance of the Integration Approach, Importance of the Integration Approach, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Benefits of Incremental Integration, Top-Down Integration, Top-Down Integration, Top-Down Integration, Top-Down Integration, Bottom-Up Integration, Bottom-Up Integration, Bottom-Up Integration, Bottom-Up Integration, Bottom-Up Integration, Bottom-Up Integration, Sandwich Integration, Feature-Oriented Integration, Feature-Oriented Integration, Summary of Integration Approaches, Summary of Integration Approaches, Summary of Integration Approaches, Daily Build and Smoke Test, Daily Build and Smoke Test, Daily Build and Smoke Test, Continuous Integration, Continuous Integration, Integration
benefits of, Importance of the Integration Approach, Benefits of Incremental Integration
big-bang, Importance of the Integration Approach
bottom-up strategy, Bottom-Up Integration
broken builds, Daily Build and Smoke Test
checklist, Continuous Integration
classes, Importance of the Integration Approach, Benefits of Incremental Integration, Bottom-Up Integration
continuous, Daily Build and Smoke Test
customer relations, Benefits of Incremental Integration
daily build and smoke test, Summary of Integration Approaches
defined, Integration
disadvantages of top-down strategy, Top-Down Integration
errors, locating, Benefits of Incremental Integration
feature-oriented strategy, Feature-Oriented Integration
importance of approach methods, Integration
interface specification, Top-Down Integration, Bottom-Up Integration
key points, Integration
monitoring, Benefits of Incremental Integration
phased, Importance of the Integration Approach
resources on, Continuous Integration
risk-oriented strategy, Sandwich Integration
sandwich strategy, Bottom-Up Integration
scheduling, Benefits of Incremental Integration
slices approach, Bottom-Up Integration
smoke tests, Daily Build and Smoke Test
strategies for, overview, Benefits of Incremental Integration
stubs, Benefits of Incremental Integration, Top-Down Integration
summary of approaches, Summary of Integration Approaches
T-shaped integration, Feature-Oriented Integration
testing, Developer Testing, Bottom-Up Integration
top-down strategy for, Benefits of Incremental Integration
unsurfaced work, Summary of Integration Approaches
vertical-slice approach, Top-Down Integration
integrity, Characteristics of Software Quality
intellectual honesty, Intellectual Honesty
intellectual toolbox approach, Applying Software Techniques: The Intellectual Toolbox
intelligence, role in character, Intelligence and Humility
interfaces, class, Find Real-World Objects, Find Real-World Objects, Secrets and the Right to Privacy, Build Hierarchies, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Abstraction, Good Encapsulation, Good Encapsulation, Good Encapsulation, Good Encapsulation, Multiple Inheritance, Key Points, Reasons to Refactor, Class Implementation Refactorings, Class Implementation Refactorings, Class Implementation Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, System-Level Refactorings, Top-Down Integration, Bottom-Up Integration, Interface Documentation Tools, Laying Out Routines, General Guidelines for Class Documentation
abstraction aspect of, Find Real-World Objects, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments, Reasons to Refactor
calls to classes, refactoring, Class Implementation Refactorings
cohesion, Good Abstraction
consistent level of abstraction, Good Abstraction
delegation vs. inheritance, refactoring, Class Interface Refactorings
documenting, Interface Documentation Tools, General Guidelines for Class Documentation
erosion under modification problem, Good Abstraction
evaluating abstraction of, Good Abstraction
extension classes, refactoring with, Class Interface Refactorings
foreign routines, refactoring with, Class Interface Refactorings
formalizing as contracts, Build Hierarchies
good abstraction example, Handling Multiple Instances of Data with ADTs in Non-Object-Oriented Environments
guidelines for creating, Good Abstraction
inconsistency with members problem, Good Abstraction
inconsistent abstraction, example of, Good Abstraction
information hiding role, Secrets and the Right to Privacy
integration, specification during, Top-Down Integration, Bottom-Up Integration
key points for, Key Points
layout of, Laying Out Routines
mixins, Multiple Inheritance
objects, designing for, Find Real-World Objects
opposites, pairs of, Good Abstraction
poor abstraction example, Good Abstraction
private details in, Good Encapsulation
programmatic preferred to semantic, Good Abstraction
public routines in interfaces concern, Good Encapsulation
read-time convenience rule, Good Encapsulation
refactoring, Class Implementation Refactorings, System-Level Refactorings
routines, moving to refactor, Class Implementation Refactorings
routines, unused, Class Interface Refactorings
semantic violations of encapsulation, Good Encapsulation
unrelated information, handling, Good Abstraction
interfaces, graphic, Business Rules
interfaces, routine, How to Use Routine Parameters, Code the Routine, Class Implementation Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, Commenting Routines
commenting, Commenting Routines
foreign routines, refactoring with, Class Interface Refactorings
pseudocode for, Code the Routine
public member variables, Class Interface Refactorings
routines, hiding, Class Interface Refactorings
routines, moving to refactor, Class Implementation Refactorings
internationalization, Performance
interoperability, Performance
interpreted languages, performance of, Common Sources of Inefficiency
invalid input, Assertions
iteration in development, Appeal to Analogy, Determine the Kind of Software You're Working On, Determine the Kind of Software You're Working On, Choosing Between Iterative and Sequential Approaches, General Software-Development Approaches, Iterate, Pseudocode for Pros, Watch for Falling Rocks, Watch for Falling Rocks
choosing, reasons for, Choosing Between Iterative and Sequential Approaches (see )
code tuning, Watch for Falling Rocks
design practice, Iterate
Extreme Programming, General Software-Development Approaches
importance of, Watch for Falling Rocks
prerequisites, Appeal to Analogy, Determine the Kind of Software You're Working On
pseudocode component of, Pseudocode for Pros
sequential approach compared, Determine the Kind of Software You're Working On
iteration, code, Look for Common Design Patterns, Relationship Between Data Types and Control Structures, Controlling Loops, Controlling Loops, Normal Loop-With-Exit Loops, When to Use a for Loop, Iteration
foreach loops, Controlling Loops, When to Use a for Loop
iterative data, Relationship Between Data Types and Control Structures
iterator loops, defined, Controlling Loops
Iterator pattern, Look for Common Design Patterns
structured programming concept of, Iteration

J

jamming loops, Unswitching
Java, Java, Classes in General, How to Use Routine Parameters, Assertions, Exceptions, Keep Variables "Live" for as Short a Time as Possible, Comments on Minimizing Scope, C++ Conventions, Sample Naming Conventions, Common Problems with Boolean Expressions, Endline Layout
assertion example in, Assertions
boolean expression syntax, Common Problems with Boolean Expressions
description of, Java
exceptions, Exceptions
layout recommended, Endline Layout
live time examples, Keep Variables "Live" for as Short a Time as Possible
naming conventions for, C++ Conventions, Sample Naming Conventions
parameters example, How to Use Routine Parameters
persistence of variables, Comments on Minimizing Scope
resources for, Classes in General
Javadoc, Commenting Routines, Additional Resources
JavaScript, Java
JUnit, Testing
just in time binding, Binding Time

K

key construction decisions, Example of Programming into a Language
killed data state, Structured Basis Testing
kinds of software projects, Boss-Readiness Test

L

languages, programming, Choice of Programming Language
Law of Demeter, Member Functions and Data
layout, Layout Fundamentals, Layout Extremes, Layout Extremes, Layout Extremes, Layout Extremes, Layout Extremes, Human and Computer Interpretations of a Program, Human and Computer Interpretations of a Program, Human and Computer Interpretations of a Program, How Much Is Good Layout Worth?, Layout as Religion, Layout as Religion, Layout as Religion, Layout as Religion, Layout as Religion, Objectives of Good Layout, Objectives of Good Layout, White Space, White Space, Parentheses, Parentheses, Parentheses, Parentheses, Parentheses, Pure Blocks, Pure Blocks, Using begin-end Pairs (Braces) to Designate Block Boundaries, Using begin-end Pairs (Braces) to Designate Block Boundaries, Endline Layout, Endline Layout, Fine Points of Formatting Control-Structure Blocks, Fine Points of Formatting Control-Structure Blocks, Fine Points of Formatting Control-Structure Blocks, Other Considerations, Other Considerations, Other Considerations, Other Considerations, Laying Out Individual Statements, Laying Out Individual Statements, Laying Out Individual Statements, Using Spaces for Clarity, Using Spaces for Clarity, Using Spaces for Clarity, Using Spaces for Clarity, Using Spaces for Clarity, Formatting Continuation Lines, Formatting Continuation Lines, Formatting Continuation Lines, Formatting Continuation Lines, Formatting Continuation Lines, Formatting Continuation Lines, Using Only One Statement Per Line, Using Only One Statement Per Line, Laying Out Data Declarations, Laying Out Data Declarations, Laying Out Data Declarations, Laying Out Comments, Laying Out Routines, Laying Out Routines, Laying Out Class Implementations, Laying Out Files and Programs, Laying Out Files and Programs, Additional Resources, External Documentation, Commenting Paragraphs of Code
array references, Using Spaces for Clarity (see ; ; ; ; )
assignment statement continuations, Formatting Continuation Lines
begin-end pairs, Using begin-end Pairs (Braces) to Designate Block Boundaries
blank lines, White Space, Fine Points of Formatting Control-Structure Blocks
block style, Parentheses
brace styles, How Much Is Good Layout Worth?, Pure Blocks
C++ side effects, Using Only One Statement Per Line
checklist, Laying Out Files and Programs
classes, Laying Out Routines
closely related statement elements, Formatting Continuation Lines
comments, Laying Out Data Declarations
complicated expressions, Other Considerations
consistency requirement, Layout as Religion
continuing statements, Using Spaces for Clarity
control statement continuations, Formatting Continuation Lines
control structure styles, Endline Layout
declarations, Using Only One Statement Per Line
discourse rules, Human and Computer Interpretations of a Program
documentation in code, Laying Out Data Declarations
double indented begin-end pairs, Fine Points of Formatting Control-Structure Blocks
emulating pure blocks, Pure Blocks
endline layout, Using begin-end Pairs (Braces) to Designate Block Boundaries, Other Considerations
ends of continuations, Formatting Continuation Lines
files, within, Laying Out Class Implementations
Fundamental Theorem of Formatting, Layout Extremes
gotos, Other Considerations
incomplete statements, Using Spaces for Clarity
indentation, White Space
interfaces, Laying Out Routines
key points, Additional Resources
language-specific guidelines, Endline Layout
logical expressions, Laying Out Individual Statements
logical structure, reflecting, Layout Extremes, Layout as Religion
mediocre example, Layout Extremes
misleading indentation example, Layout Extremes
misleading precedence, Human and Computer Interpretations of a Program
modifications guideline, Objectives of Good Layout
multiple statements per line, Formatting Continuation Lines
negative examples, Layout Fundamentals
objectives of, Layout as Religion
parentheses for, Parentheses
pointers, C++, Laying Out Data Declarations
pure blocks style, Parentheses
readability goal, Layout as Religion
religious aspects of, Layout as Religion
resources on, Laying Out Files and Programs
routine arguments, Using Spaces for Clarity
routine call continuations, Formatting Continuation Lines
routine guidelines, Laying Out Comments
self-documenting code, External Documentation
single-statement blocks, Other Considerations
statement continuation, Using Spaces for Clarity
statement length, Laying Out Individual Statements
structures, importance of, Human and Computer Interpretations of a Program
styles overview, Parentheses
unindented begin-end pairs, Fine Points of Formatting Control-Structure Blocks
violations of, commenting, Commenting Paragraphs of Code
Visual Basic blocking style, Parentheses
white space, Layout Extremes, Objectives of Good Layout, Laying Out Individual Statements
laziness, Laziness
lazy evaluation, Substitute Table Lookups for Complicated Expressions
leanness design goal, Desirable Characteristics of a Design
legal notices, General Guidelines for File Documentation
length of variable names, optimum, Optimum Name Length
levels of design, Levels of Design, Levels of Design, Levels of Design, Levels of Design, Level 2: Division into Subsystems or Packages, Level 2: Division into Subsystems or Packages, Level 2: Division into Subsystems or Packages, Level 2: Division into Subsystems or Packages, Level 3: Division into Classes, Level 3: Division into Classes
business logic subsystem, Level 2: Division into Subsystems or Packages
classes, divisions into, Level 3: Division into Classes
database access subsystem, Level 2: Division into Subsystems or Packages
overview of, Levels of Design
packages, Levels of Design
routines, Level 3: Division into Classes
software system, Levels of Design
subsystems, Levels of Design
system dependencies subsystem, Level 2: Division into Subsystems or Packages
user interface subsystem, Level 2: Division into Subsystems or Packages
libraries, code, Design the Routine, Build Tools
purpose of, Build Tools
using functionality from, Design the Routine
life-cycle models, Boss-Readiness Test, The Book Paradigm for Program Documentation
development standard, The Book Paradigm for Program Documentation
good practices table for, Boss-Readiness Test
linked lists, Knowledge of How to Interpret the Contents, General Tips on Pointers, General Tips on Pointers
deleting pointers, General Tips on Pointers
node insertion, General Tips on Pointers
pointers, isolating operations of, Knowledge of How to Interpret the Contents
linkers, Executable-Code Tools
lint tool, Compiler Warning Messages
Liskov Substitution Principle (LSP), Containment ("has a" Relationships)
literal data, Floating-Point Numbers, Named Constants
literate programs, Common Software Metaphors
live time of variables, Keep Variables "Live" for as Short a Time as Possible, Other Kinds of Complexity
load time, binding during, Binding Time
localization, Performance, Characters and Strings
architecture prerequisites, Performance
string data types, Characters and Strings
locking global data, How to Use Access Routines
logarithms, Use Strength Reduction
logging, Determining How Much Defensive Programming to Leave in Production Code, Coverage Monitors
defensive programming guideline, Determining How Much Defensive Programming to Leave in Production Code
tools for testing, Coverage Monitors
logic coverage testing, Structured Basis Testing
logical cohesion, Design at the Routine Level
logical expressions, Writing Numeric Expressions in Number-Line Order, Code-Tuning Techniques, Code-Tuning Techniques, Code-Tuning Techniques, Order Tests by Frequency, Compare Performance of Similar Logic Structures, Compare Performance of Similar Logic Structures, Substitute Table Lookups for Complicated Expressions, Expressions, Laying Out Individual Statements
code tuning, Code-Tuning Techniques
comparing performance of, Compare Performance of Similar Logic Structures
eliminating testing redundancy, Code-Tuning Techniques
frequency, testing in order of, Order Tests by Frequency
identities, Expressions
layout of, Laying Out Individual Statements
lazy evaluation, Substitute Table Lookups for Complicated Expressions
lookup tables, substituting, Compare Performance of Similar Logic Structures
short-circuit evaluation, Code-Tuning Techniques
loops, General Guidelines for Minimizing Scope, Relationship Between Data Types and Control Structures, Naming Loop Indexes, Enumerated Types, Controlling Loops, Controlling Loops, Controlling Loops, Controlling Loops, Controlling Loops, Controlling Loops, Controlling Loops, Controlling Loops, Selecting the Kind of Loop, Selecting the Kind of Loop, Selecting the Kind of Loop, Loop with Test at the Beginning, Loop with Test at the Beginning, Normal Loop-With-Exit Loops, Normal Loop-With-Exit Loops, Normal Loop-With-Exit Loops, When to Use a for Loop, When to Use a for Loop, Controlling the Loop, Controlling the Loop, Controlling the Loop, Entering the Loop, Entering the Loop, Entering the Loop, Entering the Loop, Entering the Loop, Entering the Loop, Entering the Loop, Processing the Middle of the Loop, Processing the Middle of the Loop, Exiting the Loop, Exiting the Loop, Exiting the Loop, Exiting the Loop, Exiting the Loop, Exiting the Loop, Exiting the Loop, Exiting the Loop, Exiting the Loop, Exiting Loops Early, Exiting Loops Early, Exiting Loops Early, Exiting Loops Early, Exiting Loops Early, Exiting Loops Early, Exiting Loops Early, Checking Endpoints, Checking Endpoints, Checking Endpoints, Using Loop Variables, Using Loop Variables, Using Loop Variables, How Long Should a Loop Be?, How Long Should a Loop Be?, How Long Should a Loop Be?, How Long Should a Loop Be?, How Long Should a Loop Be?, Creating Loops Easily—From the Inside Out, Correspondence Between Loops and Arrays, Correspondence Between Loops and Arrays, Correspondence Between Loops and Arrays, Correspondence Between Loops and Arrays, Correspondence Between Loops and Arrays, Correspondence Between Loops and Arrays, Correspondence Between Loops and Arrays, Null Statements, Iteration, Philosophy of Software Evolution, Philosophy of Software Evolution, Statement-Level Refactorings, Common Sources of Inefficiency, Code-Tuning Techniques, Use Lazy Evaluation, Use Lazy Evaluation, Use Lazy Evaluation, Unswitching, Unswitching, Jamming, Unrolling, Unrolling, Minimizing the Work Inside Loops, Minimizing the Work Inside Loops, Sentinel Values, Sentinel Values, Sentinel Values, Layout Extremes, Fine Points of Formatting Control-Structure Blocks, Formatting Continuation Lines, Commenting Control Structures
abnormal, Normal Loop-With-Exit Loops (see ; )
arrays with, Creating Loops Easily—From the Inside Out
bodies of, processing, Entering the Loop, Correspondence Between Loops and Arrays
brackets recommended, Entering the Loop
break statements, Normal Loop-With-Exit Loops, Exiting the Loop, Exiting Loops Early
checklist, Correspondence Between Loops and Arrays
code tuning, Use Lazy Evaluation
commenting, Commenting Control Structures
completion tests, location of, Selecting the Kind of Loop
compound, simplifying, Minimizing the Work Inside Loops
continuation lines in, Formatting Continuation Lines
continue statements, Exiting the Loop, Exiting Loops Early, Exiting Loops Early
continuously evaluated loops, Controlling Loops
(see also )
counted loops, Controlling Loops
(see also )
cross talk, Using Loop Variables
defined, Controlling Loops
designing, process for, How Long Should a Loop Be?
do loops, Loop with Test at the Beginning
empty, avoiding, Entering the Loop
endless loops, Controlling Loops, Entering the Loop
endpoint considerations, Exiting Loops Early
entering, guidelines for, Controlling the Loop, Correspondence Between Loops and Arrays
enumerated types for, Enumerated Types
exit guidelines, Loop with Test at the Beginning, Exiting the Loop, Correspondence Between Loops and Arrays
for loops, When to Use a for Loop, Entering the Loop, Layout Extremes, Fine Points of Formatting Control-Structure Blocks
foreach loops, Controlling Loops, When to Use a for Loop
fusion of, Unswitching
goto with, Normal Loop-With-Exit Loops
housekeeping statements, Processing the Middle of the Loop
index alterations, Exiting the Loop
index checklist, Correspondence Between Loops and Arrays
index final values, Exiting the Loop
index scope, Using Loop Variables
index variable names, Naming Loop Indexes
infinite loops, Controlling Loops, Entering the Loop
initialization code for, Controlling the Loop, Entering the Loop
iterative data structures with, Relationship Between Data Types and Control Structures
iterator loops, Controlling Loops, Iteration
jamming, Unswitching
key points, Correspondence Between Loops and Arrays
kinds of, generalized, Controlling Loops
labeled break statements, Exiting Loops Early
language-specific, table of, Selecting the Kind of Loop
length of, How Long Should a Loop Be?
minimizing work inside, Unrolling
multiple break statements, Exiting Loops Early
naming variables, Checking Endpoints
nested, Checking Endpoints, How Long Should a Loop Be?, Sentinel Values
null statements, rewriting, Null Statements
off-by-one errors, Exiting Loops Early
one-function guideline, Processing the Middle of the Loop
order of nesting, Sentinel Values
performance considerations, Common Sources of Inefficiency
pointers inside, Unrolling
problems with, overview of, Controlling the Loop
pseudocode method, How Long Should a Loop Be?
refactoring, Philosophy of Software Evolution, Statement-Level Refactorings
repeat until clauses, Exiting the Loop
routines in, How Long Should a Loop Be?
safety counters with, Exiting the Loop
scope of indexes, Using Loop Variables
sentinel tests for, Minimizing the Work Inside Loops
size as refactoring indicator, Philosophy of Software Evolution
strength reduction, Sentinel Values
switching, Use Lazy Evaluation
termination, making obvious, Exiting the Loop
testing redundancy, eliminating, Code-Tuning Techniques
unrolling, Jamming
unswitching, Use Lazy Evaluation
variable guidelines, Checking Endpoints
variable initializations, General Guidelines for Minimizing Scope
variables checklist, Correspondence Between Loops and Arrays
verifying termination, Exiting the Loop
while loops, Selecting the Kind of Loop
loose coupling, Desirable Characteristics of a Design, Keep Coupling Loose
design goal, as, Desirable Characteristics of a Design
strategies for, Keep Coupling Loose
low-to-medium fan-out design goal, Desirable Characteristics of a Design
LSP (Liskov Substitution Principle), Containment ("has a" Relationships)

M

Macintosh naming conventions, Guidelines for Language-Specific Conventions
macro routines, Inheritance ("is a" Relationships), When to Use a Function and When to Use a Procedure, Macro Routines and Inline Routines, Macro Routines and Inline Routines, Macro Routines and Inline Routines, Macro Routines and Inline Routines, Sample Naming Conventions
alternatives for, Macro Routines and Inline Routines (see )
limitations on, Macro Routines and Inline Routines
multiple statements in, Macro Routines and Inline Routines
naming, Macro Routines and Inline Routines, Sample Naming Conventions
parentheses with, When to Use a Function and When to Use a Procedure
magazines on programming, Lowbrow Programmer Magazines
magic variables, avoiding, Numbers in General, Floating-Point Numbers, Named Constants
maintenance, Desirable Characteristics of a Design, Structures, Characteristics of Software Quality, Which Classes Contain the Most Errors?, Fixing a Defect, Description of the Code's Intent, Write Programs for People First, Computers Second
comments requiring, Description of the Code's Intent
design goal for, Desirable Characteristics of a Design
error-prone routines, prioritizing for, Which Classes Contain the Most Errors?
fixing defects, problems from, Fixing a Defect
maintainability defined, Characteristics of Software Quality
readability benefit for, Write Programs for People First, Computers Second
structures for reducing, Structures
major construction practices checklist, Example of Programming into a Language
managing construction, Design Is Emergent, What Results Can You Expect from Inspections?, Managing Construction, Managing Construction, Managing Construction, Techniques for Encouraging Good Coding, Techniques for Encouraging Good Coding, Techniques for Encouraging Good Coding, Techniques for Encouraging Good Coding, Techniques for Encouraging Good Coding, Estimating a Construction Schedule, Additional Resources on Software Estimation, Additional Resources on Software Measurement, Additional Resources on Programmers as Human Beings, Additional Resources on Managing Construction, Additional Resources on Managing Construction, Key Points, Software Quality-Assurance Standards
code ownership attitudes, Techniques for Encouraging Good Coding (see )
complexity, Design Is Emergent
good coding, encouraging, Managing Construction
inspections, management role in, What Results Can You Expect from Inspections?
key points, Key Points
managers, Additional Resources on Programmers as Human Beings
measurements, Additional Resources on Software Estimation
programmers, treatment of, Additional Resources on Software Measurement
readability standard, Techniques for Encouraging Good Coding
resources on, Additional Resources on Managing Construction
reviewing all code, Techniques for Encouraging Good Coding
rewarding good practices, Techniques for Encouraging Good Coding
schedules, estimating, Estimating a Construction Schedule
signing off on code, Techniques for Encouraging Good Coding
standards, authority to set, Managing Construction
standards, IEEE, Additional Resources on Managing Construction, Software Quality-Assurance Standards
two-person teams, Managing Construction
markers, defects from, Marker in the Code
matrices, Arrays
mature technology environments, Your Location on the Technology Wave
maximum normal configurations, Classes of Bad Data
maze recursion example, Recursion
McCabe's complexity metric, Control Structures and Complexity, How to Measure Complexity
measure twice, cut once, Measure Twice, Cut Once: Upstream Prerequisites
measurement, Additional Resources on Software Estimation, Measurement, Measurement, Measurement, Measurement, Measurement, Measurement
advantages of, Additional Resources on Software Estimation
arguing against, Measurement
goals for, Measurement
outlier identification, Measurement
resources for, Measurement
side effects of, Measurement
table of useful types of, Measurement
memory, Introduce Debugging Aids Early, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, Symbolic Debuggers, Common Sources of Inefficiency
allocation, error detection for, Introduce Debugging Aids Early
corruption by pointers, Knowledge of How to Interpret the Contents
fillers, Guidelines for Initializing Variables
initializing working, Guidelines for Initializing Variables
paging operation performance impact, Common Sources of Inefficiency
pointers, corruption by, Knowledge of How to Interpret the Contents
tools for, Symbolic Debuggers
mentoring, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise
merge tools, Multiple-File String Searching and Replacing
metaphors, software, Metaphors for a Richer Understanding of Software Development, Metaphors for a Richer Understanding of Software Development, Metaphors for a Richer Understanding of Software Development, The Importance of Metaphors, The Importance of Metaphors, The Importance of Metaphors, The Importance of Metaphors, The Importance of Metaphors, The Importance of Metaphors, The Importance of Metaphors, The Importance of Metaphors, The Importance of Metaphors, How to Use Software Metaphors, How to Use Software Metaphors, Common Software Metaphors, Common Software Metaphors, Common Software Metaphors, Common Software Metaphors, Software Penmanship: Writing Code, Software Penmanship: Writing Code, Software Farming: Growing a System, Software Farming: Growing a System, Software Farming: Growing a System, Software Oyster Farming: System Accretion, Software Oyster Farming: System Accretion, Software Construction: Building Software, Software Construction: Building Software, Software Construction: Building Software, Applying Software Techniques: The Intellectual Toolbox, Applying Software Techniques: The Intellectual Toolbox, Key Points
accreting a system, Software Farming: Growing a System
algorithmic use of, The Importance of Metaphors, How to Use Software Metaphors
building metaphor, Software Oyster Farming: System Accretion
building vs. buying components, Software Construction: Building Software
combining, Applying Software Techniques: The Intellectual Toolbox
computer-centric vs. data-centric views, The Importance of Metaphors
customization, Software Construction: Building Software
discoveries based on, Metaphors for a Richer Understanding of Software Development
earth centric vs. sun centric views, The Importance of Metaphors
examples of, Common Software Metaphors
farming, Software Penmanship: Writing Code
growing a system, Software Penmanship: Writing Code
heuristic use of, How to Use Software Metaphors
importance of, Metaphors for a Richer Understanding of Software Development
incremental development, Software Farming: Growing a System
key points for, Key Points
modeling use for, Metaphors for a Richer Understanding of Software Development
overextension of, The Importance of Metaphors
oyster farming, Software Farming: Growing a System
pendulum example, The Importance of Metaphors
power of, The Importance of Metaphors
readability, Common Software Metaphors
relative merits of, The Importance of Metaphors, The Importance of Metaphors
simple vs. complex structures, Software Oyster Farming: System Accretion
size of projects, Software Construction: Building Software
throwing one away, Common Software Metaphors
toolbox approach, Applying Software Techniques: The Intellectual Toolbox
using, The Importance of Metaphors
writing code example, Common Software Metaphors
methodologies, Programs, Products, Systems, and System Products
(see also )
methods, Inheritance ("is a" Relationships)
metrics reporters, Picky Syntax and Semantics Checkers
minimum normal configurations, Classes of Bad Data
mission-critical systems, Boss-Readiness Test
mixed-language environments, C++ Conventions
mixins, Multiple Inheritance
mock objects, Test-Support Tools
modeling, metaphors as, Software Farming: Growing a System
moderator role in inspections, What Results Can You Expect from Inspections?
modularity, Avoid Failure, Common Problems with Global Data
design goal of, Avoid Failure
global variables, damage from, Common Problems with Global Data
modules, coupling considerations, Keep Coupling Loose
multiple inheritance, Inheritance ("is a" Relationships)
multiple returns from routines, Unusual Control Structures
multiple-file string search capability, Integrated Development Environments (IDEs)

N

named constants, Guidelines for Creating Your Own Types
naming conventions, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Good Routine Names, Good Routine Names, Good Routine Names, Good Routine Names, How to Use Routine Parameters, Design the Routine, Naming Boolean Variables, Naming Constants, Naming Constants, Naming Constants, Naming Constants, Why Have Conventions?, Why Have Conventions?, Why Have Conventions?, Informal Naming Conventions, Informal Naming Conventions, Informal Naming Conventions, Informal Naming Conventions, Informal Naming Conventions, Informal Naming Conventions, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Guidelines for Language-Specific Conventions, Guidelines for Language-Specific Conventions, Guidelines for Language-Specific Conventions, C++ Conventions, C++ Conventions, Sample Naming Conventions, Sample Naming Conventions, Sample Naming Conventions, Sample Naming Conventions, Sample Naming Conventions, Standardized Prefixes, Standardized Prefixes, Standardized Prefixes, User-Defined Type Abbreviations, User-Defined Type Abbreviations, Creating Short Names That Are Readable, Creating Short Names That Are Readable, Creating Short Names That Are Readable, Phonetic Abbreviations, Phonetic Abbreviations, Phonetic Abbreviations, Comments on Abbreviations, Comments on Abbreviations, Comments on Abbreviations, Comments on Abbreviations, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, How to Use Access Routines, External Documentation, Programming Style as Documentation, General Guidelines for File Documentation
"a" prefix convention, Informal Naming Conventions (see ; )
abbreviating names, Creating Short Names That Are Readable
abbreviation guidelines, Creating Short Names That Are Readable
arrays, User-Defined Type Abbreviations
benefits of, Naming Constants
C language, Guidelines for Language-Specific Conventions, Sample Naming Conventions
C++, Guidelines for Language-Specific Conventions
capitalization, Guidelines for a Language-Independent Convention, Kinds of Names to Avoid
case-insensitive languages, Guidelines for a Language-Independent Convention
characters, hard to read, Kinds of Names to Avoid
checklist, Kinds of Names to Avoid, Programming Style as Documentation
class member variables, Guidelines for a Language-Independent Convention
class vs. object names, Informal Naming Conventions
common operations, for, Good Routine Names
constants, Guidelines for a Language-Independent Convention
cross-project benefits, Naming Constants
descriptiveness guideline, Design at the Routine Level
documentation, Comments on Abbreviations, External Documentation
enumerated types, Naming Boolean Variables, Guidelines for a Language-Independent Convention, Sample Naming Conventions
files, General Guidelines for File Documentation
formality, degrees of, Why Have Conventions?
function return values, Good Routine Names
global variables, Guidelines for a Language-Independent Convention, How to Use Access Routines
homonyms, Kinds of Names to Avoid
Hungarian, Standardized Prefixes
informal, Informal Naming Conventions
input parameters, Guidelines for a Language-Independent Convention
Java, C++ Conventions, Sample Naming Conventions
key points, Kinds of Names to Avoid
kinds of information in names, Sample Naming Conventions
language-independence guidelines, Informal Naming Conventions
length, not limiting, Design at the Routine Level
Macintosh, Guidelines for Language-Specific Conventions
meanings in names, too similar, Comments on Abbreviations
misleading names, Comments on Abbreviations
misspelled words, Kinds of Names to Avoid
mixed-language considerations, C++ Conventions
multiple natural languages, Kinds of Names to Avoid
numbers, differentiating solely by, Design at the Routine Level
numerals, Kinds of Names to Avoid
opposites, use of, Good Routine Names
parameters, How to Use Routine Parameters
phonic abbreviations, Phonetic Abbreviations
prefix standardization, Standardized Prefixes
procedure descriptions, Good Routine Names
proliferation reduction benefit, Naming Constants
pronunciation guideline, Phonetic Abbreviations
purpose of, Naming Constants
readability, Guidelines for a Language-Independent Convention
relationships, emphasis of, Why Have Conventions?
reserved names, Kinds of Names to Avoid
routines, Design at the Routine Level, Design the Routine
semantic prefixes, User-Defined Type Abbreviations
short names, Creating Short Names That Are Readable, Kinds of Names to Avoid
similarity of names, too much, Comments on Abbreviations
spacing characters, Guidelines for a Language-Independent Convention
thesaurus, using, Phonetic Abbreviations
types vs. variables names, Informal Naming Conventions
t_ prefix convention, Informal Naming Conventions
UDT abbreviations, Standardized Prefixes
Visual Basic, Sample Naming Conventions
when to use, Why Have Conventions?
nested if statements, Null Statements, Null Statements, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting
case statements, converting to, Taming Dangerously Deep Nesting, Taming Dangerously Deep Nesting (see )
converting to if-then-else statements, Taming Dangerously Deep Nesting
factoring to routines, Taming Dangerously Deep Nesting
factory method approach, converting to, Taming Dangerously Deep Nesting
functional decomposition of, Taming Dangerously Deep Nesting
object-oriented approach, converting to, Taming Dangerously Deep Nesting
redesigning, Taming Dangerously Deep Nesting
simplification by retesting conditions, Null Statements
simplification with break blocks, Taming Dangerously Deep Nesting
summary of techniques for reducing, Taming Dangerously Deep Nesting
too many levels of, Null Statements
nested loops, Checking Endpoints, How Long Should a Loop Be?, Sentinel Values
designing, Checking Endpoints, How Long Should a Loop Be?
ordering for performance, Sentinel Values
nondeterministic nature of design process, Design Is a Sloppy Process (Even If it Produces a Tidy Result), Level 5: Internal Routine Design
nonstandard language features, Identify Areas Likely to Change
null objects, refactoring, Statement-Level Refactorings
null statements, Null Statements
numbers, literal, Numbers in General
numeric data types, Numbers in General, Numbers in General, Numbers in General, Numbers in General, Numbers in General, Numbers in General, Numbers in General, Numbers in General, Numbers in General, Integers, Integers, Integers, Floating-Point Numbers, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types, Knowing How Boolean Expressions Are Evaluated, Relative Performance Costs of Common Operations, Relative Performance Costs of Common Operations, Commenting Data Declarations
BCD, Floating-Point Numbers (see )
checklist, Guidelines for Creating Your Own Types
comparisons, Knowing How Boolean Expressions Are Evaluated
compiler warnings, Numbers in General
conversions, showing, Numbers in General
costs of operations, Relative Performance Costs of Common Operations
declarations, commenting, Commenting Data Declarations
floating-point types, Integers, Guidelines for Creating Your Own Types, Relative Performance Costs of Common Operations
hard coded 0s and 1s, Numbers in General
integers, Numbers in General
literal numbers, avoiding, Numbers in General
magic numbers, avoiding, Numbers in General
magnitudes, greatly different, operations with, Integers
mixed-type comparisons, Numbers in General
overflows, Numbers in General
ranges of integers, Integers
zero, dividing by, Numbers in General

O

object-oriented programming, Comments on Popular Methodologies, Classes in General
resources for, Comments on Popular Methodologies, Classes in General
object-parameter coupling, Coupling Criteria
objectives, software quality, Techniques for Improving Software Quality, Development Process
objects, Level 3: Division into Classes, Level 5: Internal Routine Design, Level 5: Internal Routine Design, Find Real-World Objects, Find Real-World Objects, Find Real-World Objects, Find Real-World Objects, Find Real-World Objects, Find Real-World Objects, Find Real-World Objects, Find Real-World Objects, Look for Common Design Patterns, Build Hierarchies, More Examples of ADTs, Constructors, How to Use Routine Parameters, Introduce Debugging Aids Early, Informal Naming Conventions, Taming Dangerously Deep Nesting, Routine-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, System-Level Refactorings
ADTs as, More Examples of ADTs (see )
attribute identification, Find Real-World Objects
class names, differentiating from, Informal Naming Conventions
classes, contrasted to, Level 3: Division into Classes
containment, identifying, Find Real-World Objects
deleting objects, Introduce Debugging Aids Early
factory methods, Look for Common Design Patterns, Taming Dangerously Deep Nesting, System-Level Refactorings
identifying, Find Real-World Objects
inheritance, identifying, Find Real-World Objects
(see also )
interfaces, designing, Find Real-World Objects
(see also )
operations, identifying, Find Real-World Objects
parameters, using as, How to Use Routine Parameters, Routine-Level Refactorings
protected interfaces, designing, Find Real-World Objects
public vs. private members, designing, Find Real-World Objects
real world, finding, Level 5: Internal Routine Design
refactoring, Routine-Level Refactorings
reference objects, Routine-Level Refactorings
responsibilities, assigning to, Build Hierarchies
singleton property, enforcing, Constructors
steps in designing, Level 5: Internal Routine Design
Observer pattern, Look for Common Design Patterns
off-by-one errors, Error Guessing, Fixing a Defect
boundary analysis, Error Guessing
fixing, approaches to, Fixing a Defect
offensive programming, Introduce Debugging Aids Early
one-in, one-out control constructs, Summary of Techniques for Reducing Deep Nesting
operating systems, Program Design
operations, costs of common, Common Sources of Inefficiency
opposites for variable names, Computed-Value Qualifiers in Variable Names
optimization, premature, Pick Your Process
(see also )
oracles, software, Iterate, Repeatedly, Again and Again
out keyword creation, How to Use Routine Parameters
overengineering, Architectural Feasibility
overflows, integer, Numbers in General
overlay linkers, Executable-Code Tools
overridable routines, Inheritance ("is a" Relationships), Summary of Reasons to Create a Class
oyster farming metaphor, Software Farming: Growing a System

P

packages, Summary of Reasons to Create a Class
paging operations, Common Sources of Inefficiency
pair programming, Collaboration Applies As Much Before Construction As After, Collaboration Applies As Much Before Construction As After, Collaboration Applies As Much Before Construction As After, Collaboration Applies As Much Before Construction As After, Collaboration Applies As Much Before Construction As After, Collaboration Applies As Much Before Construction As After, Keys to Success with Pair Programming, Keys to Success with Pair Programming, Keys to Success with Pair Programming, Keys to Success with Pair Programming, Keys to Success with Pair Programming, Keys to Success with Pair Programming, Dog-and-Pony Shows, Comparison of Collaborative Construction Techniques, Inspections
benefits of, Keys to Success with Pair Programming (see )
checklist, Keys to Success with Pair Programming
coding standards support for, Collaboration Applies As Much Before Construction As After
compared to other collaboration, Dog-and-Pony Shows
defined, Collaboration Applies As Much Before Construction As After
inexperienced pairs, Keys to Success with Pair Programming
key points, Inspections
pace, matching, Collaboration Applies As Much Before Construction As After
personality conflicts, Keys to Success with Pair Programming
resources, Comparison of Collaborative Construction Techniques
rotating pairs, Collaboration Applies As Much Before Construction As After
team leaders, Keys to Success with Pair Programming
visibility of monitor, Keys to Success with Pair Programming
watching, Collaboration Applies As Much Before Construction As After
when not to use, Collaboration Applies As Much Before Construction As After
parameters of routines, How Long Can a Routine Be?, How Long Can a Routine Be?, How Long Can a Routine Be?, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, Guidelines for a Language-Independent Convention, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Sample Naming Conventions, Standardized Prefixes, Boolean Variables, Structures, C++-Pointer Pointers, C++-Pointer Pointers, C++-Pointer Pointers, Common Problems with Global Data, Statements That Must Be in a Specific Order, Reasons to Refactor, Reasons Not to Refactor, Statement-Level Refactorings, Routine-Level Refactorings, Commenting Routines
abstraction and object parameters, How to Use Routine Parameters (see )
actual, matching to formal, How to Use Routine Parameters
asterisk (*) rule for pointers, C++-Pointer Pointers
behavior dependence on, Routine-Level Refactorings
by reference vs. by value, C++-Pointer Pointers
checklist for, 185 C-library order, How to Use Routine Parameters
commenting, Commenting Routines
const prefix, How to Use Routine Parameters, How to Use Routine Parameters, Guidelines for a Language-Independent Convention
dependencies, clarifying, Statements That Must Be in a Specific Order
documentation, How to Use Routine Parameters
enumerated types for, Boolean Variables
error variables, How to Use Routine Parameters
formal, matching to actual, How to Use Routine Parameters
global variables for, Common Problems with Global Data
guidelines for use in routines, How Long Can a Routine Be?
in keyword creation, How to Use Routine Parameters
input-modify-output order, How Long Can a Routine Be?
Java, How to Use Routine Parameters
list size as refactoring indicator, Reasons to Refactor
matching actual to formal, How to Use Routine Parameters
naming, How to Use Routine Parameters, How to Use Routine Parameters, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Sample Naming Conventions, Standardized Prefixes
number of, limiting, How to Use Routine Parameters
objects, passing, How to Use Routine Parameters
order for, How Long Can a Routine Be?
out keyword creation, How to Use Routine Parameters
passing, types of, C++-Pointer Pointers
refactoring, Reasons Not to Refactor, Statement-Level Refactorings
status, How to Use Routine Parameters
structures as, Structures
using all of rule, How to Use Routine Parameters
variables, using as, How to Use Routine Parameters
Visual Basic, How to Use Routine Parameters
parentheses, Using Parentheses to Clarify Boolean Expressions, Parentheses
balancing technique, Using Parentheses to Clarify Boolean Expressions
layout with, Parentheses
Pareto Principle, Introduction to Code Tuning
passing parameters, C++-Pointer Pointers
patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Look for Common Design Patterns, Software Design, General
advantages of, Look for Common Design Patterns (see )
alternatives suggested by, Look for Common Design Patterns
communications benefit, Look for Common Design Patterns
complexity reduction with, Look for Common Design Patterns
disadvantages of, Look for Common Design Patterns
error reduction benefit, Look for Common Design Patterns
Factory Method, Look for Common Design Patterns
resource for, Software Design, General
table of, Look for Common Design Patterns
people first theme, Techniques for Encouraging Good Coding
performance appraisals, Roles During an Inspection
performance tuning, Performance, Barriers to Information Hiding, Valid Reasons to Create a Routine, Design the Routine, Code-Tuning Strategies, Performance Overview, Performance Overview, Performance and Code Tuning, Performance and Code Tuning, Program Design, Program Design, Program Design, Program Design, Program Design, Hardware, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Old Wives' Tales, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Common Sources of Inefficiency, Relative Performance Costs of Common Operations, Relative Performance Costs of Common Operations, Measurement, Iteration, Iteration, Iteration, Iteration, Performance, Algorithms and Data Types, Recoding in a Low-Level Language, Commenting Efficiently, Pick Your Process
algorithm choice, Program Design
architecture prerequisites, Performance
arrays, Old Wives' Tales, Relative Performance Costs of Common Operations
checklist, Performance
comments, effects on, Commenting Efficiently
competing objectives dilemma, Old Wives' Tales, Iteration
compiler considerations, Program Design, Old Wives' Tales
correctness, importance of, Old Wives' Tales
database indexing, Common Sources of Inefficiency
defects in code, Common Sources of Inefficiency
DES example, Iteration
design view, Performance and Code Tuning
feature specific, Old Wives' Tales
hardware considerations, Hardware
inefficiency, sources of, Common Sources of Inefficiency
information hiding considerations of, Barriers to Information Hiding
input/output, Common Sources of Inefficiency
interpreted vs. compiled languages, Common Sources of Inefficiency
key points, Algorithms and Data Types
lines of code, minimizing number of, Old Wives' Tales
measurement of, Relative Performance Costs of Common Operations
memory vs. file operations, Common Sources of Inefficiency
old wives' tales, Old Wives' Tales
operating system considerations, Program Design
operations, costs of common, Common Sources of Inefficiency
overview of, Recoding in a Low-Level Language
paging operations, Common Sources of Inefficiency
premature optimization, Pick Your Process
program requirements view of, Performance and Code Tuning
purpose of, Code-Tuning Strategies
quality of code, impact on, Performance Overview
resource goals, Program Design
resources, Iteration
routine design, Valid Reasons to Create a Routine, Design the Routine, Program Design
speed, importance of, Old Wives' Tales
summary of approach for, Iteration
system calls, Common Sources of Inefficiency
timing issues, Measurement
user view of coding, Performance Overview
when to tune, Old Wives' Tales
periodicals on programming, Lowbrow Programmer Magazines
Perl, Java
persistence of variables, Comments on Minimizing Scope, Persistence
personal character, Curiosity
perturbers, Symbolic Debuggers
phased integration, Importance of the Integration Approach
phonic abbreviations of names, Phonetic Abbreviations
PHP (PHP Hypertext Processor), Java, Common Sources of Inefficiency
physical environment for programmers, Religious Issues
planning, Software Construction: Building Software, Causes of Incomplete Preparation, Causes of Incomplete Preparation, Appeal to Analogy, Boss-Readiness Test
analogy argument for, Causes of Incomplete Preparation
building metaphor for, Software Construction: Building Software
data arguing for, Appeal to Analogy
good practices table for, Boss-Readiness Test
logical argument for, Causes of Incomplete Preparation
pointers, Valid Reasons to Create a Routine, When to Use a Function and When to Use a Procedure, Plan to Remove Debugging Aids, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Characters and Strings, Structures, Structures, Structures, Structures, Structures, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, Knowledge of How to Interpret the Contents, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers, C++-Pointer Pointers, C++-Pointer Pointers, C++-Pointer Pointers, C++-Pointer Pointers, C++-Pointer Pointers, C++-Pointer Pointers, C++-Pointer Pointers, C++-Pointer Pointers, C-Pointer Pointers, How to Reduce the Risks of Using Global Data, Additional Resources, Additional Resources, Writing Numeric Expressions in Number-Line Order, Symbolic Debuggers, Laying Out Data Declarations, Laying Out Data Declarations, Watch for Falling Rocks
& (pointer reference symbol), General Tips on Pointers
* (pointer declaration symbol), General Tips on Pointers, C++-Pointer Pointers, Laying Out Data Declarations (see )
address of, Structures, General Tips on Pointers
allocation of, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers
alternatives to, General Tips on Pointers
as function return values, When to Use a Function and When to Use a Procedure
asterisk (*) rule, C++-Pointer Pointers
auto_ptrs, C++-Pointer Pointers
bounds checking tools, Symbolic Debuggers
C language, C++-Pointer Pointers
C++ examples, Knowledge of How to Interpret the Contents, General Tips on Pointers
C++ guidelines, General Tips on Pointers
checking before using, General Tips on Pointers, General Tips on Pointers
checklist for, Additional Resources
comparisons with, Writing Numeric Expressions in Number-Line Order
contents, interpretation of, Knowledge of How to Interpret the Contents
cover routines for, General Tips on Pointers
dangers of, Structures, Knowledge of How to Interpret the Contents
data types pointed to, Knowledge of How to Interpret the Contents
deallocation of, General Tips on Pointers, General Tips on Pointers, General Tips on Pointers
debugging aids, Plan to Remove Debugging Aids
declaring, Knowledge of How to Interpret the Contents, Laying Out Data Declarations
deleting, General Tips on Pointers, General Tips on Pointers
diagramming, General Tips on Pointers
dog tag fields, General Tips on Pointers
explicit typing of, C++-Pointer Pointers
explicitly redundant fields, General Tips on Pointers
extra variables for clarity, General Tips on Pointers
hiding operations with routines, Valid Reasons to Create a Routine
initializing, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Knowledge of How to Interpret the Contents
interpretation of address contents, Knowledge of How to Interpret the Contents
isolating operations of, Knowledge of How to Interpret the Contents
key points, Additional Resources
languages not providing, Structures
linked lists, deleting in, General Tips on Pointers
location in memory, Structures
memory corruption by, Knowledge of How to Interpret the Contents
memory parachutes, General Tips on Pointers
null, setting to after deleting, General Tips on Pointers
null, using as warnings, Watch for Falling Rocks
overwriting memory with junk, General Tips on Pointers
parts of, Structures
passing by reference, C++-Pointer Pointers
references, C++, General Tips on Pointers
resources for, How to Reduce the Risks of Using Global Data
SAFE_ routines for, General Tips on Pointers
simplifying complicated expressions, General Tips on Pointers
sizeof(), C-Pointer Pointers
smart, C++-Pointer Pointers
string operations in C, Characters and Strings
type casting, avoiding, C++-Pointer Pointers
variables referenced by, checking, General Tips on Pointers
–> (pointer symbol), General Tips on Pointers
polymorphism, Inherit—When Inheritance Simplifies the Design, Inheritance ("is a" Relationships), Summary of Reasons to Create a Class, Taming Dangerously Deep Nesting
case statements, replacing with, Inheritance ("is a" Relationships) (see )
defined, Inherit—When Inheritance Simplifies the Design
language-specific rules, Summary of Reasons to Create a Class
nested ifs, converting to, Taming Dangerously Deep Nesting
polynomial expressions, Use Strength Reduction
portability, Valid Reasons to Create a Routine, Why Are the Examples of Creating Your Own Types in Pascal and Ada?, Characteristics of Software Quality
data types, defining for, Why Are the Examples of Creating Your Own Types in Pascal and Ada?
defined, Characteristics of Software Quality
routines for, Valid Reasons to Create a Routine
postconditions, Guidelines for Using Assertions, Design the Routine
routine design with, Design the Routine
verification, Guidelines for Using Assertions
PPP (Pseudocode Programming Process), Pseudocode for Pros, Pseudocode for Pros, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Code the Routine, Code the Routine, Code the Routine, Code the Routine, Check the Code, Check the Code, Check the Code, Check the Code, Clean Up Leftovers, Clean Up Leftovers, Clean Up Leftovers, Alternatives to the PPP, Alternatives to the PPP
algorithms, researching, Design the Routine (see )
alternates to, Clean Up Leftovers
checking for errors, Check the Code
checklist for, Alternatives to the PPP
cleanup steps, Clean Up Leftovers
coding below comments, Code the Routine
coding routines from, Design the Routine
data structure for routines, Design the Routine
declarations from, Code the Routine
defined, Pseudocode for Pros
designing routines, Pseudocode for Pros
error handling considerations, Design the Routine
example for routines, Design the Routine
functionality from libraries, Design the Routine
header comments for routines, Design the Routine
high-level comments from, Code the Routine
iterating, Design the Routine
key points for, Alternatives to the PPP
naming routines, Design the Routine
performance considerations, Design the Routine
prerequisites, Design the Routine
problem definition, Design the Routine
refactoring, Code the Routine
removing errors, Check the Code
repeating steps, Clean Up Leftovers
reviewing pseudocode, Design the Routine
stepping through code, Check the Code
testing the code, Design the Routine, Check the Code
writing pseudocode step, Design the Routine
precedence, misleading, Human and Computer Interpretations of a Program
preconditions, Guidelines for Using Assertions, Design the Routine
routine design with, Design the Routine
verification, Guidelines for Using Assertions
prefixes, standardization of, Standardized Prefixes
premature optimization, Pick Your Process
preparation, Causes of Incomplete Preparation
preprocessors, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Plan to Remove Debugging Aids, Code-Generation Wizards
C++, Plan to Remove Debugging Aids
debugging aids, removing with, Plan to Remove Debugging Aids
purpose of, Code-Generation Wizards
writing, Plan to Remove Debugging Aids
prerequisites, upstream, Measure Twice, Cut Once: Upstream Prerequisites, Do Prerequisites Apply to Modern Software Projects?, Do Prerequisites Apply to Modern Software Projects?, Do Prerequisites Apply to Modern Software Projects?, Do Prerequisites Apply to Modern Software Projects?, Do Prerequisites Apply to Modern Software Projects?, Causes of Incomplete Preparation, Causes of Incomplete Preparation, Causes of Incomplete Preparation, Causes of Incomplete Preparation, Causes of Incomplete Preparation, Causes of Incomplete Preparation, Appeal to Analogy, Appeal to Analogy, Appeal to Data, Appeal to Data, Boss-Readiness Test, Boss-Readiness Test, Determine the Kind of Software You're Working On, Iterative Approaches' Effect on Prerequisites, Choosing Between Iterative and Sequential Approaches, Choosing Between Iterative and Sequential Approaches, General Architectural Quality, General Software-Development Approaches, General Software-Development Approaches
analogy argument for, Causes of Incomplete Preparation (see )
boss readiness test, Appeal to Data
checklist for, General Software-Development Approaches
choosing between iterative and sequential approaches, Choosing Between Iterative and Sequential Approaches
coding too early mistake, Do Prerequisites Apply to Modern Software Projects?
compelling argument for, Causes of Incomplete Preparation
data arguing for, Appeal to Analogy
error detection, doing early, Appeal to Data
goal of, Do Prerequisites Apply to Modern Software Projects?
good practices table for, Boss-Readiness Test
importance of, Measure Twice, Cut Once: Upstream Prerequisites
incomplete preparation, causes of, Do Prerequisites Apply to Modern Software Projects?
iterative and sequential mixes, Iterative Approaches' Effect on Prerequisites
iterative methods with, Appeal to Analogy, Determine the Kind of Software You're Working On
key points for, General Software-Development Approaches
kinds of projects, Boss-Readiness Test
logical argument for, Causes of Incomplete Preparation
manager ignorance problem, Causes of Incomplete Preparation
problem definition, Choosing Between Iterative and Sequential Approaches
risk reduction goal, Do Prerequisites Apply to Modern Software Projects?
skills required for success, Do Prerequisites Apply to Modern Software Projects?
time allowed for, General Architectural Quality
WIMP syndrome, Causes of Incomplete Preparation
WISCA syndrome, Causes of Incomplete Preparation
Principle of Proximity, Guidelines for Initializing Variables, Statements Whose Order Doesn't Matter
private data, Inheritance ("is a" Relationships)
problem domain, programming at, Focus Your Attention with the Help of Conventions
problem-definition prerequisites, Choosing Between Iterative and Sequential Approaches
problem-solving skills development, Curiosity
procedural cohesion, Design at the Routine Level
procedures, Inheritance ("is a" Relationships), Good Routine Names, Special Considerations in the Use of Functions
naming guidelines for, Good Routine Names
when to use, Special Considerations in the Use of Functions
processes, development, General Software-Development Approaches
productivity, Why Is Software Construction Important?, The General Principle of Software Quality, Effect of Project Size on Errors
effects of good construction practice, Why Is Software Construction Important?
industry average, The General Principle of Software Quality
size of projects, effects on, Effect of Project Size on Errors
professional development, Curiosity
professional organizations, Professional Level
program flow, Grouping Related Statements, Other Kinds of Complexity
control of, Other Kinds of Complexity
sequential, Grouping Related Statements
program organization prerequisite, Typical Architectural Components
program size, Activity Proportions and Size
programmers, character of, Curiosity
programmers, treatment of, Additional Resources on Software Measurement, How Do Programmers Spend Their Time?, How Do Programmers Spend Their Time?, Team Variation, Team Variation, Religious Issues, Religious Issues, Physical Environment, Daily Build and Smoke Test
overview, Additional Resources on Software Measurement
physical environment, Religious Issues
privacy of offices, Religious Issues
religious issues, Team Variation
resources on, Physical Environment
style issues, Team Variation
time allocations, How Do Programmers Spend Their Time?
variations in performance, How Do Programmers Spend Their Time?
programming conventions, Visual Basic, Example of Programming into a Language
choosing, Visual Basic
coding practices checklist, Example of Programming into a Language
programming into languages, Your Location on the Technology Wave, Write Programs for People First, Computers Second
programming language choice, Key Construction Decisions, Choice of Programming Language, Choice of Programming Language, Choice of Programming Language, Choice of Programming Language, Choice of Programming Language, Choice of Programming Language, Choice of Programming Language, Choice of Programming Language, C, C, C, C, C, Java, Java, Java, Java, Java, Java, Java, Java, Your Location on the Technology Wave, Write Programs for People First, Computers Second
Ada, Choice of Programming Language (see )
assembly language, Choice of Programming Language
Basic, Java
C, C
C#, C
C++, C
Cobol, C
expressiveness of concepts, Choice of Programming Language
familiar vs. unfamiliar languages, Choice of Programming Language
Fortran, C
higher- vs. lower-level language productivity, Choice of Programming Language
importance of, Key Construction Decisions
Java, Java
JavaScript, Java
Perl, Java
PHP, Java
productivity from, Choice of Programming Language
programming into languages, Your Location on the Technology Wave, Write Programs for People First, Computers Second
Python, Java
ratio of statements compared to C code, table of, Choice of Programming Language
SQL, Java
thinking, effects on, Choice of Programming Language
Visual Basic, Java
programming tools, Coverage Monitors, Tips for Finding Defects, Execution Profilers, Programming Tools, Programming Tools, Programming Tools, Programming Tools, Programming Tools, Programming Tools, Programming Tools, Integrated Development Environments (IDEs), Integrated Development Environments (IDEs), Multiple-File String Searching and Replacing, Multiple-File String Searching and Replacing, Multiple-File String Searching and Replacing, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Picky Syntax and Semantics Checkers, Picky Syntax and Semantics Checkers, Restructurers, Restructurers, Restructurers, Restructurers, Executable-Code Tools, Executable-Code Tools, Executable-Code Tools, Executable-Code Tools, Executable-Code Tools, Build Tools, Code-Generation Wizards, Code-Generation Wizards, Preprocessors, Preprocessors, Code Tuning, Code Tuning, Code Tuning, Code Tuning, Code Tuning, Tool-Oriented Environments, Tool-Oriented Environments, Project-Specific Tools, Project-Specific Tools, Additional Resources, Additional Resources, Additional Resources
assembler listing tools, Code Tuning (see ; )
beautifiers, Multiple-File String Searching and Replacing
build tools, Executable-Code Tools
building your own, Tool-Oriented Environments
CASE tools, Programming Tools
checklist, Additional Resources
class-hierarchy generators, Interface Documentation Tools
code libraries, Build Tools
code tuning, Code Tuning
code-generation wizards, Code-Generation Wizards
compilers, Executable-Code Tools
cross-reference tools, Interface Documentation Tools
data dictionaries, Restructurers
debugging tools, Coverage Monitors, Tips for Finding Defects, Execution Profilers, Preprocessors
dependency checkers, Executable-Code Tools
design tools, Programming Tools
Diff tools, Multiple-File String Searching and Replacing
disassemblers, Code Tuning
editing tools, Programming Tools
executable-code tools, Executable-Code Tools
execution profiler tools, Code Tuning
fantasyland, Project-Specific Tools
graphical design tools, Programming Tools
grep, Integrated Development Environments (IDEs)
IDEs, Programming Tools
interface documentation, Interface Documentation Tools
key points, Additional Resources
linkers, Executable-Code Tools
merge tools, Multiple-File String Searching and Replacing
metrics reporters, Picky Syntax and Semantics Checkers
multiple-file string searches, Integrated Development Environments (IDEs)
preprocessors, Code-Generation Wizards
project-specific tools, Tool-Oriented Environments
purpose of, Programming Tools
quality analysis, Interface Documentation Tools
refactoring tools, Picky Syntax and Semantics Checkers
resources on, Additional Resources
restructuring tools, Restructurers
scripts, Project-Specific Tools
semantics checkers, Interface Documentation Tools
source-code tools, Programming Tools
syntax checkers, Interface Documentation Tools
templates, Interface Documentation Tools
testing tools, Preprocessors
tool-oriented environments, Code Tuning
translators, Restructurers
version control tools, Restructurers
project types, prerequisites corresponding to, Boss-Readiness Test
protected data, Inheritance ("is a" Relationships)
prototyping, Experimental Prototyping, Development Process
Proximity, Principle of, Guidelines for Initializing Variables, Statements Whose Order Doesn't Matter
pseudocode, Summary of Steps in Building Classes and Routines, Steps in Creating a Class, Pseudocode for Pros, Pseudocode for Pros, Pseudocode for Pros, Pseudocode for Pros, Pseudocode for Pros, Pseudocode for Pros, Pseudocode for Pros, Pseudocode for Pros, Pseudocode for Pros, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Code the Routine, Code the Routine, Code the Routine, Code the Routine, Check the Code, Alternatives to the PPP, Alternatives to the PPP, How Long Should a Loop Be?, Commenting Efficiently
algorithms, researching, Design the Routine
bad, example of, Pseudocode for Pros
benefits from, Pseudocode for Pros
changing, efficiency of, Pseudocode for Pros
checking for errors, Check the Code
checklist for PPP, Alternatives to the PPP
classes, steps in creating, Summary of Steps in Building Classes and Routines
coding below comments, Code the Routine
coding from, Design the Routine
comments from, Pseudocode for Pros, Commenting Efficiently
data structure for routines, Design the Routine
declarations from, Code the Routine
defined, Pseudocode for Pros
designing routines, Pseudocode for Pros
error handling considerations, Design the Routine
example for routines, Design the Routine
functionality from libraries, Design the Routine
good, example of, Pseudocode for Pros
guidelines for effective use, Pseudocode for Pros
header comments for routines, Design the Routine
high-level comments from, Code the Routine
iterative refinement, Pseudocode for Pros, Design the Routine
key points for creating, Alternatives to the PPP
loop design, How Long Should a Loop Be?
naming routines, Design the Routine
performance considerations, Design the Routine
prerequisites, Design the Routine
problem definition, Design the Routine
refactoring, Code the Routine
reviewing, Design the Routine
routines, steps in creating, Steps in Creating a Class, Design the Routine
testing, planning for, Design the Routine
Pseudocode Programming Process, Design the Routine
psychological distance, How "Psychological Distance" Can Help
psychological factors, Curiosity
psychological set, Fixing a Defect
public data members, Reasons to Refactor
pure blocks layout style, Parentheses
Python, Java, Common Sources of Inefficiency
description of, Java
performance issues, Common Sources of Inefficiency

Q

quality assurance, Measure Twice, Cut Once: Upstream Prerequisites, Boss-Readiness Test, Handling Requirements Changes During Construction, Selection of Major Construction Practices, Characteristics of Software Quality
checklist, Selection of Major Construction Practices
good practices table for, Boss-Readiness Test
prerequisites role in, Measure Twice, Cut Once: Upstream Prerequisites
requirements checklist, Handling Requirements Changes During Construction
quality gates, Techniques for Improving Software Quality
quality of software, The Software-Quality Landscape, The Software-Quality Landscape, The Software-Quality Landscape, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Characteristics of Software Quality, Techniques for Improving Software Quality, Techniques for Improving Software Quality, Techniques for Improving Software Quality, Techniques for Improving Software Quality, Techniques for Improving Software Quality, Techniques for Improving Software Quality, Techniques for Improving Software Quality, Techniques for Improving Software Quality, Development Process, Development Process, Development Process, Development Process, Development Process, Setting Objectives, Percentage of Defects Detected, Percentage of Defects Detected, Percentage of Defects Detected, Cost of Finding Defects, Cost of Finding Defects, Cost of Fixing Defects, Cost of Fixing Defects, The General Principle of Software Quality, The General Principle of Software Quality, The General Principle of Software Quality, The General Principle of Software Quality, Relevant Standards, Relevant Standards, Developer Testing, Overview of Debugging Issues, Software Quality-Assurance Standards
accuracy, Characteristics of Software Quality (see )
adaptability, Characteristics of Software Quality
change-control procedures, Development Process
checklist for, The General Principle of Software Quality
correctness, The Software-Quality Landscape
costs of finding defects, Cost of Finding Defects
costs of fixing defects, Cost of Finding Defects
debugging, role of, The General Principle of Software Quality, Overview of Debugging Issues
detection of defects by various techniques, table of, Percentage of Defects Detected
development process assurance activities, Techniques for Improving Software Quality
efficiency, Characteristics of Software Quality
engineering guidelines, Techniques for Improving Software Quality
explicit activity for, Techniques for Improving Software Quality
external audits, Techniques for Improving Software Quality
external characteristics of, The Software-Quality Landscape
Extreme Programming, Percentage of Defects Detected
flexibility, Characteristics of Software Quality
gates, Techniques for Improving Software Quality
General Principle of Software Quality, The General Principle of Software Quality
integrity, Characteristics of Software Quality
internal characteristics, Characteristics of Software Quality
key points, Relevant Standards
maintainability, Characteristics of Software Quality
measurement of results, Development Process
multiple defect detection techniques recommended, Percentage of Defects Detected
objectives, setting, Techniques for Improving Software Quality, Development Process
optimization conflicts, Characteristics of Software Quality
percentage of defects measurement, Setting Objectives
portability, Characteristics of Software Quality
programmer performance, objectives based, Development Process
prototyping, Development Process
readability, Characteristics of Software Quality
recommended combination for, Cost of Fixing Defects
relationships of characteristics, Characteristics of Software Quality
reliability, Characteristics of Software Quality
resources for, The General Principle of Software Quality
reusability, Characteristics of Software Quality
reviews, Techniques for Improving Software Quality
robustness, Characteristics of Software Quality
standards, IEEE, Relevant Standards, Software Quality-Assurance Standards
testing, Characteristics of Software Quality, Techniques for Improving Software Quality, Developer Testing
understandability, Characteristics of Software Quality
usability, The Software-Quality Landscape
when to do assurance of, Cost of Fixing Defects

R

random-data generators, Test-Data Generators
readability, Common Software Metaphors, Characteristics of Software Quality, Defects as Opportunities, Techniques for Encouraging Good Coding, Human and Computer Interpretations of a Program, Curiosity, Pick Your Process, Pick Your Process, Write Programs for People First, Computers Second, Write Programs for People First, Computers Second, Watch for Falling Rocks
as management standard, Techniques for Encouraging Good Coding
defects exposing lack of, Defects as Opportunities
defined, Characteristics of Software Quality
importance of, Common Software Metaphors, Pick Your Process
maintenance benefit from, Write Programs for People First, Computers Second
positive effects from, Pick Your Process
private vs. public programs, Write Programs for People First, Computers Second
professional development, importance to, Curiosity
structures, importance of, Human and Computer Interpretations of a Program
warning sign, as a, Watch for Falling Rocks
reading as a skill, Curiosity
reading plan for software developers, Special-Interest Publications
records, refactoring, Data-Level Refactorings
recursion, Multiple Returns from a Routine, Multiple Returns from a Routine, Recursion, Recursion, Example of Recursion, Example of Recursion, Example of Recursion, Tips for Using Recursion, Tips for Using Recursion, Tips for Using Recursion, Tips for Using Recursion, gotos, gotos
alternatives to, Tips for Using Recursion (see )
checklist, gotos
defined, Multiple Returns from a Routine
factorials using, Tips for Using Recursion
Fibonacci numbers using, Tips for Using Recursion
guidelines for, Recursion
key points, gotos
maze example, Recursion
safety counters for, Example of Recursion
single routine guideline, Example of Recursion
sorting example, Multiple Returns from a Routine
stack space concerns, Tips for Using Recursion
terminating, Example of Recursion
refactoring, Code the Routine, Philosophy of Software Evolution, Philosophy of Software Evolution, Philosophy of Software Evolution, Philosophy of Software Evolution, Philosophy of Software Evolution, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons Not to Refactor, Reasons Not to Refactor, Reasons Not to Refactor, Reasons Not to Refactor, Reasons Not to Refactor, Reasons Not to Refactor, Data-Level Refactorings, Data-Level Refactorings, Data-Level Refactorings, Data-Level Refactorings, Data-Level Refactorings, Data-Level Refactorings, Statement-Level Refactorings, Statement-Level Refactorings, Statement-Level Refactorings, Statement-Level Refactorings, Statement-Level Refactorings, Statement-Level Refactorings, Statement-Level Refactorings, Statement-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Class Implementation Refactorings, Class Implementation Refactorings, Class Implementation Refactorings, Class Implementation Refactorings, Class Interface Refactorings, Class Interface Refactorings, Class Interface Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, System-Level Refactorings, Refactoring Safely, Refactoring Safely, Refactoring Safely, Refactoring Safely, Refactoring Safely, Refactoring Safely, Refactoring Safely, Refactoring Safely, Refactoring Safely, Refactoring Safely, Bad Times to Refactor, Bad Times to Refactor, Bad Times to Refactor, Bad Times to Refactor, Bad Times to Refactor, Bad Times to Refactor, Bad Times to Refactor, Bad Times to Refactor, Bad Times to Refactor, Refactoring Strategies, Refactoring Strategies, Refactoring Strategies, Refactoring Strategies, Additional Resources, Additional Resources, Code-Tuning Techniques, Picky Syntax and Semantics Checkers
80/20 rule, Bad Times to Refactor
adding routines, Bad Times to Refactor
algorithms, Statement-Level Refactorings
arrays, Data-Level Refactorings
backing up old code, System-Level Refactorings
bidirectional class associations, System-Level Refactorings
boolean expressions, Data-Level Refactorings
case statements, Statement-Level Refactorings
checklists for, Reasons to Refactor, System-Level Refactorings
checkpoints for, Refactoring Safely
class cohesion indicator, Reasons to Refactor
class interfaces, Class Implementation Refactorings
classes, Reasons to Refactor, Routine-Level Refactorings, System-Level Refactorings, Bad Times to Refactor
code tuning, compared to, Code-Tuning Techniques
collections, Data-Level Refactorings
comments on bad code, Reasons to Refactor
complex modules, Refactoring Strategies
conditional expressions, Statement-Level Refactorings
constant values varying among subclass, Routine-Level Refactorings
constructors to factory methods, System-Level Refactorings
data from uncontrolled sources, Class Interface Refactorings
data sets, related, as indicator, Reasons to Refactor
data types to classes, Data-Level Refactorings
data-level, Reasons Not to Refactor, System-Level Refactorings
defects, fixes of, Bad Times to Refactor
defined, Philosophy of Software Evolution
designing code for future needs, Reasons to Refactor
Don't Repeat Yourself principle, Philosophy of Software Evolution
duplicate code indicator, Philosophy of Software Evolution
error-prone modules, Bad Times to Refactor
expressions, Reasons Not to Refactor
global variables, Reasons to Refactor
GUI data, Class Interface Refactorings
if statements, Statement-Level Refactorings
interfaces, Reasons to Refactor, Class Implementation Refactorings, System-Level Refactorings
key points, Additional Resources
listing planned steps, Refactoring Safely
literal constants, Reasons Not to Refactor
loops, Philosophy of Software Evolution, Statement-Level Refactorings
maintenance triggering, Refactoring Strategies
middleman classes, Reasons to Refactor
misuse of, Bad Times to Refactor
null objects, Statement-Level Refactorings
objects, Routine-Level Refactorings
one-at-a-time rule, Refactoring Safely
overloaded primitive data types, Reasons to Refactor
parallel modifications required indicator, Reasons to Refactor
parameters, Reasons to Refactor, Reasons Not to Refactor, Statement-Level Refactorings
PPP coding step, Code the Routine
public data members, Reasons to Refactor
queries, Routine-Level Refactorings
reasons not to, Reasons Not to Refactor
records, Data-Level Refactorings
redesigning instead of, Bad Times to Refactor
reference objects, Routine-Level Refactorings
resources on, Additional Resources
reviews of, Refactoring Safely
risk levels of, Refactoring Safely
routines, Philosophy of Software Evolution, Statement-Level Refactorings, System-Level Refactorings, Bad Times to Refactor
safety guidelines, System-Level Refactorings, Refactoring Strategies
setup code, Reasons to Refactor
size guideline, Refactoring Safely
statement-level, Data-Level Refactorings, System-Level Refactorings
strategies for, Bad Times to Refactor
subclasses, Reasons to Refactor, Class Implementation Refactorings
superclasses, Class Implementation Refactorings
system-level, Class Interface Refactorings, System-Level Refactorings
takedown code, Reasons to Refactor
testing, Refactoring Safely
to do lists for, Refactoring Safely
tools for, Picky Syntax and Semantics Checkers
tramp data, Reasons to Refactor
ugly code, interfaces to, Refactoring Strategies
unidirectional class associations, System-Level Refactorings
unit tests for, Refactoring Safely
variables, Reasons Not to Refactor
warnings, compiler, Refactoring Safely
references (&), C++, General Tips on Pointers
regression testing, Developer Testing, Building Scaffolding to Test Individual Classes, Improving Your Testing
defined, Developer Testing
diff tools for, Building Scaffolding to Test Individual Classes
purpose of, Improving Your Testing
reliability, Design at the Routine Level, Characteristics of Software Quality
cohesive routines, Design at the Routine Level
defined, Characteristics of Software Quality
religious attitude toward programming, Team Variation, Layout as Religion, Iterate, Repeatedly, Again and Again, Iterate, Repeatedly, Again and Again, Iterate, Repeatedly, Again and Again, Eclecticism
eclecticism, Iterate, Repeatedly, Again and Again
experimentation compared to, Eclecticism
harmful effects of, Iterate, Repeatedly, Again and Again
layout styles becoming, Layout as Religion
managing people, Team Variation
software oracles, Iterate, Repeatedly, Again and Again
reports, What Results Can You Expect from Inspections?
requirements, Causes of Incomplete Preparation, Boss-Readiness Test, Problem-Definition Prerequisite, Problem-Definition Prerequisite, Problem-Definition Prerequisite, Problem-Definition Prerequisite, Why Have Official Requirements?, The Myth of Stable Requirements, The Myth of Stable Requirements, The Myth of Stable Requirements, The Myth of Stable Requirements, Handling Requirements Changes During Construction, Handling Requirements Changes During Construction, Handling Requirements Changes During Construction, Handling Requirements Changes During Construction, Handling Requirements Changes During Construction, Handling Requirements Changes During Construction, Handling Requirements Changes During Construction, Handling Requirements Changes During Construction, General Architectural Quality, Amount of Time to Spend on Upstream Prerequisites, Key Points, Testing During Construction, Refactoring, Performance and Code Tuning, Techniques for Encouraging Good Coding, Requirements and Design Changes, Pick Your Process
benefits of, Problem-Definition Prerequisite (see )
business cases for, Handling Requirements Changes During Construction
change-control procedures, The Myth of Stable Requirements
checklists for, The Myth of Stable Requirements, Handling Requirements Changes During Construction
coding without, Causes of Incomplete Preparation
communicating changes in, The Myth of Stable Requirements
completeness, checklist, Handling Requirements Changes During Construction
configuration management of, Techniques for Encouraging Good Coding, Requirements and Design Changes
defined, Problem-Definition Prerequisite
development approaches with, Handling Requirements Changes During Construction
development process effects on, The Myth of Stable Requirements
dumping projects, Handling Requirements Changes During Construction
errors in, effects of, Problem-Definition Prerequisite
functional, checklist, Handling Requirements Changes During Construction
good practices table for, Boss-Readiness Test
importance of, Problem-Definition Prerequisite
key point for, Key Points
nonfunctional, checklist, Handling Requirements Changes During Construction
performance tuning, Performance and Code Tuning
quality, checklist, Handling Requirements Changes During Construction
rate of change, typical, Refactoring
resources on developing, Amount of Time to Spend on Upstream Prerequisites
stability of, Why Have Official Requirements?, Pick Your Process
testing for, Testing During Construction
time allowed for, General Architectural Quality
resource management, Business Rules, The Phony goto Debate
architecture for, Business Rules
cleanup example, The Phony goto Debate
restrictive nature of design, Design Is a Sloppy Process (Even If it Produces a Tidy Result)
restructuring tools, Restructurers
retesting, Building Scaffolding to Test Individual Classes
return statements, Unusual Control Structures, Unusual Control Structures, Multiple Returns from a Routine, Summary of Guidelines for Using gotos, gotos, gotos
checklist, gotos (see )
guard clauses, Multiple Returns from a Routine
key points, gotos
multiple, from one routine, Unusual Control Structures
readability, Unusual Control Structures
resources for, Summary of Guidelines for Using gotos
reusability, Reuse Decisions, Characteristics of Software Quality
architecture prerequisites, Reuse Decisions
defined, Characteristics of Software Quality
reviewer role in inspections, What Results Can You Expect from Inspections?
reviews, Techniques for Improving Software Quality, Techniques for Improving Software Quality, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise, Formal Inspections, Inspection Summary, Code Reading, Dog-and-Pony Shows, Refactoring Safely, Techniques for Encouraging Good Coding, Watch for Falling Rocks
code reading, Code Reading
dog-and-pony shows, Dog-and-Pony Shows
educational aspect of, Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise
every line of code rule, Techniques for Encouraging Good Coding
formal inspections, compared to, Formal Inspections
formal, quality from, Techniques for Improving Software Quality
informal, defined, Techniques for Improving Software Quality
iteration process, place in, Watch for Falling Rocks
refactoring conducting after, Refactoring Safely
walk-throughs, Inspection Summary
right shifting, Be Wary of System Routines
risk-oriented integration, Sandwich Integration
robustness, Architectural Feasibility, Guidelines for Using Assertions, Robustness vs. Correctness, Robustness vs. Correctness, Characteristics of Software Quality
architecture prerequisites, Architectural Feasibility
assertions with error handling, Guidelines for Using Assertions
correctness, balanced against, Robustness vs. Correctness
defined, Robustness vs. Correctness, Characteristics of Software Quality
rounding errors, Floating-Point Numbers
routines, Level 3: Division into Classes, Level 5: Internal Routine Design, Keep Coupling Loose, Good Encapsulation, Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Inheritance ("is a" Relationships), Summary of Reasons to Create a Class, High-Quality Routines, High-Quality Routines, High-Quality Routines, High-Quality Routines, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Valid Reasons to Create a Routine, Operations That Seem Too Simple to Put Into Routines, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Design at the Routine Level, Good Routine Names, Good Routine Names, Good Routine Names, Good Routine Names, How Long Can a Routine Be?, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, How to Use Routine Parameters, Special Considerations in the Use of Functions, Macro Routines and Inline Routines, Inline Routines, Key Points, Steps in Creating a Class, Pseudocode for Pros, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Design the Routine, Code the Routine, Code the Routine, Code the Routine, Code the Routine, Check the Code, Check the Code, Check the Code, Check the Code, Check the Code, Check the Code, Clean Up Leftovers, Clean Up Leftovers, Clean Up Leftovers, Alternatives to the PPP, Alternatives to the PPP, Alternatives to the PPP, Alternatives to the PPP, Alternatives to the PPP, Informal Naming Conventions, Sample Naming Conventions, Unusual Control Structures, Unusual Control Structures, How to Measure Complexity, Role of Developer Testing in Software Quality, Structured Basis Testing, Test-Support Tools, Philosophy of Software Evolution, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Reasons to Refactor, Statement-Level Refactorings, Statement-Level Refactorings, Statement-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Routine-Level Refactorings, Class Interface Refactorings, System-Level Refactorings, Bad Times to Refactor, Common Sources of Inefficiency, Eliminate Common Subexpressions, Using Spaces for Clarity, Formatting Continuation Lines, Laying Out Comments, Laying Out Comments, Laying Out Comments, Laying Out Routines, Laying Out Files and Programs, Laying Out Files and Programs, Programming Style as Documentation, Programming Style as Documentation, Commenting Control Structures, Commenting Routines, Additional Resources
abstract overridable, Inheritance ("is a" Relationships) (see ; ; ; )
abstraction benefit, Valid Reasons to Create a Routine
abstraction with object parameters, How to Use Routine Parameters, Routine-Level Refactorings
algorithm selection for, Design the Routine, Statement-Level Refactorings
alternates to PPP, Clean Up Leftovers
black-box testing of, Role of Developer Testing in Software Quality
blank lines in, Laying Out Comments
boolean test benefit, Valid Reasons to Create a Routine
calculation to function example, Valid Reasons to Create a Routine
calls, costs of, Common Sources of Inefficiency
checking for errors, Check the Code
checklists, Inline Routines, Laying Out Files and Programs, Programming Style as Documentation
classes, converting to, criteria for, Statement-Level Refactorings
cleanup steps, Clean Up Leftovers
code tuning, Eliminate Common Subexpressions
coding from pseudocode, Design the Routine
cohesion, Design at the Routine Level
coincidental cohesion, Design at the Routine Level
commenting, Commenting Control Structures, Additional Resources
communicational cohesion, Design at the Routine Level
compiling for errors, Check the Code
complexity metric, How to Measure Complexity
complexity reduction benefit, Valid Reasons to Create a Routine
construction step for classes, Steps in Creating a Class
continuations in call lines, Formatting Continuation Lines
coupling considerations, Keep Coupling Loose
data states, Structured Basis Testing
data structures for, Design the Routine
declarations, Code the Routine
defined, High-Quality Routines
descriptiveness guideline for naming, Design at the Routine Level
design by contract, Alternatives to the PPP
designing, Level 3: Division into Classes, Pseudocode for Pros
documentation, How to Use Routine Parameters, Programming Style as Documentation
downcast objects, Routine-Level Refactorings
duplication benefit, Valid Reasons to Create a Routine
endline layout, Laying Out Routines
error handling considerations, Design the Routine
errors in, relation to length of, Good Routine Names
event handlers, Design at the Routine Level
fields of objects, passing to, Routine-Level Refactorings
files, layout in, Laying Out Files and Programs
functional cohesion, Design at the Routine Level
functionality from libraries, Design the Routine
functions, special considerations for, Special Considerations in the Use of Functions
hacking approach to, Alternatives to the PPP
header comments for, Design the Routine
high quality, counterexample, High-Quality Routines
high-level comments from pseudocode, Code the Routine
importance of, High-Quality Routines
in keyword creation, How to Use Routine Parameters
indentation of, Laying Out Comments
inline, Macro Routines and Inline Routines
input-modify-output parameter order, How Long Can a Routine Be?
interface statements, Code the Routine
internal design, Level 5: Internal Routine Design
iterating pseudocode, Design the Routine
key points for, Key Points, Alternatives to the PPP
layout of, Using Spaces for Clarity, Laying Out Comments
length of, guideline for, Good Routine Names
limitations, documenting, Commenting Routines
logical cohesion, Design at the Routine Level
low-quality example, High-Quality Routines
mentally checking for errors, Check the Code
multiple returns from, Unusual Control Structures
named parameters in, How to Use Routine Parameters
naming, Design at the Routine Level, Design the Routine, Sample Naming Conventions, Reasons to Refactor
nested deeply, Valid Reasons to Create a Routine
objects, passing to, How to Use Routine Parameters, Routine-Level Refactorings
out keyword creation, How to Use Routine Parameters
overridable vs. non-overridable routines, Inheritance ("is a" Relationships)
overridden to do nothing, Inheritance ("is a" Relationships)
overriding, Summary of Reasons to Create a Class
performance considerations, Valid Reasons to Create a Routine, Design the Routine
pointer hiding benefit, Valid Reasons to Create a Routine
portability benefit, Valid Reasons to Create a Routine
postconditions, Design the Routine
PPP checklist for, Alternatives to the PPP
preconditions, Design the Routine
prerequisites, Design the Routine
problem definition, Design the Routine
procedural cohesion, Design at the Routine Level
procedure naming guideline, Good Routine Names
pseudocode writing step, Design the Routine
public, using in interfaces concern, Good Encapsulation
queries, refactoring, Routine-Level Refactorings
reasons for creating, list of, Operations That Seem Too Simple to Put Into Routines
refactoring, Code the Routine, Statement-Level Refactorings, System-Level Refactorings, Bad Times to Refactor
reliability from cohesiveness, Design at the Routine Level
removing errors, Check the Code
repeating steps, Clean Up Leftovers
returns from, multiple, Unusual Control Structures
reviewing pseudocode, Design the Routine
sequence hiding benefit, Valid Reasons to Create a Routine
sequential cohesion, Design at the Routine Level
setup code for, refactoring, Reasons to Refactor
similar parameters, order for, How to Use Routine Parameters
similar, refactoring, Routine-Level Refactorings
simple, usefulness of, Valid Reasons to Create a Routine
size as refactoring indicator, Philosophy of Software Evolution
small vs. large, Valid Reasons to Create a Routine, Good Routine Names
specification example, Design the Routine
stepping through code, Check the Code
strength, Design at the Routine Level
subclassing benefit, Valid Reasons to Create a Routine
temporal cohesion, Design at the Routine Level
test-first development, Alternatives to the PPP
testing, Design the Routine, Check the Code, Test-Support Tools
tramp data in, Reasons to Refactor
unused, refactoring, Class Interface Refactorings
valid reasons for creating, Valid Reasons to Create a Routine
variable names, differentiating from, Informal Naming Conventions
wrong class, indicator for, Reasons to Refactor
run time, binding during, Binding Time

S

safety counters in loops, Exiting the Loop
sandwich integration, Bottom-Up Integration
scaffolding, Test-Support Tools, Testing, Execution Profilers
debugging with, Execution Profilers
testing, Test-Support Tools, Testing
scalability, Performance
(see also )
schedules, estimating, Estimating a Construction Schedule
scientific method, classic steps in, Debugging by Superstition
SCM (software configuration management), What Is Configuration Management?
(see also )
scope of variables, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Scope, Scope, Keep Variables "Live" for as Short a Time as Possible, General Guidelines for Minimizing Scope, General Guidelines for Minimizing Scope, General Guidelines for Minimizing Scope, General Guidelines for Minimizing Scope, General Guidelines for Minimizing Scope, General Guidelines for Minimizing Scope, Comments on Minimizing Scope, Comments on Minimizing Scope, Using Each Variable for Exactly One Purpose, Optimum Name Length
convenience argument, General Guidelines for Minimizing Scope (see )
defined, Guidelines for Initializing Variables
global scope, problems with, Comments on Minimizing Scope
grouping related statements, General Guidelines for Minimizing Scope
key point, Using Each Variable for Exactly One Purpose
language differences, Guidelines for Initializing Variables
live time, minimizing, Keep Variables "Live" for as Short a Time as Possible
localizing references to variables, Scope
loop initializations, General Guidelines for Minimizing Scope
manageability argument, Comments on Minimizing Scope
minimizing, guidelines for, General Guidelines for Minimizing Scope
restrict and expand tactic, General Guidelines for Minimizing Scope
span of variables, Scope
value assignments, General Guidelines for Minimizing Scope
variable names, effects on, Optimum Name Length
scribe role in inspections, What Results Can You Expect from Inspections?
scripts, Common Sources of Inefficiency, Project-Specific Tools
programming tools, as, Project-Specific Tools
slowness of, Common Sources of Inefficiency
SDFs (software development folders), External Documentation
security, Business Rules
selections, code, Selection
selective data, Binding Time
self-documenting code, External Documentation, Commenting Paragraphs of Code
semantic coupling, Kinds of Coupling
semantic prefixes, User-Defined Type Abbreviations
semantics checkers, Interface Documentation Tools
sentinel tests for loops, Minimizing the Work Inside Loops
sequences, code, Valid Reasons to Create a Routine, Common Problems with Boolean Expressions, Summary of Techniques for Reducing Deep Nesting
hiding with routines, Valid Reasons to Create a Routine
structured programming concept of, Summary of Techniques for Reducing Deep Nesting
sequential approach, Determine the Kind of Software You're Working On
sequential cohesion, Design at the Routine Level
Set() routines, Class Interface Refactorings
setup code, refactoring, Reasons to Refactor
setup tools, Code-Generation Wizards
short-circuit evaluation, Using Parentheses to Clarify Boolean Expressions, Code-Tuning Techniques
side effects, C++, Using Only One Statement Per Line
signing off on code, Techniques for Encouraging Good Coding
simple-data-parameter coupling, Coupling Criteria
simple-object coupling, Coupling Criteria
single points of control, Named Constants
single-statement blocks, Other Considerations
singleton property, enforcing, Look for Common Design Patterns, Constructors
size of projects, Software Construction: Building Software, How Program Size Affects Construction, Communication and Size, Range of Project Sizes, Range of Project Sizes, Effect of Project Size on Errors, Effect of Project Size on Development Activities, Activity Proportions and Size, Programs, Products, Systems, and System Products, Programs, Products, Systems, and System Products, Programs, Products, Systems, and System Products, Programs, Products, Systems, and System Products, Programs, Products, Systems, and System Products, Programs, Products, Systems, and System Products, Programs, Products, Systems, and System Products, Programs, Products, Systems, and System Products, Programs, Products, Systems, and System Products, Methodology and Size, Additional Resources
activities, list of fastest growing, Activity Proportions and Size (see ; )
activity types, effects on, Effect of Project Size on Development Activities
building metaphor for, Software Construction: Building Software
communications between people, Communication and Size
complexity, effect of, Programs, Products, Systems, and System Products
defects created, effects on, Range of Project Sizes
documentation requirements, Programs, Products, Systems, and System Products
estimation errors, Programs, Products, Systems, and System Products
formality requirements, Programs, Products, Systems, and System Products
key points, Additional Resources
methodology considerations, Programs, Products, Systems, and System Products
overview, How Program Size Affects Construction
productivity, effects on, Effect of Project Size on Errors
ranges in, Range of Project Sizes
resources on, Methodology and Size
single product, multiple users, Programs, Products, Systems, and System Products
single program, single user, Programs, Products, Systems, and System Products
system products, Programs, Products, Systems, and System Products
systems, Programs, Products, Systems, and System Products
sizeof(), C-Pointer Pointers
sloppy processes, Design Is a Wicked Problem
smart pointers, C++-Pointer Pointers
smoke tests, Daily Build and Smoke Test
software accretion metaphor, Software Farming: Growing a System
software construction overview, Welcome to Software Construction, Welcome to Software Construction, What Is Software Construction?, What Is Software Construction?, What Is Software Construction?, What Is Software Construction?, What Is Software Construction?, What Is Software Construction?, Why Is Software Construction Important?, Why Is Software Construction Important?, Why Is Software Construction Important?, Why Is Software Construction Important?, Why Is Software Construction Important?, Why Is Software Construction Important?, How to Read This Book
activities excluded from, What Is Software Construction?
activities in, list of, Welcome to Software Construction
centralness to development process, Why Is Software Construction Important?
defined, Welcome to Software Construction
documentation by source code, Why Is Software Construction Important?
guaranteed done nature of, Why Is Software Construction Important?
importance of, What Is Software Construction?
key points for, How to Read This Book
main activities of, What Is Software Construction?
percent of total development process, Why Is Software Construction Important?
productivity, importance in, Why Is Software Construction Important?
programming as, What Is Software Construction?
programming vs., What Is Software Construction?
source code as documentation, Why Is Software Construction Important?
tasks in, list of, What Is Software Construction?
software design, Find Real-World Objects
software development folders (SDFs), External Documentation
software engineering overview of resources, Overview Material
software evolution, Refactoring, Refactoring, Refactoring, Refactoring, Philosophy of Software Evolution
background for, Refactoring
Cardinal Rule of, Philosophy of Software Evolution
construction vs. maintenance, Refactoring
improving vs. degrading direction of, Refactoring
philosophy of, Refactoring
software metaphors, Software Farming: Growing a System
software oracles, Iterate, Repeatedly, Again and Again
software quality, Characteristics of Software Quality
Software's Primary Technical Imperative, Inherit—When Inheritance Simplifies the Design
software-development libraries, Where to Find More Information, Information About Software Construction, Topics Beyond Construction, Overview Material, Overview Material, Lowbrow Programmer Magazines, Special-Interest Publications
bibliographies, Overview Material
construction, Information About Software Construction
magazines, Lowbrow Programmer Magazines
overview, Where to Find More Information, Topics Beyond Construction
reading plan, Special-Interest Publications
software engineering overviews, Overview Material
software-engineering guidelines, Techniques for Improving Software Quality
sorting, recursive algorithm for, Multiple Returns from a Routine
source code, Why Is Software Construction Important?, Additional Resources
documentation aspect of, Why Is Software Construction Important?
resource for, Additional Resources
source-code tools, How "Psychological Distance" Can Help, Programming Tools, Programming Tools, Integrated Development Environments (IDEs), Integrated Development Environments (IDEs), Multiple-File String Searching and Replacing, Multiple-File String Searching and Replacing, Multiple-File String Searching and Replacing, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Interface Documentation Tools, Picky Syntax and Semantics Checkers, Picky Syntax and Semantics Checkers, Restructurers, Restructurers, Restructurers, Restructurers
analyzing quality, Interface Documentation Tools (see )
beautifiers, Multiple-File String Searching and Replacing
class-hierarchy generators, Interface Documentation Tools
comparators, How "Psychological Distance" Can Help
cross-reference tools, Interface Documentation Tools
data dictionaries, Restructurers
Diff tools, Multiple-File String Searching and Replacing
editing tools, Programming Tools
grep, Integrated Development Environments (IDEs)
IDEs, Programming Tools
interface documentation, Interface Documentation Tools
merge tools, Multiple-File String Searching and Replacing
metrics reporters, Picky Syntax and Semantics Checkers
multiple-file string searches, Integrated Development Environments (IDEs)
refactoring tools, Picky Syntax and Semantics Checkers
restructuring tools, Restructurers
semantics checkers, Interface Documentation Tools
syntax checkers, Interface Documentation Tools
templates, Interface Documentation Tools
translators, Restructurers
version control tools, Restructurers
span, Scope, Other Kinds of Complexity
specific functional requirements checklist, Handling Requirements Changes During Construction
specific nonfunctional requirements checklist, Handling Requirements Changes During Construction
specification, Problem-Definition Prerequisite
speed improvement checklist, Recoding in a Low-Level Language
(see also )
(see also )
SQL, Java
stabilizing errors, Stabilize the Error
stair-step access tables, Indexed Access Tables
standards, overview of, Software Quality-Assurance Standards
state variables, Commenting Data Declarations
statements, Data-Level Refactorings, System-Level Refactorings, Laying Out Individual Statements, Using Spaces for Clarity, Using Spaces for Clarity, Formatting Continuation Lines, Formatting Continuation Lines, Laying Out Files and Programs
checklist, Laying Out Files and Programs
closely-related elements, Formatting Continuation Lines
continuation layout, Using Spaces for Clarity
ends of continuations, Formatting Continuation Lines
incomplete, Using Spaces for Clarity
length of, Laying Out Individual Statements
refactoring, Data-Level Refactorings, System-Level Refactorings
status reporting, Intellectual Honesty
status variables, Identify Areas Likely to Change, Kinds of Coupling, Naming Status Variables, Naming Status Variables, Error Processing and gotos, Commenting Data Declarations
bit-level meanings, Commenting Data Declarations
change, identifying areas of, Identify Areas Likely to Change
enumerated types for, Naming Status Variables
gotos rewritten with, Error Processing and gotos
names for, Naming Status Variables
semantic coupling of, Kinds of Coupling
straight-line code, Organizing Straight-Line Code, Organizing Straight-Line Code, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements That Must Be in a Specific Order, Statements Whose Order Doesn't Matter, Statements Whose Order Doesn't Matter, Making Code Read from Top to Bottom, Grouping Related Statements
checklist, Grouping Related Statements (see ; )
clarifying dependencies, Statements That Must Be in a Specific Order
dependencies concept, Organizing Straight-Line Code
documentation, Statements That Must Be in a Specific Order
error checking, Statements That Must Be in a Specific Order
grouping related statements, Making Code Read from Top to Bottom
hidden dependencies, Statements That Must Be in a Specific Order
initialization order, Statements That Must Be in a Specific Order
naming routines, Statements That Must Be in a Specific Order
non-obvious dependencies, Statements That Must Be in a Specific Order
organization to show dependencies, Statements That Must Be in a Specific Order
parameters, effective, Statements That Must Be in a Specific Order
proximity principle, Statements Whose Order Doesn't Matter
specific order, required, Organizing Straight-Line Code
top to bottom readability guideline, Statements Whose Order Doesn't Matter
Strategy pattern, Look for Common Design Patterns
stratification design goal, Desirable Characteristics of a Design
strcpy(), Strings in C
streams, Introduce Debugging Aids Early
strength, Good Abstraction
string data types, Floating-Point Numbers, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Characters and Strings, Strings in C, Strings in C, Guidelines for Creating Your Own Types, Minimize Array References
C language, Characters and Strings (see )
character sets, Characters and Strings
checklist, Guidelines for Creating Your Own Types
conversion strategies, Characters and Strings
indexes, Characters and Strings, Characters and Strings, Minimize Array References
initializing, Strings in C
localization, Characters and Strings
magic (literal) strings, Floating-Point Numbers
memory concerns, Characters and Strings, Strings in C
pointers vs. character arrays, Characters and Strings
Unicode, Characters and Strings, Characters and Strings
string pointers, Characters and Strings
strncpy(), Strings in C
strong cohesion, Look for Common Design Patterns
structs, Structures
structured basis testing, Testing During Construction, Bag of Testing Tricks
recommended, Testing During Construction
theory of, Bag of Testing Tricks
structured programming, Summary of Techniques for Reducing Deep Nesting, Summary of Techniques for Reducing Deep Nesting, Selection, Iteration, Iteration
core thesis of, Iteration
iteration, Iteration
overview, Summary of Techniques for Reducing Deep Nesting
selections, Selection
sequences, Summary of Techniques for Reducing Deep Nesting
structures, Unusual Data Types, Unusual Data Types, Structures, Structures, Structures, Structures, Structures, Structures, Structures, Structures, Structures, Structures, Structures, How to Reduce the Risks of Using Global Data, Additional Resources
blocks of data, operations on, Structures (see ; )
checklist for, How to Reduce the Risks of Using Global Data
clarifying data relationships with, Structures
classes performing as, Unusual Data Types
defined, Unusual Data Types
key points, Additional Resources
maintenance reduction with, Structures
overdoing, Structures
parameter simplification with, Structures
relationships, clear example of, Structures
routine calls with, Structures
simplifying data operations with, Structures
swapping data, Structures
unstructured data example, Structures
Visual Basic examples, Structures
stub objects, testing with, Test-Support Tools
stubs as integration aids, Benefits of Incremental Integration, Top-Down Integration
stubs with debugging aids, Plan to Remove Debugging Aids
style issues, Team Variation, External Documentation
human aspects of, Team Variation
self-documenting code, External Documentation
sub procedures, High-Quality Routines
(see also )
subsystem design level, Levels of Design
subtraction, Integers
swapping data using structures, Structures
switch statements, case Statements
symbolic debuggers, Coverage Monitors
syntax, errors in, Brute-Force Debugging, Debuggers, Interface Documentation Tools
system architecture, Typical Architectural Components
system calls, Common Sources of Inefficiency, Initialize at Compile Time
code tuning, Initialize at Compile Time
performance issues, Common Sources of Inefficiency
system dependencies, Level 2: Division into Subsystems or Packages
system perturbers, Symbolic Debuggers
system testing, Developer Testing
system-level refactoring, Class Interface Refactorings, System-Level Refactorings

T

T-shaped integration, Feature-Oriented Integration
table-driven methods, Table-Driven Methods, Table-Driven Methods, General Considerations in Using Table-Driven Methods, General Considerations in Using Table-Driven Methods, Two Issues in Using Table-Driven Methods, Two Issues in Using Table-Driven Methods, Insurance Rates Example, Insurance Rates Example, Table-Driven Approach, Table-Driven Approach, Table-Driven Approach, Table-Driven Approach, Table-Driven Approach, Table-Driven Approach, Fudging Lookup Keys, Indexed Access Tables, Indexed Access Tables, Stair-Step Access Tables, Stair-Step Access Tables, Stair-Step Access Tables, Stair-Step Access Tables, Stair-Step Access Tables, Key Points, Making Complicated Expressions Simple, Compare Performance of Similar Logic Structures, Use the Correct Type of Constants
advantages of, Table-Driven Approach
binary searches with, Stair-Step Access Tables
case statement approach, Table-Driven Approach
checklist, Stair-Step Access Tables
code-tuning with, Compare Performance of Similar Logic Structures
creating from expressions, Making Complicated Expressions Simple
days-in-month example, Two Issues in Using Table-Driven Methods
defined, Table-Driven Methods
design method, Table-Driven Approach
endpoints of ranges, Stair-Step Access Tables
flexible-message-format example, Insurance Rates Example
fudging keys for, Table-Driven Approach
indexed access tables, Indexed Access Tables, Stair-Step Access Tables
insurance rates example, Insurance Rates Example
issues in, General Considerations in Using Table-Driven Methods
key points, Key Points
keys for, Table-Driven Approach
lookup issue, General Considerations in Using Table-Driven Methods
miscellaneous examples, Stair-Step Access Tables
object approach, Table-Driven Approach
precomputing calculations, Use the Correct Type of Constants
purpose of, Table-Driven Methods
stair-step access tables, Indexed Access Tables
storage issue, Two Issues in Using Table-Driven Methods
transforming keys, Fudging Lookup Keys
Tacoma Narrows bridge, Design in Construction
takedown code, refactoring, Reasons to Refactor
Team Software Process (TSP), How Many Errors Should You Expect to Find?
teams, Example of Programming into a Language, Communication and Size, Techniques for Encouraging Good Coding, What to Do If You're Behind, How Do Programmers Spend Their Time?, How Do Programmers Spend Their Time?, Team Variation, Team Variation, Religious Issues, Religious Issues, Physical Environment, Additional Resources on Programmers as Human Beings, Daily Build and Smoke Test, Conquer Complexity, Pick Your Process
build groups, Daily Build and Smoke Test
checklist, Example of Programming into a Language
development processes used by, Pick Your Process
expanding to meet schedules, What to Do If You're Behind
managers, Additional Resources on Programmers as Human Beings
physical environment, Religious Issues
privacy of offices, Religious Issues
process, importance to, Conquer Complexity
religious issues, Team Variation
resources on, Physical Environment
size of projects, effects of, Communication and Size
style issues, Team Variation
time allocations, How Do Programmers Spend Their Time?
variations in performance, How Do Programmers Spend Their Time?
technology waves, determining your location in, Visual Basic
Template Method pattern, Look for Common Design Patterns
template tools, Interface Documentation Tools
temporal cohesion, Design at the Routine Level
temporary variables, Naming Status Variables
test-data generators, Building Scaffolding to Test Individual Classes
test-first development, Alternatives to the PPP
testability, Characteristics of Software Quality, Techniques for Improving Software Quality
defined, Characteristics of Software Quality
strategies for, Techniques for Improving Software Quality
testing, Alternatives to the PPP, Characteristics of Software Quality, Techniques for Improving Software Quality, Developer Testing, Developer Testing, Developer Testing, Developer Testing, Developer Testing, Developer Testing, Developer Testing, Developer Testing, Developer Testing, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Role of Developer Testing in Software Quality, Testing During Construction, Testing During Construction, Testing During Construction, Testing During Construction, Testing During Construction, Testing During Construction, Test First or Test Last?, Test First or Test Last?, Test First or Test Last?, Test First or Test Last?, Bag of Testing Tricks, Bag of Testing Tricks, Bag of Testing Tricks, Bag of Testing Tricks, Structured Basis Testing, Structured Basis Testing, Structured Basis Testing, Structured Basis Testing, Combinations of Data States, Combinations of Data States, Error Guessing, Error Guessing, Boundary Analysis, Boundary Analysis, Classes of Bad Data, Classes of Bad Data, Classes of Bad Data, Classes of Bad Data, Classes of Good Data, Classes of Good Data, Typical Errors, Which Classes Contain the Most Errors?, Errors by Classification, Errors by Classification, Errors by Classification, Errors by Classification, Errors by Classification, Errors by Classification, Errors by Classification, How Many Errors Should You Expect to Find?, How Many Errors Should You Expect to Find?, How Many Errors Should You Expect to Find?, How Many Errors Should You Expect to Find?, How Many Errors Should You Expect to Find?, How Many Errors Should You Expect to Find?, Test-Support Tools, Test-Support Tools, Test-Support Tools, Test-Support Tools, Test-Support Tools, Building Scaffolding to Test Individual Classes, Building Scaffolding to Test Individual Classes, Building Scaffolding to Test Individual Classes, Building Scaffolding to Test Individual Classes, Test-Data Generators, Coverage Monitors, Coverage Monitors, Coverage Monitors, Coverage Monitors, Coverage Monitors, Symbolic Debuggers, Symbolic Debuggers, Symbolic Debuggers, Symbolic Debuggers, Improving Your Testing, Improving Your Testing, Improving Your Testing, Automated Testing, Automated Testing, Keeping Test Records, Testing, Testing, Testing, Relevant Standards, Relevant Standards, Relevant Standards, Key Points, Stabilize the Error, Tips for Finding Defects, Tips for Finding Defects, Preprocessors
automated testing, Improving Your Testing
bad data classes, Boundary Analysis
black-box testing, Developer Testing
boundary analysis, Error Guessing
bounds checking tools, Symbolic Debuggers
cases, creating, Structured Basis Testing, How Many Errors Should You Expect to Find?, Relevant Standards
characteristics of, troublesome, Role of Developer Testing in Software Quality
checklist, Relevant Standards
classes prone to error, Typical Errors
classifications of errors, Which Classes Contain the Most Errors?
clean test limitation, Test First or Test Last?
clerical errors (typos), Errors by Classification
code coverage testing, Structured Basis Testing
component testing, Developer Testing
compound boundaries, Boundary Analysis
construction defects, proportion of, Errors by Classification
coverage of code, Bag of Testing Tricks, Coverage Monitors
data flow testing, Structured Basis Testing
data generators for, Building Scaffolding to Test Individual Classes
data recorder tools, Coverage Monitors
debuggers, Coverage Monitors
debugging, compared to, Developer Testing
defined-used data paths, Combinations of Data States
design concerns, Testing During Construction
designs, misunderstanding, Errors by Classification
developer-view limitations, Test First or Test Last?
developing tests, How Many Errors Should You Expect to Find?
diff tools for, Building Scaffolding to Test Individual Classes
driver routines, Test-Support Tools
dummy classes, Test-Support Tools
dummy files for, Building Scaffolding to Test Individual Classes
during construction, Role of Developer Testing in Software Quality
ease of fixing defects, Errors by Classification
equivalence partitioning, Combinations of Data States
error checklists for, Testing During Construction
error databases, Symbolic Debuggers
error guessing, Error Guessing
error presence assumption, Role of Developer Testing in Software Quality
errors in testing itself, How Many Errors Should You Expect to Find?
expected defect rate, How Many Errors Should You Expect to Find?
first or last recommendation, Testing During Construction, Testing
frameworks for, How Many Errors Should You Expect to Find?, Building Scaffolding to Test Individual Classes
goals of, Role of Developer Testing in Software Quality
good data classes, Classes of Bad Data
integration testing, Developer Testing
JUnit for, Testing
key points, Key Points
limitations on developer testing, Test First or Test Last?
logging tools for, Coverage Monitors
logic coverage testing, Structured Basis Testing
maximum normal configurations, Classes of Bad Data
measurement of, Errors by Classification, Automated Testing
memory tools, Symbolic Debuggers
minimum normal configurations, Classes of Bad Data
mock objects, Test-Support Tools
nominal case errors, Classes of Bad Data
old data, compatibility with, Classes of Good Data
optimistic programmers limitation, Test First or Test Last?
outside of construction domain defects, Errors by Classification
planning for, Improving Your Testing
prioritizing coverage, Bag of Testing Tricks
provability of correctness, Role of Developer Testing in Software Quality, Bag of Testing Tricks
quality not affected by, Role of Developer Testing in Software Quality
random-data generators, Test-Data Generators
recommended approach to, Testing During Construction
record keeping for, Automated Testing
regression testing, Developer Testing, Improving Your Testing
requirements, Testing During Construction
resources for, Keeping Test Records
results, uses for, Role of Developer Testing in Software Quality
role in software quality assurance, Developer Testing
routines, black-box testing of, Role of Developer Testing in Software Quality
scaffolding, Test-Support Tools, Testing
scope of defects, Errors by Classification
selecting cases for convenience, Classes of Good Data
stabilizing errors, Stabilize the Error
standards, IEEE, Relevant Standards
structured basis testing, Testing During Construction, Bag of Testing Tricks
stub objects, Test-Support Tools
symbolic debuggers, Coverage Monitors
system perturbers, Symbolic Debuggers
system testing, Developer Testing
test case errors, How Many Errors Should You Expect to Find?
test-first development, Alternatives to the PPP
testability, Characteristics of Software Quality, Techniques for Improving Software Quality
time commitment to, Role of Developer Testing in Software Quality
tools, list of, Preprocessors
unit testing, Developer Testing, Tips for Finding Defects
varying cases, Tips for Finding Defects
white-box testing, Developer Testing, Role of Developer Testing in Software Quality
threading, Common Problems with Global Data
throwaway code, Experimental Prototyping
throwing one away metaphor, Common Software Metaphors
time allowances, General Architectural Quality
tool version control, Software Code Changes
toolbox approach, Applying Software Techniques: The Intellectual Toolbox
tools, Selection of Major Construction Practices
checklist, Selection of Major Construction Practices
top-down approach to design, Iterate
top-down integration, Benefits of Incremental Integration
transcendental functions, Relative Performance Costs of Common Operations, Be Wary of System Routines
translator tools, Restructurers
try-finally statements, Error Processing and gotos
type casting, avoiding, C++-Pointer Pointers
type creation, Arrays, Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Creating Your Own Types (Type Aliasing), Why Are the Examples of Creating Your Own Types in Pascal and Ada?, Why Are the Examples of Creating Your Own Types in Pascal and Ada?, Why Are the Examples of Creating Your Own Types in Pascal and Ada?, Why Are the Examples of Creating Your Own Types in Pascal and Ada?, Why Are the Examples of Creating Your Own Types in Pascal and Ada?, Guidelines for Creating Your Own Types, Guidelines for Creating Your Own Types
C++, Creating Your Own Types (Type Aliasing) (see ; )
centralization benefit, Creating Your Own Types (Type Aliasing)
checklist, Guidelines for Creating Your Own Types
classes, compared to, Guidelines for Creating Your Own Types
example of, Creating Your Own Types (Type Aliasing)
guidelines for, Why Are the Examples of Creating Your Own Types in Pascal and Ada?
information hiding aspect of, Creating Your Own Types (Type Aliasing)
languages with, evaluation of, Creating Your Own Types (Type Aliasing)
modification benefit, Creating Your Own Types (Type Aliasing)
naming conventions, Why Are the Examples of Creating Your Own Types in Pascal and Ada?
Pascal example, Creating Your Own Types (Type Aliasing)
portability benefit, Why Are the Examples of Creating Your Own Types in Pascal and Ada?
predefined types, avoiding, Why Are the Examples of Creating Your Own Types in Pascal and Ada?
purpose of, Arrays
reasons for, Creating Your Own Types (Type Aliasing)
redefining predefined, Why Are the Examples of Creating Your Own Types in Pascal and Ada?
reliability benefit, Creating Your Own Types (Type Aliasing)
validation benefit, Creating Your Own Types (Type Aliasing)
type definitions, Sample Naming Conventions

U

UDFs (unit development folders), External Documentation
UDT (user-defined type) abbreviations, Standardized Prefixes
UML diagrams, Capturing Your Design Work, Software Design, General
understandability, Characteristics of Software Quality
(see also )
Unicode, Kinds of Names to Avoid
unit development folders (UDFs), External Documentation
unit testing, Developer Testing
UNIX programming environment, Code Tuning
unrolling loops, Jamming
unswitching loops, Use Lazy Evaluation
upstream prerequisites, Causes of Incomplete Preparation
usability, The Software-Quality Landscape
used data state, Structured Basis Testing
user interfaces, Business Rules, Level 2: Division into Subsystems or Packages, Class Interface Refactorings
architecture prerequisites, Business Rules
refactoring data from, Class Interface Refactorings
subsystem design, Level 2: Division into Subsystems or Packages
user-defined type (UDT) abbreviations, Standardized Prefixes

V

validation, Protecting Your Program from Invalid Inputs, Protecting Your Program from Invalid Inputs, Protecting Your Program from Invalid Inputs, Assertions, Enumerated Types
assumptions to check, list of, Assertions
data types, suspicious, Protecting Your Program from Invalid Inputs
enumerated types for, Enumerated Types
external data sources rule, Protecting Your Program from Invalid Inputs
input parameters rule, Protecting Your Program from Invalid Inputs
variable names, Implicit Declarations, The Power of Variable Names, Considerations in Choosing Good Names, Considerations in Choosing Good Names, Considerations in Choosing Good Names, The Most Important Naming Consideration, The Most Important Naming Consideration, The Most Important Naming Consideration, The Most Important Naming Consideration, Optimum Name Length, Optimum Name Length, The Effect of Scope on Variable Names, The Effect of Scope on Variable Names, The Effect of Scope on Variable Names, The Effect of Scope on Variable Names, Computed-Value Qualifiers in Variable Names, Naming Loop Indexes, Naming Status Variables, Naming Status Variables, Naming Temporary Variables, Naming Boolean Variables, Naming Constants, Informal Naming Conventions, Informal Naming Conventions, Guidelines for a Language-Independent Convention, Guidelines for Language-Specific Conventions, Guidelines for Language-Specific Conventions, Sample Naming Conventions, Sample Naming Conventions, Sample Naming Conventions, Standardized Prefixes, Creating Short Names That Are Readable, Phonetic Abbreviations, Comments on Abbreviations, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, Kinds of Names to Avoid, How "Psychological Distance" Can Help
abbreviation guidelines, Creating Short Names That Are Readable (see ; ; )
accurate description rule, Considerations in Choosing Good Names
bad names, examples of, The Power of Variable Names, The Most Important Naming Consideration
boolean variables, Naming Temporary Variables
C language, Guidelines for Language-Specific Conventions, Sample Naming Conventions
C++, The Effect of Scope on Variable Names, Guidelines for Language-Specific Conventions
capitalization, Kinds of Names to Avoid
characters, hard to read, Kinds of Names to Avoid
checklist, Kinds of Names to Avoid
class member variables, Guidelines for a Language-Independent Convention
computed-value qualifiers, The Effect of Scope on Variable Names
constants, Naming Constants
enumerated types, Naming Boolean Variables
full description rule, Considerations in Choosing Good Names
global, qualifiers for, The Effect of Scope on Variable Names
good names, examples of, Considerations in Choosing Good Names, The Most Important Naming Consideration
homonyms, Kinds of Names to Avoid
Java conventions, Sample Naming Conventions
key points, Kinds of Names to Avoid
kinds of information in, Sample Naming Conventions
length, optimum, Optimum Name Length
loop indexes, Naming Loop Indexes
misspelled words, Kinds of Names to Avoid
multiple natural languages, Kinds of Names to Avoid
namespaces, The Effect of Scope on Variable Names
numerals in, Kinds of Names to Avoid
opposite pairs for, Computed-Value Qualifiers in Variable Names
phonic abbreviations, Phonetic Abbreviations
problem orientation rule, The Most Important Naming Consideration
psychological distance, How "Psychological Distance" Can Help
purpose of, Implicit Declarations
reserved names, Kinds of Names to Avoid
routine names, differentiating from, Informal Naming Conventions
scope, effects of, Optimum Name Length
similarity of names, too much, Comments on Abbreviations
specificity rule, The Most Important Naming Consideration
status variables, Naming Status Variables
temporary variables, Naming Status Variables
type names, differentiating from, Informal Naming Conventions
Visual Basic, Standardized Prefixes
variables, Identify Areas Likely to Change, General Issues in Using Variables, The Data Literacy Test, Implicit Declarations, Guidelines for Initializing Variables, Guidelines for Initializing Variables, Scope, Scope, Keep Variables "Live" for as Short a Time as Possible, Comments on Minimizing Scope, Persistence, Binding Time, Binding Time, Binding Time, Relationship Between Data Types and Control Structures, Relationship Between Data Types and Control Structures, Using Each Variable for Exactly One Purpose, Using Each Variable for Exactly One Purpose, Using Each Variable for Exactly One Purpose, Using Each Variable for Exactly One Purpose, Using Each Variable for Exactly One Purpose, Using Each Variable for Exactly One Purpose, Checking Endpoints, Other Kinds of Complexity, Reasons Not to Refactor, Class Interface Refactorings, Class Interface Refactorings, Commenting Data Declarations
binding time for, Persistence
change, identifying areas of, Identify Areas Likely to Change
checklist for using, Using Each Variable for Exactly One Purpose
comments for, Commenting Data Declarations
counters, Guidelines for Initializing Variables
data literacy test, General Issues in Using Variables
data type relationship to control structures, Binding Time
hidden meanings, avoiding, Using Each Variable for Exactly One Purpose
hybrid coupling, Using Each Variable for Exactly One Purpose
implicit declarations, The Data Literacy Test
initializing, Implicit Declarations, Using Each Variable for Exactly One Purpose
iterative data, Relationship Between Data Types and Control Structures
key points, Using Each Variable for Exactly One Purpose
live time, Keep Variables "Live" for as Short a Time as Possible, Other Kinds of Complexity
localizing references to, Scope
looping, Checking Endpoints
persistence of, Comments on Minimizing Scope
Principle of Proximity, Guidelines for Initializing Variables
public class members, Class Interface Refactorings
refactoring, Reasons Not to Refactor, Class Interface Refactorings
reusing, Relationship Between Data Types and Control Structures
selective data, Binding Time
sequential data, Binding Time
span of, Scope
using all declared, Using Each Variable for Exactly One Purpose
version control, Plan to Remove Debugging Aids, Software Code Changes, Restructurers, General Guidelines for File Documentation
commenting, General Guidelines for File Documentation
debugging aid removal, Plan to Remove Debugging Aids
tools for, Software Code Changes, Restructurers
visibility, Secrets and the Right to Privacy, Keep Coupling Loose, General Guidelines for Minimizing Scope
classes, of, Secrets and the Right to Privacy
coupling criteria for, Keep Coupling Loose
vision statement prerequisites, Choosing Between Iterative and Sequential Approaches
Visual Basic, Java, Classes in General, How to Use Routine Parameters, Guidelines for Using Assertions, Exceptions, Exceptions, Implicit Declarations, Guidelines for a Language-Independent Convention, Sample Naming Conventions, Boolean Variables, Structures, Parentheses, Endline Layout
assertion examples, Guidelines for Using Assertions
blocking style, Parentheses
case-insensitivity, Guidelines for a Language-Independent Convention
description of, Java
enumerated types, Boolean Variables
exceptions in, Exceptions, Exceptions
implicit declarations, turning off, Implicit Declarations
layout recommended, Endline Layout
naming conventions for, Sample Naming Conventions
parameters example, How to Use Routine Parameters
resources for, Classes in General
structures, Structures

W

walk-throughs, Inspection Summary, Dog-and-Pony Shows
warning signs, Watch for Falling Rocks
while loops, Selecting the Kind of Loop, Loop with Test at the Beginning, Loop with Test at the Beginning, Loop with Test at the Beginning, Entering the Loop, Entering the Loop, Exiting the Loop, Null Statements, Fixing a Defect
advantages of, Entering the Loop
break statements, Exiting the Loop
do-while loops, Loop with Test at the Beginning
exits in, Loop with Test at the Beginning
infinite loops, Entering the Loop
misconception of evaluation, Fixing a Defect
null statements with, Null Statements
purpose of, Selecting the Kind of Loop
tests, position of, Loop with Test at the Beginning
white space, Layout Extremes, Objectives of Good Layout, White Space, White Space, White Space, Fine Points of Formatting Control-Structure Blocks, Laying Out Individual Statements
blank lines, White Space, Fine Points of Formatting Control-Structure Blocks
defined, Layout Extremes
grouping with, White Space
importance of, Objectives of Good Layout
indentation, White Space
individual statements with, Laying Out Individual Statements
white-box testing, Developer Testing, Role of Developer Testing in Software Quality
wicked problems, Design in Construction
Wikis, How Much Design Is Enough?
WIMP syndrome, Causes of Incomplete Preparation
WISCA syndrome, Causes of Incomplete Preparation
workarounds, documenting, Commenting Paragraphs of Code
writing metaphor for coding, Common Software Metaphors
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.21.98.207