Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development. Use when writing or reviewing TS/JS/React/Node code, setting up ESLint/Prettier/tsc tooling, or enforcing naming, immutability, error-handling, and structural conventions. Do NOT use for Python (python-patterns), Go (golang-patterns), or WordPress theme PHP (skyyrose-wp-platform owns phpcs and the .min build).
Scanned 9/11/2026
Install to Claude Code
npx -y skills add SkyyRoseLLC/DevSkyy --skill coding-standards --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Coding Standards?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/skyyrosellc-coding-standards)More formats (shields.io, HTML) on the badges page.
---
name: coding-standards
description: Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development. Use when writing or reviewing TS/JS/React/Node code, setting up ESLint/Prettier/tsc tooling, or enforcing naming, immutability, error-handling, and structural conventions. Do NOT use for Python (python-patterns), Go (golang-patterns), or WordPress theme PHP (skyyrose-wp-platform owns phpcs and the .min build).
origin: ECC
---
# Coding Standards & Best Practices
Universal coding standards applicable across all projects.
## When to use
- Starting a new project or module
- Reviewing code for quality and maintainability
- Refactoring existing code to follow conventions
- Enforcing naming, formatting, or structural consistency
- Setting up linting, formatting, or type-checking rules
- Onboarding new contributors to coding conventions
**When NOT to use:**
- Python code — `python-patterns` owns PEP 8, type hints, and Pythonic idioms
- Go code — `golang-patterns` owns Go conventions
- WordPress theme PHP — `skyyrose-wp-platform` owns phpcs, escaping/nonce rules, and the `.min` build
- Repo-wide policy (STOP-AND-SHOW, deploy gates, git discipline) — that lives in `CLAUDE.md`, not here
## Inputs
Required before applying any standard:
- **The target files, read this session.** Never grade or refactor code you have not opened — apply standards to what the file actually contains, not what you assume it contains.
- **The owning workspace's lint/type config.** This repo has two separate TS workspaces:
- `frontend/` — Next.js dashboard: `npm run lint` (`eslint .`), `npm run type-check` (`tsc --noEmit`)
- repo root — `npm run lint` (`eslint src/**/*.{ts,tsx,js,jsx}`), `npm run type-check` (`tsc --project config/typescript/tsconfig.json --noEmit`)
- **Installed dependencies for that workspace.** If `node_modules/.bin/eslint` is absent there, the gate cannot execute — stop and install first. Do not proceed on an unrunnable gate and report it clean (fail-open, bug-230).
If any input is absent: stop and name what's missing. Never proceed with a guessed config or an unread file.
## Procedure
1. Read the code you are about to write against or review (`Read`/`Grep`) — quote `file:line` for every finding.
2. Identify the owning workspace (`frontend/` vs root `src/`) so the right ESLint/tsc config judges the code. Never mix `frontend/node_modules` with root.
3. Apply the standards in this file in order: naming → immutability → error handling → type safety → structure → tests.
4. Grep the diff for banned patterns before running tools: `: any`, direct mutation of shared state (`obj.key =`, `.push(`), empty `catch` blocks, magic numbers.
5. Run the owning workspace's lint and type-check (see Verification). Fix the cause of each finding — never silence it with `eslint-disable` or `@ts-ignore` to get green.
6. Report findings with `file:line` and severity. Violations in code you did not touch are flagged, not fixed unasked (surgical-changes rule).
## Verification
Run the owning workspace's own gates — these are the real scripts in this repo's `package.json` files `[repo]`:
```bash
cd frontend && npm run lint # frontend workspace: eslint .
cd frontend && npm run type-check # frontend workspace: tsc --noEmit
npm run lint # root workspace: eslint src/**/*.{ts,tsx,js,jsx}
npm run type-check # root workspace: tsc --project config/typescript/tsconfig.json --noEmit
grep -n ": any" <changed .ts/.tsx files> # diff-scoped hard gate, blocking even when eslint exits 0
```
- **PASS (lint):** exits 0. Observed 2026-07-29: `cd frontend && npm run lint` exits 0 in this worktree — existing `no-explicit-any` / `no-unused-vars` findings are warning-severity, so exit 0 does NOT mean zero violations. `[repro]`
- **PASS (type-check):** exits 0 with no diagnostics. `[test]`
- **PASS (diff grep):** zero matches on lines you added. `[repo]`
- A gate that dies (missing binary, config error, OOM) is an artifact, not a pass — fix the environment and re-run; never read an errored run as clean (bug-230).
## Worked example
Real invocation in this repo, 2026-07-29 — grepping a workspace lib against the Type Safety standard:
```bash
grep -rn ": any" frontend/lib/vercel --include="*.ts" | head -5
```
Observed output:
```
frontend/lib/vercel/deployment-manager.ts:26: aliasError?: any
frontend/lib/vercel/deployment-manager.ts:34: info?: any
frontend/lib/vercel/deployment-manager.ts:93: const body: any = {
frontend/lib/vercel/deployment-manager.ts:177: const body: any = {
frontend/lib/vercel/deployment-manager.ts:208: const params: any = { ...options }
```
Five violations of the Type Safety standard (`any` in API payload shapes) `[repro]`. The same day, `cd frontend && npm run lint` exited 0 while reporting `@typescript-eslint/no-explicit-any` across 41+ files — the rule is warning-severity in this config, which is exactly why the diff-scoped grep is the blocking check for new code. The correct fix is a typed interface for the Vercel deployment payloads, not an `eslint-disable`.
## Failure modes
| Failure | What it looks like | Rule |
|---|---|---|
| Silencing instead of fixing | `eslint-disable-next-line`, `@ts-ignore`, `as any` added to get green | Same defect as weakening a test to pass it — fix the cause |
| Warning-severity lulling | lint exits 0, so "zero violations" gets claimed | Exit 0 ≠ clean (observed above) — grep the diff for banned patterns |
| Gate dies, read as pass | eslint crashes on a missing binary/config and the empty output is treated as clean | Fail-open (bug-230, ×6) — a gate that dies is not a gate that passed |
| Wrong workspace | root ESLint config judging `frontend/` code, or mixed `node_modules` trees | Two separate workspaces — never mix (`CLAUDE.md` §5) |
| Standards applied to unread code | findings without `file:line`, refactors of assumed content | If you haven't read it, you don't know it |
| Cross-language leakage | these TS/React rules applied to Python or theme PHP | Route to `python-patterns` / `skyyrose-wp-platform` instead |
## Code Quality Principles
### 1. Readability First
- Code is read more than written
- Clear variable and function names
- Self-documenting code preferred over comments
- Consistent formatting
### 2. KISS (Keep It Simple, Stupid)
- Simplest solution that works
- Avoid over-engineering
- No premature optimization
- Easy to understand > clever code
### 3. DRY (Don't Repeat Yourself)
- Extract common logic into functions
- Create reusable components
- Share utilities across modules
- Avoid copy-paste programming
### 4. YAGNI (You Aren't Gonna Need It)
- Don't build features before they're needed
- Avoid speculative generality
- Add complexity only when required
- Start simple, refactor when needed
## TypeScript/JavaScript Standards
### Variable Naming
```typescript
// ✅ GOOD: Descriptive names
const marketSearchQuery = 'election'
const isUserAuthenticated = true
const totalRevenue = 1000
// ❌ BAD: Unclear names
const q = 'election'
const flag = true
const x = 1000
```
### Function Naming
```typescript
// ✅ GOOD: Verb-noun pattern
async function fetchMarketData(marketId: string) { }
function calculateSimilarity(a: number[], b: number[]) { }
function isValidEmail(email: string): boolean { }
// ❌ BAD: Unclear or noun-only
async function market(id: string) { }
function similarity(a, b) { }
function email(e) { }
```
### Immutability Pattern (CRITICAL)
```typescript
// ✅ ALWAYS use spread operator
const updatedUser = {
...user,
name: 'New Name'
}
const updatedArray = [...items, newItem]
// ❌ NEVER mutate directly
user.name = 'New Name' // BAD
items.push(newItem) // BAD
```
### Error Handling
```typescript
// ✅ GOOD: Comprehensive error handling
async function fetchData(url: string) {
try {
const response = await fetch(url)
if (!response.ok) {
throw new Error(`HTTP ${response.status}: ${response.statusText}`)
}
return await response.json()
} catch (error) {
console.error('Fetch failed:', error)
throw new Error('Failed to fetch data')
}
}
// ❌ BAD: No error handling
async function fetchData(url) {
const response = await fetch(url)
return response.json()
}
```
### Async/Await Best Practices
```typescript
// ✅ GOOD: Parallel execution when possible
const [users, markets, stats] = await Promise.all([
fetchUsers(),
fetchMarkets(),
fetchStats()
])
// ❌ BAD: Sequential when unnecessary
const users = await fetchUsers()
const markets = await fetchMarkets()
const stats = await fetchStats()
```
### Type Safety
```typescript
// ✅ GOOD: Proper types
interface Market {
id: string
name: string
status: 'active' | 'resolved' | 'closed'
created_at: Date
}
function getMarket(id: string): Promise<Market> {
// Implementation
}
// ❌ BAD: Using 'any'
function getMarket(id: any): Promise<any> {
// Implementation
}
```
## React Best Practices
### Component Structure
```typescript
// ✅ GOOD: Functional component with types
interface ButtonProps {
children: React.ReactNode
onClick: () => void
disabled?: boolean
variant?: 'primary' | 'secondary'
}
export function Button({
children,
onClick,
disabled = false,
variant = 'primary'
}: ButtonProps) {
return (
<button
onClick={onClick}
disabled={disabled}
className={`btn btn-${variant}`}
>
{children}
</button>
)
}
// ❌ BAD: No types, unclear structure
export function Button(props) {
return <button onClick={props.onClick}>{props.children}</button>
}
```
### Custom Hooks
```typescript
// ✅ GOOD: Reusable custom hook
export function useDebounce<T>(value: T, delay: number): T {
const [debouncedValue, setDebouncedValue] = useState<T>(value)
useEffect(() => {
const handler = setTimeout(() => {
setDebouncedValue(value)
}, delay)
return () => clearTimeout(handler)
}, [value, delay])
return debouncedValue
}
// Usage
const debouncedQuery = useDebounce(searchQuery, 500)
```
### State Management
```typescript
// ✅ GOOD: Proper state updates
const [count, setCount] = useState(0)
// Functional update for state based on previous state
setCount(prev => prev + 1)
// ❌ BAD: Direct state reference
setCount(count + 1) // Can be stale in async scenarios
```
### Conditional Rendering
```typescript
// ✅ GOOD: Clear conditional rendering
{isLoading && <Spinner />}
{error && <ErrorMessage error={error} />}
{data && <DataDisplay data={data} />}
// ❌ BAD: Ternary hell
{isLoading ? <Spinner /> : error ? <ErrorMessage error={error} /> : data ? <DataDisplay data={data} /> : null}
```
## API Design Standards
### REST API Conventions
```
GET /api/markets # List all markets
GET /api/markets/:id # Get specific market
POST /api/markets # Create new market
PUT /api/markets/:id # Update market (full)
PATCH /api/markets/:id # Update market (partial)
DELETE /api/markets/:id # Delete market
# Query parameters for filtering
GET /api/markets?status=active&limit=10&offset=0
```
### Response Format
```typescript
// ✅ GOOD: Consistent response structure
interface ApiResponse<T> {
success: boolean
data?: T
error?: string
meta?: {
total: number
page: number
limit: number
}
}
// Success response
return NextResponse.json({
success: true,
data: markets,
meta: { total: 100, page: 1, limit: 10 }
})
// Error response
return NextResponse.json({
success: false,
error: 'Invalid request'
}, { status: 400 })
```
### Input Validation
```typescript
import { z } from 'zod'
// ✅ GOOD: Schema validation
const CreateMarketSchema = z.object({
name: z.string().min(1).max(200),
description: z.string().min(1).max(2000),
endDate: z.string().datetime(),
categories: z.array(z.string()).min(1)
})
export async function POST(request: Request) {
const body = await request.json()
try {
const validated = CreateMarketSchema.parse(body)
// Proceed with validated data
} catch (error) {
if (error instanceof z.ZodError) {
return NextResponse.json({
success: false,
error: 'Validation failed',
details: error.errors
}, { status: 400 })
}
}
}
```
## File Organization
### Project Structure
```
src/
├── app/ # Next.js App Router
│ ├── api/ # API routes
│ ├── markets/ # Market pages
│ └── (auth)/ # Auth pages (route groups)
├── components/ # React components
│ ├── ui/ # Generic UI components
│ ├── forms/ # Form components
│ └── layouts/ # Layout components
├── hooks/ # Custom React hooks
├── lib/ # Utilities and configs
│ ├── api/ # API clients
│ ├── utils/ # Helper functions
│ └── constants/ # Constants
├── types/ # TypeScript types
└── styles/ # Global styles
```
### File Naming
```
components/Button.tsx # PascalCase for components
hooks/useAuth.ts # camelCase with 'use' prefix
lib/formatDate.ts # camelCase for utilities
types/market.types.ts # camelCase with .types suffix
```
## Comments & Documentation
### When to Comment
```typescript
// ✅ GOOD: Explain WHY, not WHAT
// Use exponential backoff to avoid overwhelming the API during outages
const delay = Math.min(1000 * Math.pow(2, retryCount), 30000)
// Deliberately using mutation here for performance with large arrays
items.push(newItem)
// ❌ BAD: Stating the obvious
// Increment counter by 1
count++
// Set name to user's name
name = user.name
```
### JSDoc for Public APIs
```typescript
/**
* Searches markets using semantic similarity.
*
* @param query - Natural language search query
* @param limit - Maximum number of results (default: 10)
* @returns Array of markets sorted by similarity score
* @throws {Error} If OpenAI API fails or Redis unavailable
*
* @example
* ```typescript
* const results = await searchMarkets('election', 5)
* console.log(results[0].name) // "Trump vs Biden"
* ```
*/
export async function searchMarkets(
query: string,
limit: number = 10
): Promise<Market[]> {
// Implementation
}
```
## Performance Best Practices
### Memoization
```typescript
import { useMemo, useCallback } from 'react'
// ✅ GOOD: Memoize expensive computations
const sortedMarkets = useMemo(() => {
return markets.sort((a, b) => b.volume - a.volume)
}, [markets])
// ✅ GOOD: Memoize callbacks
const handleSearch = useCallback((query: string) => {
setSearchQuery(query)
}, [])
```
### Lazy Loading
```typescript
import { lazy, Suspense } from 'react'
// ✅ GOOD: Lazy load heavy components
const HeavyChart = lazy(() => import('./HeavyChart'))
export function Dashboard() {
return (
<Suspense fallback={<Spinner />}>
<HeavyChart />
</Suspense>
)
}
```
### Database Queries
```typescript
// ✅ GOOD: Select only needed columns
const { data } = await supabase
.from('markets')
.select('id, name, status')
.limit(10)
// ❌ BAD: Select everything
const { data } = await supabase
.from('markets')
.select('*')
```
## Testing Standards
### Test Structure (AAA Pattern)
```typescript
test('calculates similarity correctly', () => {
// Arrange
const vector1 = [1, 0, 0]
const vector2 = [0, 1, 0]
// Act
const similarity = calculateCosineSimilarity(vector1, vector2)
// Assert
expect(similarity).toBe(0)
})
```
### Test Naming
```typescript
// ✅ GOOD: Descriptive test names
test('returns empty array when no markets match query', () => { })
test('throws error when OpenAI API key is missing', () => { })
test('falls back to substring search when Redis unavailable', () => { })
// ❌ BAD: Vague test names
test('works', () => { })
test('test search', () => { })
```
## Code Smell Detection
Watch for these anti-patterns:
### 1. Long Functions
```typescript
// ❌ BAD: Function > 50 lines
function processMarketData() {
// 100 lines of code
}
// ✅ GOOD: Split into smaller functions
function processMarketData() {
const validated = validateData()
const transformed = transformData(validated)
return saveData(transformed)
}
```
### 2. Deep Nesting
```typescript
// ❌ BAD: 5+ levels of nesting
if (user) {
if (user.isAdmin) {
if (market) {
if (market.isActive) {
if (hasPermission) {
// Do something
}
}
}
}
}
// ✅ GOOD: Early returns
if (!user) return
if (!user.isAdmin) return
if (!market) return
if (!market.isActive) return
if (!hasPermission) return
// Do something
```
### 3. Magic Numbers
```typescript
// ❌ BAD: Unexplained numbers
if (retryCount > 3) { }
setTimeout(callback, 500)
// ✅ GOOD: Named constants
const MAX_RETRIES = 3
const DEBOUNCE_DELAY_MS = 500
if (retryCount > MAX_RETRIES) { }
setTimeout(callback, DEBOUNCE_DELAY_MS)
```
**Remember**: Code quality is not negotiable. Clear, maintainable code enables rapid development and confident refactoring.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!