# Coding Discipline

> Enforces coding discipline: constants over magic values, enums over boolean params, breathing room and purposeful comments, private-by-default visibility, layered abstractions, minimal diffs, strict layer boundaries, always-braces if, and test-first bug fixes. Use when writing or editing code, reviewing changes, or when the user asks about code style or clean code practices.

- Skill: `snowbridge/coding-discipline` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add snowbridge/coding-discipline`
- Raw SKILL.md: https://api.skillmd.com/api/skills/snowbridge/coding-discipline/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Snowbridge (https://skillmd.com/u/snowbridge)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/snowbridge/coding-discipline

---


# Coding discipline

## When to apply

- Writing or editing code in any language
- Code review or refactoring
- User asks about code style, clean code, or coding discipline

## Principles

- Avoid magic numbers and strings by extracting recurring or meaningful values into descriptive constants (const) or enums. Keep self-explanatory, one-off values inline to avoid clutter. If a value comes from a spec (e.g. HTTP 200 OK), use a constant regardless.

- Use enums instead of booleans for function parameters.

- Let the reader of the code breathe. Add empty lines between logical blocks of code.

- Add a small, to the point, comment to explain *what* the block does and *why*. Use examples when possible. Propose ASCII drawings to explain complete systems.

- Treat member visibility changes as a breaking design shift. Keep all fields and functions private unless external access is strictly required by the design. Prompt the user for explicit approval before changing any access modifier from private to internal or public.

- Program to levels of abstraction. Lower-level mechanics (e.g., raw hardware I/O, sector parsing, direct socket streams) must be encapsulated in a dedicated driver/abstraction layer. Expose clean, high-level APIs to the rest of the application so calling code works with domain concepts, not raw implementation details.

- Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature.

- Strictly adhere to the layered boundary hierarchy: each layer may only communicate with its immediate neighbor directly below it. Never "punch holes" through layers (e.g., controllers or UI components must never directly call database queries, raw hardware drivers, or low-level network clients; always route through the intermediate service/abstraction layer).

- Always use {}, even on a one-line "if" statement.

- If the prompt indicates that a bug is being fixed, don't write the fix right away. First write the test. Observe it failing. Then write the fix. And observe the test passing.

## Workflows

### Visibility gate

Before widening any access modifier, stop and ask the user:

```text
⚠️ Visibility change requested
Current: private <member>
Proposed: internal|public <member>
Reason: <why external access is required>
Confirm before applying.
```

Do not apply the change until the user explicitly approves.

### Bug-fix TDD

When the task is a bug fix:

```text
- [ ] Write a test that reproduces the bug
- [ ] Run the test — confirm failure
- [ ] Implement the minimal fix
- [ ] Run the test — confirm pass
```

### Layer boundary

Each layer talks only to its immediate neighbor below:

```text
UI / CLI ──► Service / Use-case ──► Domain ──► Driver / IO
     ✗ never skip intermediate layer
```

## Additional resources

- For good/bad code examples, see [examples.md](examples.md)