Index
C
- calls, Motivation
- chains, conditional, Dealing with Conditional Chains-Dealing with Conditional Chains
- change
- checksum, Write Short Units of Code
- classes, splitting, Split Classes to Separate Concerns
- clean coding
- and badly-handled exceptions, Rule 7: Leave No Badly Handled Exception Behind
- and Boy Scout rule, Objection: Why Should We Invest in Unit Tests When the Current Coverage Is Low?
- and commented-out code, Rule 3: Leave No Code in Comments Behind
- and comments as documentation, Objection: Comments Are Our Documentation
- and dead code, Rule 4: Leave No Dead Code Behind
- and exception class implementation, Objection: Exception Handling Causes Code Additions
- and number of coding guidelines, Objection: Why Only These Coding Guidelines?
- and unit-level code, Rule 1: Leave No-Unit Level Code Smells Behind
- applying guidelines for, How to Apply the Guideline-Rule 7: Leave No Badly Handled Exception Behind
- avoiding long identifiers, Rule 5: Leave No Long Identifiers Behind
- avoiding magic constants, Rule 6: Leave No Magic Constants Behind
- common objections to, Common Objections to Writing Clean Code
- importance of, Write Clean Code-Objection: Why Only These Coding Guidelines?
- minimizing inline comments, Rule 2: Leave No Bad Comments Behind
- refactoring for improved maintainability, Leave No Trace
- clone detection tools, Duplicated Code Is Harder to Analyze
- clones (see code clones)
- code
- complexity as quality characteristic, Write Simple Units of Code
- dead, Rule 4: Leave No Dead Code Behind
- finding/analyzing, A Good Component Balance Eases Finding and Analyzing Code
- hidden vs. interface, See Also
- improvement through test automation, Writing Tests Make You Write Better Code
- minimizing unit size, Write Short Units of Code-See Also
- reading when spread out over multiple units, Objection: Code Is Harder to Read When Spread Out
- replacing custom code with libraries/frameworks, Replace Custom Code with Third-Party Libraries/Frameworks
- test automation and predictability of, Automated Testing Makes Code Predictable
- unreachable, Unreachable code in methods
- writing clean (see clean coding)
- code clones
- codebase
- codebase volume
- advantages of minimizing, Motivation-Large Systems Have Higher Defect Density
- and defect density, Large Systems Have Higher Defect Density
- applying guidelines for, How to Apply the Guideline-Technical Measures
- common objections to minimizing of, Common Objections to Keeping the Codebase Small-Objection: Splitting the Codebase Is Impossible Because of Tight Coupling
- duplication as impediment to reducing, Objection: Splitting the Codebase Leads to Duplication
- functionality-related measures to minimize, Functional Measures
- importance of minimizing, Keep Your Codebase Small-Objection: Splitting the Codebase Is Impossible Because of Tight Coupling
- maintenance and, Large Codebases Are Harder to Maintain
- platform architecture and, Objection: Splitting the Codebase Is Impossible Because of Platform Architecture
- productivity measures and, Objection: Reducing the Codebase Size Is Impeded by Productivity Measures
- programming languages and, Objection: Reducing the Codebase Size is Impeded by the Programming Language
- project failures and, A Project That Sets Out to Build a Large Codebase Is More Likely to Fail
- SIG rating thresholds, Objection: Splitting the Codebase Is Impossible Because of Tight Coupling
- system complexity as impediment to reducing, Objection: System Complexity Forces Code Copying
- technical measures to minimize, Technical Measures
- tight coupling as impediment to reducing, Objection: Splitting the Codebase Is Impossible Because of Tight Coupling
- comments
- complexity, Write Simple Units of Code
- component balance, Keep Architecture Components Balanced-See Also
- advantages of, Motivation
- and component independence, Motivation
- and deceptive acceptability of imbalance, Objection: Component Imbalance Works Just Fine
- and entanglements, Objection: Entanglement Is Impairing Component Balance
- applying guidelines for, How to Apply the Guideline
- clarifying domains for, Clarify the System’s Domains and Apply Those Consistently
- common objections to, Common Objections to Balancing Components
- deciding on proper conceptual level for grouping functionality, Decide on the Right Conceptual Level for Grouping Functionality into Components
- importance of, Keep Architecture Components Balanced-See Also
- isolation of maintenance effects, A Good Component Balance Better Isolates Maintenance Effects
- separation of maintenance responsibilities, A Good Component Balance Separates Maintenance Responsibilities
- SIG rating thresholds, See Also
- when finding/analyzing code, A Good Component Balance Eases Finding and Analyzing Code
- component coupling, module coupling vs., Couple Architecture Components Loosely
- component dependence, Couple Architecture Components Loosely
- component guidelines, unit guidelines vs., Lower-Level (Unit) Guidelines Take Precedence Over Higher-Level (Component) Guidelines
- component imbalance, Keep Architecture Components Balanced, Objection: Component Imbalance Works Just Fine
- component independence
- advantages of, Motivation-Low Component Dependence Eases Testing
- and Abstract Factory design pattern, Abstract Factory Design Pattern-Abstract Factory Design Pattern
- and entangled components, Objection: Component Dependence Cannot Be Fixed Because the Components Are Entangled
- and isolated maintenance, Low Component Dependence Allows for Isolated Maintenance
- and separation of maintenance responsibilities, Low Component Dependence Separates Maintenance Responsibilities
- and testing, Low Component Dependence Eases Testing
- applying guidelines for, How to Apply the Guideline-Abstract Factory Design Pattern
- common objections to, Common Objections to Loose Component Coupling
- defined, Couple Architecture Components Loosely
- importance of, Couple Architecture Components Loosely-See Also
- SIG rating thresholds, See Also
- time as factor in achieving, Objection: No Time to Fix
- when throughput is a requirement, Objection: Throughput Is a Requirement
- components, packages vs., Generic Names for Elements of Source Code
- concepts, generic names for, Generic Names for Elements of Source Code
- concerns, separation of, Separate Concerns in Modules-Split Classes to Separate Concerns, Low Component Dependence Allows for Isolated Maintenance, A Good Component Balance Better Isolates Maintenance Effects, Objection: Entanglement Is Impairing Component Balance
- conditional chains, Dealing with Conditional Chains-Dealing with Conditional Chains
- conditionals, nested, Dealing with Nesting-Dealing with Nesting
- constants, magic, Rule 6: Leave No Magic Constants Behind
- conventions, Guideline Encourages Improper Formatting, A Good Component Balance Eases Finding and Analyzing Code, Rule 2: Leave No Bad Comments Behind, Rule 5: Leave No Long Identifiers Behind, Objection: Why Only These Coding Guidelines?
- copying and pasting
- copying code (see duplication [code])
- core classes, Small Interfaces Are Easier to Understand and Reuse
- corrective maintenance, The Four Types of Software Maintenance
- coupling, Separate Concerns in Modules
- coverage
- CPD (clone detection tool), Duplicated Code Is Harder to Analyze
- cyclomatic complexity, Write Simple Units of Code
- (see also McCabe complexity)
D
- data transfer objects, How to Apply the Guideline
- dead code, Rule 4: Leave No Dead Code Behind
- deadlines, component independence and, Objection: No Time to Fix
- defect density, codebase volume and, Large Systems Have Higher Defect Density
- defensive programming, exception handling and, Objection: Exception Handling Causes Code Additions
- dependency injection, Abstract Factory Design Pattern
- discipline, coding and, Turning the Guidelines into Practice
- documentation
- domains
- duplicates (code clones), Types of Duplication
- duplication (code)
- advantages of avoiding, Motivation
- and analysis, Duplicated Code Is Harder to Analyze
- and assumption that code will never change, This Code Will Never Change
- and backups, Duplicates of Entire Files Should Be Allowed as Backups
- and copying from another codebase, Copying from Another Codebase Should Be Allowed
- and Extract Superclass refactoring technique, The Extract Superclass Refactoring Technique-The Extract Superclass Refactoring Technique
- and modification, Duplicated Code Is Harder to Modify
- and slight variations of common functionality, Slight Variations, and Hence Duplication, Are Unavoidable
- and string literals, Duplication in String Literals Is Unavoidable and Harmless
- and unit tests, Unit Tests Are Covering Me
- as impediment to reducing codebase volume, Objection: Splitting the Codebase Leads to Duplication
- avoiding, Write Code Once-See Also
- common objections to avoiding, Common Objections to Avoiding Code Duplication-Duplication in String Literals Is Unavoidable and Harmless
- guidelines for avoiding, How to Apply the Guideline-The Extract Superclass Refactoring Technique
- SIG ratings, See Also
- types of, Types of Duplication
E
- Easymock, General Principles for Writing Good Unit Tests
- embedded software, Misunderstanding: Maintainability Is Industry-Dependent
- encapsulation, Small, Loosely Coupled Modules Ease Navigation Through the Codebase, Hide Specialized Implementations Behind Interfaces, Objection: Java Interfaces Are Not Just for Loose Coupling, Motivation, Abstract Factory Design Pattern, Objection: Throughput Is a Requirement
- end-to-end tests, How to Apply the Guideline
- entangled components
- errors, test, Getting Started with jUnit Tests
- exception handling
- execution paths, Write Simple Units of Code
- Extract Method refactoring technique, Refactoring technique: Extract Method, How to Apply the Guideline
- Extract Superclass refactoring technique, The Extract Superclass Refactoring Technique-The Extract Superclass Refactoring Technique, The Extract Superclass Refactoring Technique
G
- guidelines, maintainability
I
- identifiers, long, Rule 5: Leave No Long Identifiers Behind
- if-then-else statements, Dealing with Conditional Chains-Dealing with Conditional Chains
- implementations, specialized, Hide Specialized Implementations Behind Interfaces-Hide Specialized Implementations Behind Interfaces
- incoming calls, Motivation
- industry-dependent software development, Misunderstanding: Maintainability Is Industry-Dependent
- integration tests, How to Apply the Guideline
- interface code, See Also
- interfaces, unit (see unit interfaces)
- internal calls, Motivation
- Introduce Parameter Object refactoring pattern, Keep Unit Interfaces Small
- inversion of control (IoC), Objection: Not All Loose Coupling Solutions Increase Maintainability
- isolated maintenance, Low Component Dependence Allows for Isolated Maintenance
L
- large class smell, How to Apply the Guideline, Separate Concerns in Modules, Split Classes to Separate Concerns
- large systems, splitting up of, Technical Measures
- libraries
- local variables, Refactoring technique: Replace Method with Method Object
- loose coupling, Separate Concerns in Modules
- (see also component independence)
- advantages of, Motivation
- and reuse, Objection: Loose Coupling Conflicts With Reuse
- component, Couple Architecture Components Loosely, How to Apply the Guideline-See Also
- Java interfaces and, Objection: Java Interfaces Are Not Just for Loose Coupling
- modules, Separate Concerns in Modules, Motivation-Split Classes to Separate Concerns, Hide Specialized Implementations Behind Interfaces, Objection: Not All Loose Coupling Solutions Increase Maintainability, Writing Tests Make You Write Better Code
- systems, Technical Measures
- lower-level guidelines, Lower-Level (Unit) Guidelines Take Precedence Over Higher-Level (Component) Guidelines
M
- magic constants, Rule 6: Leave No Magic Constants Behind
- maintainability
- and discipline during development, Principle 2: Maintainability Is Not an Afterthought, and Every Contribution Counts
- as enabler for other quality characteristics, Maintainability Is an Enabler for Other Quality Characteristics
- as industry-independent, Misunderstanding: Maintainability Is Industry-Dependent
- as language-independent, Misunderstanding: Maintainability Is Language-Dependent
- as nonbinary quantity, Misunderstanding: Maintainability Is a Binary Quantity
- business impact of, Maintainability Has Significant Business Impact
- defined, What Is Maintainability?
- guidelines (see guidelines, maintainability)
- importance of, Why Is Maintainability Important?-Maintainability Is an Enabler for Other Quality Characteristics
- importance of simple guidelines, Principle 1: Maintainability Benefits Most from Simple Guidelines
- improvement over time, How SIG Measures Maintainability
- metrics for, Who Should Read This Book
- misunderstandings about, Misunderstandings About Maintainability
- performance vs., Objection: Having More Units Is Bad for Performance
- rating, Rating Maintainability-Rating Maintainability
- maintenance, four types of, The Four Types of Software Maintenance
- man-months/years, Objection: Splitting the Codebase Is Impossible Because of Tight Coupling
- manual testing
- McCabe complexity
- method invocations, Objection: Having More Units Is Bad for Performance
- method modification, Methods with Small Interfaces Are Easier to Modify
- method splitting, Objection: Splitting Up Methods Does Not Reduce Complexity
- methods
- metrics, maintainability, Who Should Read This Book, How SIG Measures Maintainability-How SIG Measures Maintainability
- mock object, General Principles for Writing Good Unit Tests
- mocking framework, General Principles for Writing Good Unit Tests
- Mockito, General Principles for Writing Good Unit Tests
- modifiability, Hide Specialized Implementations Behind Interfaces
- modification
- modularity, Hide Specialized Implementations Behind Interfaces
- module coupling, Separate Concerns in Modules-Objection: Not All Loose Coupling Solutions Increase Maintainability
- and IoC, Objection: Not All Loose Coupling Solutions Increase Maintainability
- and Java interfaces, Objection: Java Interfaces Are Not Just for Loose Coupling
- and navigation of codebase, Small, Loosely Coupled Modules Ease Navigation Through the Codebase
- and reuse, Objection: Loose Coupling Conflicts With Reuse
- and utility code, Objection: High Fan-in of Utility Classes Is Unavoidable
- applying guidelines for, How to Apply the Guideline-Replace Custom Code with Third-Party Libraries/Frameworks
- common objections to separating concerns, Common Objections to Separating Concerns
- component coupling vs., Couple Architecture Components Loosely
- hiding specialized implementations behind interfaces, Hide Specialized Implementations Behind Interfaces-Hide Specialized Implementations Behind Interfaces
- loose (see loose coupling)
- replacing custom code with libraries/frameworks, Replace Custom Code with Third-Party Libraries/Frameworks
- SIG rating thresholds, Objection: Not All Loose Coupling Solutions Increase Maintainability
- splitting classes to separate concerns, Split Classes to Separate Concerns
- tight (see tight coupling)
- to prevent no-go areas for new developers, Small, Loosely Coupled Modules Prevent No-Go Areas for New Developers
- when working on isolated parts of codebase, Small, Loosely Coupled Modules Allow Developers to Work on Isolated Parts of the Codebase
- mutual dependencies, Objection: Component Dependence Cannot Be Fixed Because the Components Are Entangled
P
- packages, components vs., Generic Names for Elements of Source Code
- parameter lists, Frameworks or Libraries Prescribe Interfaces with Long Parameter Lists
- (see also unit interfaces)
- parameter objects, How to Apply the Guideline, Objection: Parameter Objects with Large Interfaces
- perfective maintenance, The Four Types of Software Maintenance
- performance
- platform architecture, codebase volume and, Objection: Splitting the Codebase Is Impossible Because of Platform Architecture
- preventive maintenance, The Four Types of Software Maintenance
- priorities, setting, Turning the Guidelines into Practice
- private methods, unused, Unused private methods
- productivity measures
- programming languages
- project failures, codebase volume and, A Project That Sets Out to Build a Large Codebase Is More Likely to Fail
R
- rainy-side testing, General Principles for Writing Good Unit Tests
- refactoring
- and unit complexity, Objection: Splitting Up Methods Does Not Reduce Complexity
- and unit interfaces, Refactoring Large Interfaces Does Not Improve My Situation
- and unit size, Using Refactoring Techniques to Apply the Guideline-Refactoring technique: Replace Method with Method Object
- difficulties as maintainability issue, This Unit Is Impossible to Split Up
- Extract Method technique, Refactoring technique: Extract Method, How to Apply the Guideline
- Extract Superclass technique, The Extract Superclass Refactoring Technique-The Extract Superclass Refactoring Technique, The Extract Superclass Refactoring Technique
- for improved maintainability, Leave No Trace
- Introduce Parameter Object pattern, Keep Unit Interfaces Small
- Replace Method with Method Object technique, Refactoring technique: Replace Method with Method Object-Refactoring technique: Replace Method with Method Object, How to Apply the Guideline
- to reduce codebase, Technical Measures
- referral, reuse by, Technical Measures
- regression, A Good Component Balance Better Isolates Maintenance Effects, Objection: Splitting the Codebase Is Impossible Because of Platform Architecture, Automate Tests-How to Apply the Guideline, Objection: We Still Need Manual Testing
- regression tests
- repeatability, test automation and, Automated Testing Makes Testing Repeatable
- Replace Conditional with Polymorphism pattern, Dealing with Conditional Chains
- Replace Method with Method Object refactoring technique, Refactoring technique: Replace Method with Method Object-Refactoring technique: Replace Method with Method Object, How to Apply the Guideline
- Replace Nested Conditional with Guard Clauses pattern, Dealing with Nesting
- reuse
S
- scientific software, Misunderstanding: Maintainability Is Industry-Dependent
- scope creep, Functional Measures
- Selenium, How to Apply the Guideline
- self-taught developers, Who Should Read This Book
- separation of concerns (see concerns, separation of)
- SIG (Software Improvement Group), About the Software Improvement Group
- SIG/TÜViT Evaluation Criteria Trusted Product Maintainability
- codebase volume rating thresholds, Objection: Splitting the Codebase Is Impossible Because of Tight Coupling
- component balance rating thresholds, See Also
- component independence rating thresholds, See Also
- duplication rating thresholds, See Also
- metrics, Who Should Read This Book, How SIG Measures Maintainability-How SIG Measures Maintainability
- module coupling rating thresholds, Objection: Not All Loose Coupling Solutions Increase Maintainability
- star ratings, Rating Maintainability-Rating Maintainability
- testability rating thresholds, See Also
- unit complexity rating thresholds, See Also
- unit interface rating thresholds, See Also
- unit size rating thresholds, See Also
- simple units (see unit complexity)
- single responsibility principle
- smells, Boy Scout rules for preventing, How to Apply the Guideline-Rule 7: Leave No Badly Handled Exception Behind
- (see also large class smell)
- SoapUI, How to Apply the Guideline
- Software Improvement Group (see SIG)
- Software Risk Monitoring service, About the Software Improvement Group
- SQL queries, This Unit Is Impossible to Split Up
- standardization of functionality, Functional Measures
- star rating system, Rating Maintainability
- string literals, Duplication in String Literals Is Unavoidable and Harmless
- stub (test stub), General Principles for Writing Good Unit Tests
- sunny-side testing, General Principles for Writing Good Unit Tests
- system complexity, codebase volume and, Objection: System Complexity Forces Code Copying
- system properties, Who Should Read This Book
T
- test automation, Automate Tests-See Also
- advantages of, Motivation-Writing Tests Make You Write Better Code
- and code improvement, Writing Tests Make You Write Better Code
- and code predictability, Automated Testing Makes Code Predictable
- and continued need for manual testing, Objection: We Still Need Manual Testing
- and documentation, Tests Document the Code That Is Tested
- and efficient development, Automated Testing Makes Development Efficient
- and jUnit tests, Getting Started with jUnit Tests-Getting Started with jUnit Tests
- and productivity measures, Objection: I Am Not Allowed to Write Unit Tests
- and repeatability, Automated Testing Makes Testing Repeatable
- and SIG testability rating thresholds, See Also
- applying guidelines for, How to Apply the Guideline-Measure Coverage to Determine Whether There Are Enough Tests
- common objections to, Common Objections to Automating Tests
- general principles for writing good unit tests, General Principles for Writing Good Unit Tests-General Principles for Writing Good Unit Tests
- in low-coverage situation, Objection: Why Should We Invest in Unit Tests When the Current Coverage Is Low?
- measuring coverage of, Measure Coverage to Determine Whether There Are Enough Tests
- test stub, General Principles for Writing Good Unit Tests
- test-driven development (TDD), Writing Tests Make You Write Better Code
- testability
- tests/testing
- third-party libraries/frameworks (see frameworks) (see libraries)
- throughput code, Motivation
- throughput, component independence and, Objection: Throughput Is a Requirement
- tight coupling
- Type 1 clones, Types of Duplication
- Type 2 clones, Types of Duplication
U
- unhappy flow testing, General Principles for Writing Good Unit Tests
- unit
- unit complexity
- advantages of minimizing, Motivation
- and conditional chains, Dealing with Conditional Chains-Dealing with Conditional Chains
- and method splitting, Objection: Splitting Up Methods Does Not Reduce Complexity
- and nesting, Dealing with Nesting-Dealing with Nesting
- and testing, Simple Units Are Easier to Test
- and unit modification, Simple Units Are Easier to Modify
- applying guidelines for, How to Apply the Guideline-Dealing with Nesting
- common objections to minimizing, Common Objections to Writing Simple Units of Code
- in complex domains, Objection: High Complexity Cannot Be Avoided
- minimizing, Write Simple Units of Code, See Also
- SIG rating of, See Also
- unit guidelines
- unit interfaces
- advantages of minimizing size of, Motivation
- and libraries/frameworks with long parameter lists, Frameworks or Libraries Prescribe Interfaces with Long Parameter Lists
- and method modification, Methods with Small Interfaces Are Easier to Modify
- and parameter objects, Objection: Parameter Objects with Large Interfaces
- applying guidelines for, How to Apply the Guideline-How to Apply the Guideline
- common objections to minimizing size of, Common Objections to Keeping Unit Interfaces Small
- ease of understanding, Small Interfaces Are Easier to Understand and Reuse
- hiding specialized implementations behind, Hide Specialized Implementations Behind Interfaces-Hide Specialized Implementations Behind Interfaces
- Java interfaces and loose coupling, Objection: Java Interfaces Are Not Just for Loose Coupling
- minimizing size of, Keep Unit Interfaces Small-See Also
- refactoring, Refactoring Large Interfaces Does Not Improve My Situation
- reuse, Small Interfaces Are Easier to Understand and Reuse
- SIG rating thresholds, See Also
- unit size
- advantages of minimizing, Motivation
- and ease of analysis, Short Units Are Easy to Analyze
- and improper formatting, Guideline Encourages Improper Formatting
- and reuse, Short Units Are Easy to Reuse
- and testability, Short Units Are Easy to Test
- applying guidelines to, How to Apply the Guideline-Refactoring technique: Replace Method with Method Object
- common objections to writing short units, Common Objections to Writing Short Units-There Is No Visible Advantage in Splitting Units
- difficulty of optimizing by splitting units, This Unit Is Impossible to Split Up
- in real-world systems, Guideline Encourages Improper Formatting
- minimizing, Write Short Units of Code-See Also
- perceived lack of advantage in splitting units, There Is No Visible Advantage in Splitting Units
- quantity of units and performance, Objection: Having More Units Is Bad for Performance
- reading code when spread out over multiple units, Objection: Code Is Harder to Read When Spread Out
- refactoring techniques for guideline applications, Using Refactoring Techniques to Apply the Guideline-Refactoring technique: Replace Method with Method Object
- SIG thresholds for, See Also
- when extending unit with new functionality, When Extending a Unit with New Functionality
- when writing new unit, When Writing a New Unit
- unit tests
- unit-level code, clean coding and, Rule 1: Leave No-Unit Level Code Smells Behind
- unreachable code, Unreachable code in methods
- unused private methods, Unused private methods
- utility code, module coupling and, Objection: High Fan-in of Utility Classes Is Unavoidable
..................Content has been hidden....................
You can't read the all page of ebook, please click
here login for view all page.