# Skill: Generate readable code with descriptive names, DRY, KISS, and named constants

> Apply this skill when generating or reviewing any code to ensure it stays maintainable -- readable by both the developer and the agent on the next edit, with no magic numbers, no copy-paste, and no speculative complexity.

Source: sodigi·learn -- vibecoding/ponyatnyy-kod · https://sodigi.io/learn/vibecoding/ponyatnyy-kod

## When to use
- Generating any new function, module, or component for a project.
- Reviewing agent-produced code before accepting it -- check for mystery names and duplicated logic.
- Refactoring existing code that is hard to modify without breaking adjacent parts.
- Before adding a feature -- if the existing code is unreadable, clean it first.

## Core rules
- Variable and function names must explain what they contain or do without any comment. "totalRevenue" is correct; "x" is not.
- Function names use verb + subject: "fetchMarketData", "calculateSimilarity", "isValidEmail".
- Never duplicate the same logic in more than one place (DRY). Extract it into a shared function.
- Use the simplest solution that works (KISS). Do not add abstractions or features that are not required right now.
- Do not build features that "might come in handy" -- build only what is explicitly asked for (YAGNI).
- Replace every bare number in the code with a named constant (MAX_RETRIES = 3, DISCOUNT_THRESHOLD = 5000).
- Functions should do one thing. If a function name requires "and" to describe it, split it.

## Procedure
1. Before generating, list the data types and operations involved. Choose descriptive names up front.
2. Write functions with verb+subject names. Keep each function focused on a single responsibility.
3. After the first pass, scan for any repeated logic blocks. Extract duplicates into a shared helper.
4. Find every bare number. Give each one a named constant at the top of the file or in a config module.
5. Remove any code that was added "just in case" but is not called anywhere.
6. Read each function name aloud. If it does not immediately communicate what the function does, rename it.
7. Provide a brief explanation of where shared logic lives and where constants are defined.

## Ready-to-use prompt
```
Write readable code following these rules:

1. Give variables and functions descriptive names. Not x and tmp, but names
   like cartTotal, applyDiscount, isEligibleForDiscount. Functions should be
   named as a verb plus what they operate on.

2. Do not duplicate logic. Any calculation used in more than one place must
   live in a single shared function called from everywhere, not copied.

3. Do not hardcode bare numbers. Pull thresholds, limits, and percentages into
   named constants at the top of the file so they are easy to change in one
   place.

4. Keep it as simple as possible. No "future-proofing" that was not asked for.

After the code, briefly explain where each constant is defined and where the
shared logic lives.
```

## Pitfalls
- Accepting names like "x", "tmp", "data2", "flag" without pushing back -- they become unsolvable mysteries a month later.
- Tolerating copy-paste: the same block in three places means three places to fix when requirements change, and one will always be forgotten.
- Leaving bare numbers ("500", "3", "86400") in the code -- their meaning is unknown to the next reader, including the agent on the next edit.
- Allowing speculative abstraction ("I might need this later") -- extra code is extra surface area to misunderstand and break.
- Thinking readable code is only for human programmers -- the agent reads code too, and unclear names make it burn more tokens and make more mistakes.