👨‍💻
Software Engineering
Tidy First?: A Personal Exercise in Empirical Software Design
Tidy First?: A Personal Exercise in Empirical Software Design
  • Tidy First?
  • Foreword
  • Preface
  • Part 1: Tidyings
    • 1: Guard Clauses
    • 2: Dead Code
    • 3: Normalize Symmetries
    • 4: New Interface, Old Implementation
    • 5: Reading Order
    • 6: Cohesion Order
    • 7: Move Declaration & Initialization Together
    • 8: Explaining Variables
    • 9: Explaining Constants
    • 10: Explicit Parameters
    • 11: Chunk Statements
    • 12: Extract Helper
    • 13: One Pile
    • 14: Explaining Comments
    • 15: Delete Redundant Comments
  • Part 2: Managing
    • Coming soon
  • Part 3: Theory
    • Coming soon
Powered by GitBook
On this page
  1. Part 1: Tidyings

6: Cohesion Order

You read some code and realize that to make the behavior change, you need to change several widely dispersed spots in the code. What should we do?

Reorder the code so elements requiring change are adjacent.

Cohesion order applies to files, directories, and repositories.

  • Files: If two routines are coupled, put them next to each other.

  • Directories: If two files are coupled, put them in the same directory.

  • Repositories: Put coupled code in the same repository.

Or, should we decouple? Yes, if we can! But it may not be feasible, for various reasons:

  • Intellectual stretch (we don't know how to do it yet)

  • Time/money stretch (we could, but you can't afford to take the time just now)

  • Relationship stretch (the team has taken as much change as it can handle right now)

Tidying can increase cohesion enough to make behavior changes easier. Sometimes the increased clarity from slightly better cohesion unlocks whatever is blocking you from decoupling. Sometimes better cohesion helps you live with coupling.

Previous5: Reading OrderNext7: Move Declaration & Initialization Together

Last updated 10 days ago