Code Style Enforcer

This skill ensures code follows project-specific style conventions and patterns that automated linters may miss.

When to Use This Skill

• •User requests code style review or improvements
• •Ensuring consistency across the codebase
• •Onboarding new code or contributors
• •Pre-commit code review
• •User mentions "style", "consistency", "formatting", or "conventions"

Instructions

1. Detect Project Style Guides

Look for style configuration files:

JavaScript/TypeScript:

• •.eslintrc.* - ESLint configuration
• •.prettierrc.* - Prettier configuration
• •tsconfig.json - TypeScript compiler options
• •.editorconfig - Editor configuration

Python:

• •.pylintrc, pylint.cfg - Pylint
• •pyproject.toml - Black, isort configuration
• •.flake8 - Flake8 configuration
• •setup.cfg - Various tool configs

Ruby:

• •.rubocop.yml - RuboCop configuration

Go:

• •go.fmt enforced (standard)
• •.golangci.yml - GolangCI-Lint

Java:

• •checkstyle.xml - Checkstyle
• •.editorconfig

General:

• •CONTRIBUTING.md - Contribution guidelines
• •STYLE_GUIDE.md - Project style guide
• •.editorconfig - Cross-editor settings

Use Glob to find these files and Read to understand the project's style preferences.

2. Analyze Existing Code Patterns

Sample existing code to understand implicit conventions:

File organization:

• •Directory structure patterns
• •File naming conventions (camelCase, kebab-case, snake_case)
• •Import/export organization

Code structure:

• •Class/function ordering
• •Public vs private method placement
• •Constant/variable declaration location

Formatting:

• •Indentation (spaces vs tabs, size)
• •Line length limits
• •Blank line usage
• •Comment styles

Naming:

• •Variable naming (camelCase, snake_case)
• •Class naming (PascalCase, capitalization)
• •Constant naming (UPPER_CASE, etc.)
• •File naming patterns

Use Grep to find common patterns across similar files.

3. Beyond Linters: Check for Patterns

Focus on style issues that automated tools often miss:

Naming Consistency:

• •Boolean variables: is, has, should prefixes
• •Event handlers: handle*, on* patterns
• •Getters/setters: get*, set* consistency
• •Collection naming: plural vs singular
• •Acronyms: consistent capitalization

Code Organization:

• •Related functions grouped together
• •Consistent file structure across modules
• •Logical ordering (public before private, etc.)
• •Separation of concerns

Comments and Documentation:

• •JSDoc/docstring completeness
• •Comment style consistency
• •TODO/FIXME format
• •Inline vs block comments

Import/Export Patterns:

• •Import ordering (external, internal, relative)
• •Named vs default exports
• •Destructuring consistency
• •Aliasing patterns

Error Handling:

• •Consistent error message format
• •Error class usage
• •Try/catch patterns
• •Logging format

Type Usage (TypeScript/typed languages):

• •Explicit vs inferred types
• •interface vs type preference
• •Generic naming (T, K, V vs descriptive)
• •Null/undefined handling

4. Identify Common Anti-Patterns

Flag code smells and anti-patterns:

Magic Numbers:

// Bad
if (status === 200) { }

// Good
const HTTP_OK = 200;
if (status === HTTP_OK) { }

Inconsistent null checks:

// Inconsistent
if (user === null) { }
if (!data) { }
if (typeof result === 'undefined') { }

// Consistent
if (user === null) { }
if (data === null) { }
if (result === undefined) { }

Nested ternaries:

// Hard to read
const value = a ? b ? c : d : e;

// Better
let value;
if (a) {
  value = b ? c : d;
} else {
  value = e;
}

Long parameter lists:

# Hard to maintain
def create_user(name, email, age, address, phone, ...):

# Better
def create_user(user_data: UserData):

5. Check Project-Specific Conventions

Look for patterns unique to this project:

• •Custom naming for specific domains (e.g., "repo" vs "repository")
• •Preferred libraries for common tasks
• •Architectural patterns (MVC, service layer, etc.)
• •Test file naming and structure
• •Configuration patterns

Read CONTRIBUTING.md, README.md, or similar docs for explicit guidelines.

6. Generate Style Recommendations

For each issue, provide:

Current code:

function getData(id) {
  const d = fetch('/api/users/' + id);
  return d;
}

Issue:

• •Inconsistent naming (getData vs other functions use fetch*)
• •Single-letter variable name (d)
• •String concatenation instead of template literals

Recommended:

function fetchUser(id) {
  const userData = fetch(`/api/users/${id}`);
  return userData;
}

7. Prioritize Issues

Order by impact:

High Priority (Consistency):

• •Naming inconsistencies across similar functions
• •Mixed indentation or formatting
• •Inconsistent error handling

Medium Priority (Readability):

• •Magic numbers/strings
• •Unclear variable names
• •Missing documentation

Low Priority (Nice-to-have):

• •Comment formatting
• •Import ordering
• •Extra blank lines

8. Suggest Automated Tools

Recommend tools to enforce styles:

JavaScript/TypeScript:

npm install --save-dev prettier eslint
npx prettier --write .
npx eslint --fix .

Python:

pip install black isort flake8
black .
isort .

Go:

go fmt ./...
golangci-lint run

Ruby:

gem install rubocop
rubocop -a

9. Create or Update EditorConfig

Suggest .editorconfig if missing:

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.{js,ts,jsx,tsx}]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4

[*.go]
indent_style = tab

10. Style Review Checklist

When reviewing code for style:

• • Naming follows project conventions
• • Indentation and formatting consistent
• • Imports organized properly
• • Comments where needed, not excessive
• • No magic numbers or strings
• • Error handling consistent
• • File organization matches project structure
• • No obvious code smells
• • Type annotations consistent (if applicable)
• • Tests follow testing conventions

Best Practices

1. •Consistency over perfection: Follow existing patterns even if not ideal
2. •Document decisions: Add style guides for ambiguous cases
3. •Automate where possible: Use Prettier, Black, gofmt, etc.
4. •Be pragmatic: Don't refactor working code just for style
5. •Team agreement: Align on styles that matter
6. •Incremental improvement: Fix styles in touched files, not all at once
7. •Readability first: Style serves readability, not vice versa

Common Style Conflicts

Tabs vs Spaces

• •Check .editorconfig or existing files
• •When in doubt, use project majority

Quote Style (Single vs Double)

• •JavaScript: Single (') common
• •Python: Either, be consistent
• •Go: Always double (")
• •Follow linter config if present

Semicolons (JavaScript)

• •Check existing code majority
• •If mixed, suggest Prettier to enforce

Line Length

• •Common limits: 80, 100, 120 characters
• •Check linter config or .editorconfig

Import Ordering

• •Usually: stdlib, external, internal, relative
• •Use automated tools (isort, organize imports)

Supporting Files

• •reference/style-guides.md: Links to popular style guides
• •examples/before-after.md: Code examples showing improvements