write-review-elixir

Review Elixir code and make sure it does not violate these anti patterns.

Elixir Anti-Patterns Reference

Quick reference guide for Elixir anti-patterns with practical do/don't examples.

Quick Reference Checklist

Code Quality

• [ ] Avoid redundant comments; use clear names and module attributes
• [ ] Keep with else clauses simple; normalize errors in helpers
• [ ] Extract pattern/guard vars in signatures, body vars in body
• [ ] Never create atoms dynamically from user input
• [ ] Group related parameters; keep parameter lists short
• [ ] Use your package namespace, not others'
• [ ] Use static access (.) for required fields, dynamic ([]) for optional
• [ ] Fail fast with pattern matching; avoid defensive nil propagation
• [ ] Use strict boolean operators (and/or/not) for booleans
• [ ] Keep structs under 32 fields

Design

• [ ] Create separate functions instead of options changing return types
• [ ] Use atoms for state instead of multiple booleans
• [ ] Use case/pattern matching, not try/rescue for control flow
• [ ] Use structs/maps for domain concepts, not primitives
• [ ] Separate unrelated functionality into distinct functions
• [ ] Use function parameters, not application config for libraries

Processes

• [ ] Use processes for concurrency/state, not code organization
• [ ] Centralize all process interaction in one module
• [ ] Extract data before sending to processes
• [ ] Always start processes within supervision trees

Macros

• [ ] Use Macro.expand_literals/2 to reduce compile-time deps
• [ ] Delegate bulk validation to functions, not expanded code
• [ ] Only use macros when truly necessary
• [ ] Prefer explicit import over use
• [ ] Use module literals, not dynamic construction
• [ ] Debug with mix xref trace

---

More concreate DO's and DONT's are available in ./REFERENCE.md Make sure to read that.

Resources

• Official Elixir Anti-Patterns Guide
• Design Anti-Patterns
• Process Anti-Patterns
• Macro Anti-Patterns

Additional Instructions

Use mix xref trace path/to/file.ex to verify tracking. Use mix credo to get more quality issues.

First Create a list of all the issues you find. Store them in PATTERN-VIOLATIONS.md

Then group all issues by complexity and similarity and create a bundled plan to tackle the issues you found. Store the plan in PATTERN-PLAN.md in the root.

Suggest which fixes could be easily done by an LLM like claude code. Ask the user whether to fix the issues, if the users aggrees:

Group Tasks into groups that are related/dependent of each other and dispatch parallel agents for each group.