PMI Sites
Register
Disciplined Agile
Search

    Code Qualities

    Code Qualities

    Scott Bain gives an overview of essential code qualities. Scott is a senior Disciplined Agile technical trainer and thought leader. This is part of a series of recorded presentations brought to you by PMI Disciplined Agile.

    Related Resources

     

    Quality Description Principles Practices Pathologies
    Cohesion
    • All of the elements in a class or method are related to each other.
      • A "strongly cohesive class is one where all of its internal aspects (state, functions, relationships) are about fulfilling the same, single responsibility.
      • A strongly cohesive method is about implementing a single function aspect of a class's responsibility
    • Poor cohesion is termed weak.
    • Single Responsibility Principle
    • Programming by Intention
    • Up-Front Testing
    • Commonality-Variability Analysis
    • Large classes: A Large class may be large because it has more than one responsibility.
    • Long Methods: A long method may contain more than one function. 
    • Difficulty naming: It is hard to give a class or method an intention-revealing name if it does many unrelated things.
    • Large Tests: If a class contains more than one responsibility, the test for that class must test them all, and all of their possible combinations. This often results in tests that are significantly longer than the classes they test.
    Coupling
    • The dependencies between this class and other classes is logical, obvious, and minimal.
      • Identity Coupling exists when one type couples to the existence of another type.
      • Representational Coupling exists when one type couples to the interface of another type.
      • Inheritance Coupling is the coupling that is created between a derived class and its base class.
      • Subclass Coupling exists when one type is coupled to the fact that another type is polymorphic, not simple.
    • Good coupling is often termed loose, but we prefer intentional.
    • Bad coupling is often termed tight, but we prefer accidental.
    • Encapsulate by policy, reveal by need.
    • Design to Interfaces.
    • Unexpected side-effects
    • Slow, complex tests
    Redundancy
    • Anything that could change (read: anything) should be in a single place in the system.
      • State
      • Function
      • Rules
      • Object creation (memory allocation)
      • Relationships
      • etc...
    • One Rule, One Place
    • Eliminate (refactor) duplication immediately
    • Duplication in client objects
    • Duplication in tests