snapshot of https://github.com/marmelab/atomic-crm.git (main, 2026-09-18; blobs > 131072B omitted)
Some checks failed
✅ Check / 🔬 ESLint (push) Failing after 21s
✅ Check / 🏷️ Typecheck (push) Failing after 11s
✅ Check / 🔎 Test (push) Failing after 11s
✅ Check / e2e-test (push) Failing after 11s
✅ Check / 🔨 Build (push) Failing after 11s
🚀 Deploy / 🚀 Deploy (doc) (push) Failing after 12s
🚀 Deploy / 🚀 Deploy (demo) (push) Failing after 12s
🚀 Deploy / 🚀 Deploy (supabase) (push) Failing after 18s
Some checks failed
✅ Check / 🔬 ESLint (push) Failing after 21s
✅ Check / 🏷️ Typecheck (push) Failing after 11s
✅ Check / 🔎 Test (push) Failing after 11s
✅ Check / e2e-test (push) Failing after 11s
✅ Check / 🔨 Build (push) Failing after 11s
🚀 Deploy / 🚀 Deploy (doc) (push) Failing after 12s
🚀 Deploy / 🚀 Deploy (demo) (push) Failing after 12s
🚀 Deploy / 🚀 Deploy (supabase) (push) Failing after 18s
This commit is contained in:
71
.claude/rules/coding-style.md
Normal file
71
.claude/rules/coding-style.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
paths: []
|
||||
---
|
||||
|
||||
# Coding Style
|
||||
|
||||
## Immutability (critical)
|
||||
|
||||
Always create new objects, never mutate existing ones:
|
||||
|
||||
- Wrong: modify original object in-place
|
||||
- Correct: return a new copy with the change applied
|
||||
|
||||
Rationale: prevents hidden side effects, makes debugging easier,
|
||||
enables safe concurrency.
|
||||
|
||||
## Core principles
|
||||
|
||||
KISS — prefer the simplest solution that works. Optimize for clarity
|
||||
over cleverness.
|
||||
|
||||
DRY — extract repeated logic into shared functions. Introduce
|
||||
abstractions when repetition is real, not speculative.
|
||||
|
||||
YAGNI — do not build features before they are needed. Start simple,
|
||||
refactor when the pressure is real.
|
||||
|
||||
Scope discipline: implement exactly what the task asks, no more. An
|
||||
adjacent problem you notice (a nearby bug, a tempting refactor, missing
|
||||
tests elsewhere) is REPORTED, never fixed in the same change. Never expand
|
||||
scope silently.
|
||||
|
||||
## File organization
|
||||
|
||||
Many small files over few large files:
|
||||
- 200-400 lines typical, 800 max
|
||||
- High cohesion, low coupling
|
||||
- Organize by feature/domain, not by type
|
||||
- Extract utilities from large modules
|
||||
- Grow the file *count*, not the file: when an edit would push a file past
|
||||
the ~400-line typical ceiling, extract a new focused module instead of
|
||||
appending to the existing one
|
||||
|
||||
## Error handling
|
||||
|
||||
- Handle errors explicitly at every level
|
||||
- User-facing code: provide friendly error messages
|
||||
- Server-side: log detailed error context
|
||||
- Never silently swallow errors
|
||||
|
||||
## Input validation
|
||||
|
||||
- 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)
|
||||
|
||||
## Naming conventions
|
||||
|
||||
- Variables and functions: camelCase
|
||||
- Booleans: is, has, should, or can prefix
|
||||
- Interfaces, types, components: PascalCase
|
||||
- Constants: UPPER_SNAKE_CASE
|
||||
- Custom hooks: camelCase with use prefix
|
||||
|
||||
## Code smells to avoid
|
||||
|
||||
- Deep nesting (>4 levels) — use early returns
|
||||
- Magic numbers — use named constants
|
||||
- Long functions (>50 lines) — split into focused pieces
|
||||
- Large files (>800 lines) — extract modules
|
||||
Reference in New Issue
Block a user