coding-standards
installsforks
How to install coding-standards?
affaan-m/ecc/coding-standards
$npx -y skills add affaan-m/ECC --skill coding-standardsBaseline cross-project coding conventions for naming, readability, immutability, and code-quality review. Use detailed frontend or backend skills for framework-specific patterns.
SKILL.md
| 1 | # Coding Standards & Best Practices |
| 2 | |
| 3 | Baseline coding conventions applicable across projects. |
| 4 | |
| 5 | This skill is the shared floor, not the detailed framework playbook. |
| 6 | |
| 7 | - Use `frontend-patterns` for React, state, forms, rendering, and UI architecture. |
| 8 | - Use `backend-patterns` or `api-design` for repository/service layers, endpoint design, validation, and server-specific concerns. |
| 9 | - Use `rules/common/coding-style.md` when you need the shortest reusable rule layer instead of a full skill walkthrough. |
| 10 | |
| 11 | ## When to Activate |
| 12 | |
| 13 | - Starting a new project or module |
| 14 | - Reviewing code for quality and maintainability |
| 15 | - Refactoring existing code to follow conventions |
| 16 | - Enforcing naming, formatting, or structural consistency |
| 17 | - Setting up linting, formatting, or type-checking rules |
| 18 | - Onboarding new contributors to coding conventions |
| 19 | |
| 20 | ## Scope Boundaries |
| 21 | |
| 22 | Activate this skill for: |
| 23 | - descriptive naming |
| 24 | - immutability defaults |
| 25 | - readability, KISS, DRY, and YAGNI enforcement |
| 26 | - error-handling expectations and code-smell review |
| 27 | |
| 28 | Do not use this skill as the primary source for: |
| 29 | - React composition, hooks, or rendering patterns |
| 30 | - backend architecture, API design, or database layering |
| 31 | - domain-specific framework guidance when a narrower ECC skill already exists |
| 32 | |
| 33 | ## Code Quality Principles |
| 34 | |
| 35 | ### 1. Readability First |
| 36 | - Code is read more than written |
| 37 | - Clear variable and function names |
| 38 | - Self-documenting code preferred over comments |
| 39 | - Consistent formatting |
| 40 | |
| 41 | ### 2. KISS (Keep It Simple, Stupid) |
| 42 | - Simplest solution that works |
| 43 | - Avoid over-engineering |
| 44 | - No premature optimization |
| 45 | - Easy to understand > clever code |
| 46 | |
| 47 | ### 3. DRY (Don't Repeat Yourself) |
| 48 | - Extract common logic into functions |
| 49 | - Create reusable components |
| 50 | - Share utilities across modules |
| 51 | - Avoid copy-paste programming |
| 52 | |
| 53 | ### 4. YAGNI (You Aren't Gonna Need It) |
| 54 | - Don't build features before they're needed |
| 55 | - Avoid speculative generality |
| 56 | - Add complexity only when required |
| 57 | - Start simple, refactor when needed |
| 58 | |
| 59 | ## TypeScript/JavaScript Standards |
| 60 | |
| 61 | ### Variable Naming |
| 62 | |
| 63 | ```typescript |
| 64 | // PASS: GOOD: Descriptive names |
| 65 | const marketSearchQuery = 'election' |
| 66 | const isUserAuthenticated = true |
| 67 | const totalRevenue = 1000 |
| 68 | |
| 69 | // FAIL: BAD: Unclear names |
| 70 | const q = 'election' |
| 71 | const flag = true |
| 72 | const x = 1000 |
| 73 | ``` |
| 74 | |
| 75 | ### Function Naming |
| 76 | |
| 77 | ```typescript |
| 78 | // PASS: GOOD: Verb-noun pattern |
| 79 | async function fetchMarketData(marketId: string) { } |
| 80 | function calculateSimilarity(a: number[], b: number[]) { } |
| 81 | function isValidEmail(email: string): boolean { } |
| 82 | |
| 83 | // FAIL: BAD: Unclear or noun-only |
| 84 | async function market(id: string) { } |
| 85 | function similarity(a, b) { } |
| 86 | function email(e) { } |
| 87 | ``` |
| 88 | |
| 89 | ### Immutability Pattern (CRITICAL) |
| 90 | |
| 91 | ```typescript |
| 92 | // PASS: ALWAYS use spread operator |
| 93 | const updatedUser = { |
| 94 | ...user, |
| 95 | name: 'New Name' |
| 96 | } |
| 97 | |
| 98 | const updatedArray = [...items, newItem] |
| 99 | |
| 100 | // FAIL: NEVER mutate directly |
| 101 | user.name = 'New Name' // BAD |
| 102 | items.push(newItem) // BAD |
| 103 | ``` |
| 104 | |
| 105 | ### Error Handling |
| 106 | |
| 107 | ```typescript |
| 108 | // PASS: GOOD: Comprehensive error handling |
| 109 | async function fetchData(url: string) { |
| 110 | try { |
| 111 | const response = await fetch(url) |
| 112 | |
| 113 | if (!response.ok) { |
| 114 | throw new Error(`HTTP ${response.status}: ${response.statusText}`) |
| 115 | } |
| 116 | |
| 117 | return await response.json() |
| 118 | } catch (error) { |
| 119 | console.error('Fetch failed:', error) |
| 120 | throw new Error('Failed to fetch data') |
| 121 | } |
| 122 | } |
| 123 | |
| 124 | // FAIL: BAD: No error handling |
| 125 | async function fetchData(url) { |
| 126 | const response = await fetch(url) |
| 127 | return response.json() |
| 128 | } |
| 129 | ``` |
| 130 | |
| 131 | ### Async/Await Best Practices |
| 132 | |
| 133 | ```typescript |
| 134 | // PASS: GOOD: Parallel execution when possible |
| 135 | const [users, markets, stats] = await Promise.all([ |
| 136 | fetchUsers(), |
| 137 | fetchMarkets(), |
| 138 | fetchStats() |
| 139 | ]) |
| 140 | |
| 141 | // FAIL: BAD: Sequential when unnecessary |
| 142 | const users = await fetchUsers() |
| 143 | const markets = await fetchMarkets() |
| 144 | const stats = await fetchStats() |
| 145 | ``` |
| 146 | |
| 147 | ### Type Safety |
| 148 | |
| 149 | ```typescript |
| 150 | // PASS: GOOD: Proper types |
| 151 | interface Market { |
| 152 | id: string |
| 153 | name: string |
| 154 | status: 'active' | 'resolved' | 'closed' |
| 155 | created_at: Date |
| 156 | } |
| 157 | |
| 158 | function getMarket(id: string): Promise<Market> { |
| 159 | // Implementation |
| 160 | } |
| 161 | |
| 162 | // FAIL: BAD: Using 'any' |
| 163 | function getMarket(id: any): Promise<any> { |
| 164 | // Implementation |
| 165 | } |
| 166 | ``` |
| 167 | |
| 168 | ## React Best Practices |
| 169 | |
| 170 | ### Component Structure |
| 171 | |
| 172 | ```typescript |
| 173 | // PASS: GOOD: Functional component with types |
| 174 | interface ButtonProps { |
| 175 | children: React.ReactNode |
| 176 | onClick: () => void |
| 177 | disabled?: boolean |
| 178 | variant?: 'primary' | 'secondary' |
| 179 | } |
| 180 | |
| 181 | export function Button({ |
| 182 | children, |
| 183 | onClick, |
| 184 | disabled = false, |
| 185 | variant = 'primary' |
| 186 | }: ButtonProps) { |
| 187 | return ( |
| 188 | <button |
| 189 | onClick={onClick} |
| 190 | disabled={disabled} |
| 191 | className={`btn btn-${variant}`} |
| 192 | > |
| 193 | {children} |
| 194 | </button> |
| 195 | ) |
| 196 | } |
| 197 | |
| 198 | // FAIL: BAD: No types, unclear structure |
| 199 | export function Button(props) { |
| 200 | return <button onClick={props.onClick}>{props.children}</button> |
People who liked this also viewed
6 picksType
- hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026
- request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026
- explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026
- ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
