Files
everything-claude-code/rules/common/coding-style.md
Hor1zonZzz 86b5a53e5d refactor(rules): restructure into common + language-specific directories
* refactor(rules): restructure rules into common + language-specific directories

- Split 8 flat rule files into common/, typescript/, python/, golang/
- common/ contains language-agnostic principles (no code examples)
- typescript/ extracts TS/JS specifics (Zod, Playwright, Prettier hooks, etc.)
- python/ adds Python rules (PEP 8, pytest, black/ruff, bandit)
- golang/ adds Go rules (gofmt, table-driven tests, gosec, functional options)
- Replace deprecated ultrathink with extended thinking documentation
- Add README.md with installation guide and new-language template

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* Fix installation commands for rules

Updated installation instructions to copy all rules to a single directory.

* docs: update README.md to reflect new rules directory structure

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

---------

Co-authored-by: Hor1zonZzz <Hor1zonZzz@users.noreply.github.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-02-05 05:58:06 -08:00

49 lines
1.4 KiB
Markdown

# Coding Style
## Immutability (CRITICAL)
ALWAYS create new objects, NEVER mutate existing ones:
```
// Pseudocode
WRONG: modify(original, field, value) → changes original in-place
CORRECT: update(original, field, value) → returns new copy with change
```
Rationale: Immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.
## File Organization
MANY SMALL FILES > FEW LARGE FILES:
- High cohesion, low coupling
- 200-400 lines typical, 800 max
- Extract utilities from large modules
- Organize by feature/domain, not by type
## Error Handling
ALWAYS handle errors comprehensively:
- Handle errors explicitly at every level
- Provide user-friendly error messages in UI-facing code
- Log detailed error context on the server side
- Never silently swallow errors
## Input Validation
ALWAYS validate at system boundaries:
- Validate all user input before processing
- Use schema-based validation where available
- Fail fast with clear error messages
- Never trust external data (API responses, user input, file content)
## Code Quality Checklist
Before marking work complete:
- [ ] Code is readable and well-named
- [ ] Functions are small (<50 lines)
- [ ] Files are focused (<800 lines)
- [ ] No deep nesting (>4 levels)
- [ ] Proper error handling
- [ ] No hardcoded values (use constants or config)
- [ ] No mutation (immutable patterns used)