liveBook · Manning

Complexity

As explained in "Looks Good to Me"

The degree to which a code structure has numerous or intricate elements and relationships that make it harder to understand or change.

Complexity makes code harder to understand, follow, and change. During review, it can appear as giant classes, too many layers for a simple method, excessive abstraction, or temporary workarounds whose original intent is unclear. section 4.4.4 section 3.3.1

Use these questions to decide whether complexity deserves attention:

  • Can another developer understand the code now and when revisiting it later? section 3.3.1
  • Is the structure human-friendly and straightforward, or must readers jump through layers and abstractions to follow a simple method? section 4.4.4 section 3.3.1
  • Do workaround or temporary parts need a more permanent solution? section 3.3.1
  • If the same complexity problem escapes linting or prechecks repeatedly, consider a new linting rule or a precheck adjustment after the third recurrence. section 4.4.4

How "Looks Good to Me" covers it

How deep it goes
Defines review questions and recognizable structural symptoms, then stops short of prescribing a universal refactoring method.
Examples
Uses giant classes, excessive layers, over-abstraction, unclear intent, and temporary workarounds as review examples.
What it assumes
Assumes familiarity with code review and maintainable code while inviting the team to define its own review priorities.
What you can do after
Evaluate code during review and identify opportunities to make it clearer and easier to change.
How it connects
Connects complexity with code review, readability, maintainability, linting, prechecks, and automation.

Also explained in

Compare how 13 books explain complexity →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of "Looks Good to Me". The section links point to the parts of the book it draws on.