Code Quality

Code quality in lazy-cuh has two parts:

• internal complexity should stay low enough that framework behavior is easy to review
• public APIs should keep common TUI tasks small and concept-light

The second point matters more for a framework. A function can have excellent cyclomatic complexity while the API still forces app authors to learn too many concepts before they can render a useful interface.

Enforced Complexity

Ruff runs on the whole repository, including examples and tests:

uv run ruff check .

The project enables Ruff’s mccabe checks with a maximum complexity of 10. This is intentionally conservative. A violation usually means one of these things:

• a dispatcher wants a table or command map
• a widget is mixing input handling, state transitions, and rendering
• an example is exposing API friction that should move into a reusable helper

Do not optimize only to satisfy the metric. Split code when it improves the model, the API, or the review surface.

API Ergonomics

For public framework design, also review the cost of common tasks:

• lines of code for a minimal app
• lines of code for a list, tree, modal, and option editor
• number of concepts introduced by each guide
• amount of app-local glue needed to keep shell state, keybars, and widgets in sync

Examples are part of the API review surface. If an example becomes large because it must manually coordinate framework primitives, prefer extracting a small reusable primitive over hiding the complexity in the example.

Practical Rule

Before adding a new abstraction, ask:

• Does it remove repeated app glue?
• Does it reduce the number of concepts needed for a common task?
• Does it keep Textual lifecycle details at the adapter boundary?
• Can it be tested as a pure model or small adapter behavior?

If the answer is no, keep the implementation local until repeated usage proves the abstraction.