bauhaus-code

name	bauhaus-code
description	Remove accidental complexity. Design software that feels inevitable through purposeful structure, honest abstractions, and the smallest implementation that satisfies the requirements.
license	MIT

Bauhaus Code

Design code as a clear, useful object.

Principles

• Purpose before structure — understand what the code must do before choosing abstractions.
• Remove the unnecessary — delete indirection, configuration, and flexibility without a present use.
• Make form reveal function — names, types, and module boundaries should explain the system.
• Prefer simple geometry — use small functions, flat control flow, and explicit data shapes.
• Use honest materials — do not hide I/O, mutation, latency, failure, or external dependencies.
• One element, one job — each function, class, and module should have a clear responsibility.
• Compose from standard parts — prefer stable language features and ordinary interfaces over bespoke machinery.
• Repeat deliberately — tolerate small duplication when abstraction would obscure the pattern.
• Create hierarchy through proportion — important concepts receive prominent names and boundaries; minor details stay local.
• Design the whole system — optimize for the reader's path through the code, not isolated cleverness.
• Build for use — correctness, maintainability, and operability outrank novelty.
• Let constraints shape the design — do not fight the runtime, language, framework, or deployment environment.

Working Method

1. State the required behavior in plain language.
2. Identify the smallest useful data model.
3. Write the direct implementation.
4. Make failure visible.
5. Remove accidental complexity.
6. Extract only patterns that already repeat.
7. Verify behavior at the system boundary.

Review Questions

• What purpose does this element serve?
• Can the behavior be understood without tracing hidden machinery?
• Is the data shape clearer than the control flow?
• Does an abstraction remove complexity or merely relocate it?
• Are side effects visible at the point they occur?
• Is the code using the language directly?
• Can anything be deleted without losing required behavior?
• Would a new reader know where to make the next change?

Avoid

• speculative abstractions
• decorative architecture
• generic frameworks for one concrete case
• hidden global behavior
• configuration without meaningful variation
• wrapper layers that only rename existing APIs
• clever compression
• premature extensibility
• comments that compensate for unclear code

Output Style

When proposing code:

• lead with the simplest viable design
• use concrete names
• keep interfaces narrow
• show data shapes explicitly
• distinguish required complexity from accidental complexity
• call out what was intentionally not abstracted
• prefer deletion over addition
• prefer one clear recommendation over many equivalent options

Standard

The result should feel inevitable: no more structure than the problem requires, and no less clarity than the reader deserves.