Prompt
Adopt a “review-first” style for complex C code: keep control flow and conditions small, make side effects explicit, and avoid duplication.
Key rules: 1) Split overly long conditionals
- Avoid putting multiple parsing/validation calls into a single large
if. - Prefer sequential guarded
ifblocks.
2) Use guard clauses and shared cleanup
- Reduce indentation by returning early on validation failures.
- When there are multiple paths (e.g., fast-path vs fallback), share cleanup via a single label or helper, so the structure stays flat.
3) Prefer explicit branching for special modes
- Don’t hide unusual behavior inside another branch (e.g., special aggregate handling mixed into SUM). Use
else ifwith a clear name/comment.
4) Extract duplicated “finalization”/side-effect logic
- If multiple commands repeat the same update/notification/keyspace-finalization logic, move it to a helper to keep behavior consistent (and reduce the chance of diverging implementations).
5) Enforce consistent formatting
- Always use braces for multi-line
if/for/whilebodies. - For multi-line conditions, wrap the controlled block with
{}for scan-ability.
6) Use named constants instead of magic numbers
- Prefer existing shared constants (e.g., buffer sizing macros) over local ad-hoc values.
Example (splitting long validation):
// Before (hard to read)
if (parseA()!=C_OK || parseB()!=C_OK || parseC()!=C_OK) return;
// After (reviewable)
if (parseA() != C_OK) return;
if (parseB() != C_OK) return;
if (parseC() != C_OK) return;
Example (shared cleanup to reduce indentation):
if (fast_path_ok) {
goto done;
}
// fallback path
done:
cleanup_common();
return;
Applying these consistently makes diffs easier to scan, reduces reviewer cognitive load, and prevents subtle behavioral drift across similar command implementations.