deslop-code

Deslop code

What counts as AI slop

• Redundant or obvious comments — comments that restate what the code does line-by-line.
• Overly verbose names — e.g. userAuthenticationTokenHandler where authToken suffices.
• Unnecessary abstractions — wrappers, helpers, or interfaces used only once.
• Excessive defensive code — try/catch or null checks that add no real safety.
• Generic filler phrases — "Here we…", "This function is responsible for…", "Note that…".
• Over-modularization — tiny one-use functions that hurt readability.
• Boilerplate that doesn't help — empty docblocks, type annotations that duplicate obvious types.
• Inconsistent style — mixed quote styles, spacing, or naming in the same file.

Respect project style (.editorconfig, ESLint, Prettier, existing patterns). If the user or project has explicit style rules, follow those over this skill.

Removal checklist

Apply in order; re-scan after edits.

1. Comments
   • Remove comments that only repeat the code (e.g. // Loop through items above a for loop).
   • Remove or shorten generic docblocks that add no information.
   • Keep comments that explain why, non-obvious contracts, or real gotchas.
2. Names
   • Shorten verbose variables/functions to clear, idiomatic names.
   • Use project naming conventions (camelCase vs snake_case, etc.).
3. Structure
   • Inline one-off helpers used in a single place if it improves readability.
   • Remove unused parameters, imports, and dead code.
   • Prefer language idioms over step-by-step code (.map/.filter vs manual loops where idiomatic).
4. Defensive code
   • Remove try/catch that only rethrows or logs without adding value.
   • Remove redundant null/undefined checks that can't occur in context.
5. Style
   • One consistent quote style per file.
   • Consistent spacing and line length (match project or 80/100/120).
   • No trailing whitespace or unnecessary blank lines.