Analyze code to suggest and add Design by Contract specifications (preconditions, postconditions, invariants, semantic invariants) in any language. Trigger on: "Design by Contract", "DBC", "preconditions", "postconditions", "class invariants", "code contracts", "formal specifications", "document assumptions", "add contracts", "make this function safer", "define what this function guarantees", "add assertions to document behavior", Bertrand Meyer, Eiffel contracts, or when discussing invariants that should always hold. Do NOT skip for non-Eiffel code — DBC applies everywhere via assertions, type guards, properties.
92
90%
Does it follow best practices?
Impact
95%
1.05xAverage score across 5 eval scenarios
Passed
No known issues
How to express contracts in different languages.
| Language | Mechanism |
|---|---|
| Python | assert statements, pydantic validators, dataclass invariants, icontract or deal libraries |
| TypeScript/JavaScript | assert/invariant functions, type guards, io-ts or zod schemas, class validation methods |
| Java | assert statements, Objects.requireNonNull, Preconditions (Guava), Bean Validation |
| C# | System.Diagnostics.Contracts, Debug.Assert, ArgumentException |
| Rust | debug_assert!, assert!, type system (e.g., NonZeroUsize), Option/Result |
| Go | panic for invariant violations (crash early), errors for expected errors |
| Clojure | :pre / :post conditions in defn, clojure.spec |
| Elixir | Guard clauses for dispatch, with for validation chains |
| Ruby | Custom assert methods, Rails validations, Sorbet types |
| C++ | assert, static_assert, noexcept specifications |
| Haskell | Type system, smart constructors, liquid-haskell refinement types |
| Any language | Comments documenting the contract (as formal as possible), unit tests that enforce contract (especially property-based tests) |