skalanux/puntofiles/code-review

Code review

Quick start

If the user has not provided a file or diff, ask:

"Please share the code you'd like reviewed — paste it directly, upload a

file, or provide a git diff."

This is a first-pass, language-agnostic review. It surfaces issues common across all languages before any in-depth language-specific analysis.

Input handling

Review passes

Run all six passes on every review. Report findings grouped by severity.

1. Logic errors

• Infinite or unreachable loops (missing exit condition, invariant that

never changes)

• Off-by-one errors in indices, ranges, or pagination
• Null / undefined dereferences that can crash at runtime
• Dead code that can never be reached
• Incorrect boolean logic (de Morgan violations, short-circuit mistakes)
• Race conditions or incorrect execution-order assumptions

2. Operation ordering

Flag sequences where order creates correctness or reliability risk:

• Side effects before guards (e.g. sending an email before committing a

DB transaction, charging a card before persisting the order)

• Mutations or writes before validation of input
• Resource acquisition without matching release in all exit paths

(locks, file handles, connections)

• Audit logging placed after the action it should record

3. Bad practices

• Raw request / user input used without sanitisation or validation
• Overly broad exception handling that silently swallows errors
• Missing error handling on I/O, network, or DB calls
• Unsafe type coercion or implicit casting between incompatible types
• Strict equality not enforced where type safety matters

(e.g. == instead of === in JS/TS, or comparing values of different types without explicit conversion)

• Functions with hidden side effects or unclear single responsibility

4. Security

• SQL injection: string concatenation or interpolation used to build

queries instead of parameterised queries / prepared statements

• Hardcoded secrets, credentials, tokens, or environment-specific values
• Exposed sensitive data in logs, error messages, or API responses

5. Magic strings and values

• Unnamed string or numeric literals used inline instead of named

constants (e.g. status === "active", retries > 3, role === "admin")

• Duplicated literals that should share a single source of truth
• Suggest extracting to a constant, enum, or config value with a

descriptive name

6. Pattern improvements

Flag cases where a well-known pattern would meaningfully reduce coupling, improve testability, or clarify intent. Suggest only when the improvement is concrete and actionable — do not suggest patterns for their own sake:

• Hard-coded dependencies that could use dependency injection (class

instantiates its own collaborators, making unit testing difficult)

• Repeated conditional chains that could be replaced with a strategy or

map lookup

• Procedural code that obscures a domain concept a named abstraction

would clarify

• When exploring the repo reveals that a dependency is always used in the

same way, note if a factory or builder would remove duplication

Output format

For each finding:

• Location — file name and line number, or function / block if

unavailable

• Severity — critical / high / medium / low
• Pass — which of the six passes caught it
• Description — what the problem is and why it matters
• Fix — a corrected snippet or concrete actionable suggestion

Group all findings by severity (critical first). End with a short summary of overall quality and the top 1–3 issues to address immediately.

Severity guide