Static Code Analysis with Eastwood and Kibit

Static analysis: Automated inspection of source code without executing it, used to catch likely mistakes, suspicious constructs, and maintainability problems early.

Modern Clojure teams usually start with clj-kondo for always-on linting, then reach for Eastwood or Kibit when they want additional analyzer-driven warnings or style suggestions. That is the right mental model for this page: Eastwood and Kibit are useful complements, not complete substitutes for tests or broader linting.

Eastwood and Kibit Solve Different Problems

Eastwood is oriented toward warnings about suspicious or potentially incorrect code. Kibit is oriented toward suggesting simpler or more idiomatic rewrites.

That difference matters:

• Eastwood is often about correctness and semantics
• Kibit is often about code shape and readability

If you treat both as the same kind of tool, you either ignore useful warnings or create unnecessary style churn.

Fit Them into the Modern Lint Story

A pragmatic stack often looks like this:

• clj-kondo for broad, fast linting in editors and CI
• Eastwood for deeper analyzer-based checks
• Kibit for optional simplification suggestions
• tests for actual behavioral confidence

This ordering matters because not every lint tool should be run with the same frequency or enforced with the same severity.

Eastwood Is Best for Suspicious Constructs

Eastwood tends to add value when it catches things such as:

• unused or shadowed bindings
• suspicious type-hint or reflection situations
• odd macro or analyzer interactions
• code shapes that suggest a likely mistake

Treat those findings as review prompts. Some are genuine bugs. Some are design smells. Some are false positives. The useful habit is to evaluate them with technical judgment rather than blindly suppress or blindly obey.

Kibit Is Best for Simplification Suggestions

Kibit is more about “this could be written more clearly” than “this is probably broken.” For example, it may suggest simplifying a conditional or replacing a verbose pattern with a more idiomatic core form.

That is useful when:

• the team wants to reduce noisy patterns
• newer contributors are learning idiomatic shapes
• you want review help on clunky code

It is less useful when style churn outweighs the benefit. Not every equivalent rewrite deserves a commit.

Avoid Turning Lint into Noise

Static analysis gets ignored when:

• everything is enforced with the same severity
• the tool output is not reviewed and curated
• false positives accumulate
• stylistic suggestions block important work

A better policy is:

• fail CI for a small set of trusted checks
• surface broader warnings for review
• suppress deliberately and narrowly when needed
• revisit suppressions occasionally

Static Analysis Does Not Replace Tests

Lint tools can suggest that something is suspicious. They cannot tell you whether the behavior is correct under real inputs, real state transitions, or real integration boundaries.

That is why the tools work best together:

• linting for likely mistakes and maintainability issues
• tests for behavior
• CI for continuous feedback

Practical Heuristics

Use Eastwood for warnings worth human attention. Use Kibit for suggestions worth considering, not obeying mechanically. Keep the baseline lint story clear, and do not confuse static-analysis noise with actual correctness assurance.

Ready to Test Your Knowledge?