coding-standards

Name: coding-standards
Author: jmstar85

151stars12forks

How to install coding-standards?

jmstar85/oh-my-githubcopilot/coding-standards

$npx -y skills add jmstar85/oh-my-githubcopilot --skill coding-standards

Installs into the current project.

Summary

Canonical cross-language coding standards reference. Shared rules embedded by reviewer agents. Activate when: viewing coding standards, checking naming rules, reviewing style baseline, consulting style guide, what are the rules.

Files · 1

View on GitHub

SKILL.md

1	# Coding Standards
2
3	> D9 Canonical Reference. This is the single source of truth for cross-language coding standards.
4	> Language-specific reviewers (`@typescript-reviewer`, `@python-reviewer`, etc.) embed these rules.
5	> Agents cite this skill as "See also: /coding-standards."
6
7	## Naming Conventions
8
9	### Variables & Functions
10	\| Language \| Variables \| Functions \| Constants \|
11	\|----------\|-----------\|-----------\|-----------\|
12	\| TypeScript / JavaScript \| `camelCase` \| `camelCase` \| `SCREAMING_SNAKE_CASE` \|
13	\| Python \| `snake_case` \| `snake_case` \| `SCREAMING_SNAKE_CASE` \|
14	\| Go \| `camelCase` \| `camelCase` \| `CamelCase` (exported) \|
15	\| Rust \| `snake_case` \| `snake_case` \| `SCREAMING_SNAKE_CASE` \|
16	\| Java \| `camelCase` \| `camelCase` \| `SCREAMING_SNAKE_CASE` \|
17	\| C# \| `camelCase` \| `PascalCase` \| `PascalCase` \|
18	\| Swift \| `camelCase` \| `camelCase` \| `camelCase` \|
19
20	### Classes / Types / Interfaces
21	`PascalCase` — all languages, no exceptions.
22
23	### Booleans
24	Prefix with `is`, `has`, `can`, `should`: `isLoading`, `hasError`, `canEdit`, `shouldRefresh`.
25
26	### Collections
27	Plural nouns: `users`, `errors`, `items` — not `userList`, `errorArray`.
28
29	### Avoid
30	- Single-letter variables outside loop counters (`i`, `j`, `k` are OK in loops)
31	- Abbreviations that save under 3 characters: `usr` → `user`, `mgr` → `manager`
32	- Redundant type names: `UserInterface`, `UserClass`, `UserObject` → just `User`
33
34	---
35
36	## Function Design
37
38	- Max length: 50 lines (firm guideline; > 80 lines is always a split target)
39	- Single responsibility: one function, one job — if "and" appears in the description, split it
40	- Max parameters: 3; beyond that, use an options/config object
41	- Cyclomatic complexity: ≤ 10; > 15 is a mandatory refactor target
42	- Nesting depth: ≤ 3 levels; use early returns to flatten
43
44	### Early Return Pattern (preferred)
45	```typescript
46	// BEFORE — deep nesting
47	function handle(input) {
48	if (input) {
49	if (input.valid) {
50	return process(input);
51	}
52	}
53	return null;
54	}
55
56	// AFTER — early returns
57	function handle(input) {
58	if (!input \|\| !input.valid) return null;
59	return process(input);
60	}
61	```
62
63	---
64
65	## Error Handling
66
67	- Never swallow errors silently: `catch (e) {}` is always wrong
68	- Error messages must contain context: `"Failed to fetch user id=42"` not `"Error"`
69	- Propagate or handle: either handle the error at the right level OR re-throw it — never both and never neither
70	- Typed errors (TypeScript): `class NotFoundError extends Error { constructor(id: string) ... }` not generic `new Error`
71	- Python exceptions: catch specific exception types; bare `except:` is forbidden
72	- Go errors: always check returned errors; use `errors.Is()`/`errors.As()` for comparison
73	- Rust results: use `?` for propagation; no `.unwrap()` in library code
74
75	---
76
77	## Code Structure
78
79	### Immutability-First
80	- `const` over `let` (JS/TS); `val` over `var` (Swift/Kotlin); `final` where appropriate
81	- Mark fields `readonly` when not reassigned after construction
82	- Prefer immutable data structures for function arguments
83
84	### No Magic Numbers
85	```typescript
86	// BAD
87	if (retries > 3) { ... }
88	setTimeout(fn, 5000);
89
90	// GOOD
91	const MAX_RETRIES = 3;
92	const POLL_INTERVAL_MS = 5000;
93	if (retries > MAX_RETRIES) { ... }
94	setTimeout(fn, POLL_INTERVAL_MS);
95	```
96
97	### No Commented-Out Code
98	If it is dead → delete it (git history preserves it).
99	If it is needed soon → it should be in a branch.
100	If it explains a non-obvious decision → keep it as a comment, not commented-out code.
101
102	---
103
104	## Anti-Patterns Reference
105
106	\| Pattern \| Severity \| Reason \|
107	\|---------\|----------\|--------\|
108	\| Mutable global state \| HIGH \| Unpredictable side effects; hides dependencies \|
109	\| Promise not awaited \| HIGH \| Unhandled async errors silently swallowed \|
110	\| `any` in TypeScript \| MEDIUM \| Bypasses type safety across call boundaries \|
111	\| `console.log` in production code \| LOW \| Log noise; potential data leak in sensitive contexts \|
112	\| `TODO` without issue tracker reference \| LOW \| Becomes permanent tech debt \|
113	\| God Object \| HIGH \| Single class with too many responsibilities \|
114	\| Magic numbers inline \| MEDIUM \| Unclear intent; maintenance hazard \|
115	\| Copy-paste logic \| MEDIUM \| Silent divergence over time \|
116	\| Catching and re-throwing without context \| MEDIUM \| Stack traces lose meaning \|
117	\| Nested ternary operators \| MEDIUM \| Unreadable; use if/else or switch instead \|
118
119	---
120
121	## SOLID Principles Checklist
122
123	- Single Responsibility: does this class/function do exactly one thing?
124	- Open/Closed: extend via composition/interfaces, not inheritance modification?
125	- Liskov Substitution: can a subtype always replace th

People who liked this also viewed

6 picks

Type

coding-standards

151stars12forks

View on GitHub

How to install coding-standards?

jmstar85/oh-my-githubcopilot/coding-standards

$npx -y skills add jmstar85/oh-my-githubcopilot --skill coding-standards

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Coding Standards
2
3	> D9 Canonical Reference. This is the single source of truth for cross-language coding standards.
4	> Language-specific reviewers (`@typescript-reviewer`, `@python-reviewer`, etc.) embed these rules.
5	> Agents cite this skill as "See also: /coding-standards."
6
7	## Naming Conventions
8
9	### Variables & Functions
10	\| Language \| Variables \| Functions \| Constants \|
11	\|----------\|-----------\|-----------\|-----------\|
12	\| TypeScript / JavaScript \| `camelCase` \| `camelCase` \| `SCREAMING_SNAKE_CASE` \|
13	\| Python \| `snake_case` \| `snake_case` \| `SCREAMING_SNAKE_CASE` \|
14	\| Go \| `camelCase` \| `camelCase` \| `CamelCase` (exported) \|
15	\| Rust \| `snake_case` \| `snake_case` \| `SCREAMING_SNAKE_CASE` \|
16	\| Java \| `camelCase` \| `camelCase` \| `SCREAMING_SNAKE_CASE` \|
17	\| C# \| `camelCase` \| `PascalCase` \| `PascalCase` \|
18	\| Swift \| `camelCase` \| `camelCase` \| `camelCase` \|
19
20	### Classes / Types / Interfaces
21	`PascalCase` — all languages, no exceptions.
22
23	### Booleans
24	Prefix with `is`, `has`, `can`, `should`: `isLoading`, `hasError`, `canEdit`, `shouldRefresh`.
25
26	### Collections
27	Plural nouns: `users`, `errors`, `items` — not `userList`, `errorArray`.
28
29	### Avoid
30	- Single-letter variables outside loop counters (`i`, `j`, `k` are OK in loops)
31	- Abbreviations that save under 3 characters: `usr` → `user`, `mgr` → `manager`
32	- Redundant type names: `UserInterface`, `UserClass`, `UserObject` → just `User`
33
34	---
35
36	## Function Design
37
38	- Max length: 50 lines (firm guideline; > 80 lines is always a split target)
39	- Single responsibility: one function, one job — if "and" appears in the description, split it
40	- Max parameters: 3; beyond that, use an options/config object
41	- Cyclomatic complexity: ≤ 10; > 15 is a mandatory refactor target
42	- Nesting depth: ≤ 3 levels; use early returns to flatten
43
44	### Early Return Pattern (preferred)
45	```typescript
46	// BEFORE — deep nesting
47	function handle(input) {
48	if (input) {
49	if (input.valid) {
50	return process(input);
51	}
52	}
53	return null;
54	}
55
56	// AFTER — early returns
57	function handle(input) {
58	if (!input \|\| !input.valid) return null;
59	return process(input);
60	}
61	```
62
63	---
64
65	## Error Handling
66
67	- Never swallow errors silently: `catch (e) {}` is always wrong
68	- Error messages must contain context: `"Failed to fetch user id=42"` not `"Error"`
69	- Propagate or handle: either handle the error at the right level OR re-throw it — never both and never neither
70	- Typed errors (TypeScript): `class NotFoundError extends Error { constructor(id: string) ... }` not generic `new Error`
71	- Python exceptions: catch specific exception types; bare `except:` is forbidden
72	- Go errors: always check returned errors; use `errors.Is()`/`errors.As()` for comparison
73	- Rust results: use `?` for propagation; no `.unwrap()` in library code
74
75	---
76
77	## Code Structure
78
79	### Immutability-First
80	- `const` over `let` (JS/TS); `val` over `var` (Swift/Kotlin); `final` where appropriate
81	- Mark fields `readonly` when not reassigned after construction
82	- Prefer immutable data structures for function arguments
83
84	### No Magic Numbers
85	```typescript
86	// BAD
87	if (retries > 3) { ... }
88	setTimeout(fn, 5000);
89
90	// GOOD
91	const MAX_RETRIES = 3;
92	const POLL_INTERVAL_MS = 5000;
93	if (retries > MAX_RETRIES) { ... }
94	setTimeout(fn, POLL_INTERVAL_MS);
95	```
96
97	### No Commented-Out Code
98	If it is dead → delete it (git history preserves it).
99	If it is needed soon → it should be in a branch.
100	If it explains a non-obvious decision → keep it as a comment, not commented-out code.
101
102	---
103
104	## Anti-Patterns Reference
105
106	\| Pattern \| Severity \| Reason \|
107	\|---------\|----------\|--------\|
108	\| Mutable global state \| HIGH \| Unpredictable side effects; hides dependencies \|
109	\| Promise not awaited \| HIGH \| Unhandled async errors silently swallowed \|
110	\| `any` in TypeScript \| MEDIUM \| Bypasses type safety across call boundaries \|
111	\| `console.log` in production code \| LOW \| Log noise; potential data leak in sensitive contexts \|
112	\| `TODO` without issue tracker reference \| LOW \| Becomes permanent tech debt \|
113	\| God Object \| HIGH \| Single class with too many responsibilities \|
114	\| Magic numbers inline \| MEDIUM \| Unclear intent; maintenance hazard \|
115	\| Copy-paste logic \| MEDIUM \| Silent divergence over time \|
116	\| Catching and re-throwing without context \| MEDIUM \| Stack traces lose meaning \|
117	\| Nested ternary operators \| MEDIUM \| Unreadable; use if/else or switch instead \|
118
119	---
120
121	## SOLID Principles Checklist
122
123	- Single Responsibility: does this class/function do exactly one thing?
124	- Open/Closed: extend via composition/interfaces, not inheritance modification?
125	- Liskov Substitution: can a subtype always replace th

People who liked this also viewed

6 picks

Type