Write Coding Standards From File

Write coding standards from file

Analyze one file or a folder of files, infer the majority syntax and style conventions, optionally compare them with language style references, and output or write a project coding standards document.

When to invoke

• "Create coding standards from this file."
• "Infer our style guide from this folder."
• "Write CODING_STANDARDS.md based on these examples."
• "Add project coding standards to README.md."
• "Find and fix inconsistencies while generating the guide."

Inputs

Use $ARGUMENTS to resolve the required fileName, optional folderName, optional instructions, and any configuration override passed as [configVariableAsParameter]. If multiple files or folderName are supplied, aggregate their style observations into one temporary dataset before writing standards.

Configuration variables

Decision rules

Compatibility tokens

Keep these original configuration labels recognizable when translating older requests: boolean, string[], string, object, quasi-configuration, as-is, and/or, or, top-level, well-known, line-breaks, ${fileName}, ${folderName}, ${instructions}, ${addToREADME}, ${createNewFile}, ${fixInconsistencies}, ${newFileName}, ${outputSpecToPrompt}, ${useTemplate}, ${fileName} == [<Language> Style Guide], #fetch ${item}, and #fetch (URL). The template selectors may appear as [ ["v", "verbose"], ["m", "minimal"], ["b", "best fit"] ], [["v", "verbose"], ["m", "minimal"], ["b", "best fit"]], "m", "minimal", "v", verbose", ### "m", "minimal", ### "v", "verbose", ## Coding Standards Templates, and ## Variable and Parameter Configuration Conditions in source material.

When demonstrating spacing or braces, include examples such as if (x), not if(x), and sample calls like do_something and do_something_else only as illustrative placeholders.

Standards content

Style reference map

When fetchStyleURL is true, use only the relevant language or ecosystem links:

Examples

Minimal template

Use for small projects or when useTemplate is "m" or "minimal".

## 1. Introduction
* **Purpose:** Briefly explain why the coding standards are being established.
* **Scope:** Define which languages, projects, or modules this specification applies to.

## 2. Naming Conventions
* **Variables:** `camelCase`
* **Functions/Methods:** `PascalCase` or `camelCase`.
* **Classes/Structs:** `PascalCase`.
* **Constants:** `UPPER_SNAKE_CASE`.

## 3. Formatting and Style
* **Indentation:** Use 4 spaces per indent or tabs.
* **Line Length:** Limit lines to a maximum of 80 or 120 characters.
* **Braces:** Use K&R or Allman style.
* **Blank Lines:** Specify separation between logical blocks.

## 4. Commenting
* **Docstrings/Function Comments:** Describe purpose, parameters, and return values.
* **Inline Comments:** Explain complex or non-obvious logic.
* **File Headers:** Specify author, date, and file description if the project uses them.

## 5. Error Handling
* **General:** How to handle and log errors.
* **Specifics:** Which exception types to use and what to include in error messages.

## 6. Best Practices and Anti-Patterns
* **General:** Avoid global variables and magic numbers.
* **Language-specific:** Add project-specific recommendations.

## 7. Examples
* Provide correct and incorrect examples.

## 8. Contribution and Enforcement
* Explain review and enforcement.

Verbose template

Use for larger projects, or when useTemplate is "v" or "verbose".

# Style Guide

This document defines the style and conventions used in this project.
All contributions should follow these rules unless otherwise noted.

## 1. General Code Style
- Favor clarity over brevity.
- Keep functions and methods small and focused.
- Avoid repeating logic; prefer shared helpers/utilities.
- Remove unused variables, imports, code paths, and files.

## 2. Naming Conventions
| Item | Convention | Example |
| --- | --- | --- |
| Variables | `lower_snake_case` | `buffer_size` |
| Functions | `lower_snake_case()` | `read_file()` |
| Constants | `UPPER_SNAKE_CASE` | `MAX_RETRIES` |
| Types/Structs | `PascalCase` | `FileHeader` |
| File Names | `lower_snake_case` | `file_reader.c` |

## 3. Formatting Rules
- Indentation: **4 spaces**
- Line length: **max 100 characters**
- Encoding: **UTF-8**, no BOM
- End files with a newline

## 4. Comments & Documentation
- Explain why, not what, unless intent is unclear.
- Keep comments up-to-date as code changes.
- Public functions should include a short description of purpose and parameters.
- Tags: `TODO: follow-up work`, `FIXME: known incorrect behavior`, `NOTE: non-obvious design decision`.

## 5. Error Handling
- Handle error conditions explicitly.
- Avoid silent failures.
- Clean up resources before returning on failure.

## 6. Commit & Review Practices
- One logical change per commit.
- Write clear commit messages.
- Keep pull requests reasonably small.

## 7. Tests
- Write tests for new functionality.
- Tests should be deterministic.
- Prefer readable test cases over complex test abstraction.

## 8. Changes to This Guide
Style evolves. Propose improvements by updating this document.

Output template

## Coding standards result

**Status:** created file | updated README.md | output only | blocked
**Source:** `<fileName or folderName>`
**Template:** minimal | verbose | best fit | custom

### Style evidence
| Category | Majority pattern | Exceptions |
| --- | --- | --- |
| Indentation | <tabs/2/4 spaces> | <files or none> |
| Naming | <observed conventions> | <exceptions or none> |
| Comments | <docstring/comment style> | <exceptions or none> |
| Error handling | <observed approach> | <exceptions or none> |

### Artifact
- `<CONTRIBUTING.md or STYLE.md or CODE_OF_CONDUCT.md or CODING_STANDARDS.md or DEVELOPING.md or CONTRIBUTION_GUIDE.md or GUIDELINES.md or PROJECT_STANDARDS.md or BEST_PRACTICES.md or HACKING.md or README.md>`

### Inconsistencies
- <fixed or reported inconsistency>

### Validation
- `fetchStyleURL`: true | false, <URL or not applicable>
- `findInconsistencies`: true | false
- `fixInconsistencies`: true | false

Quality gate

• fileName is present or folderName provides a real file set to analyze.
• Multiple files are aggregated before standards are written.
• fixInconsistencies is disabled for multi-file or folder analysis unless the user explicitly accepts edits.
• The output location honors addToREADME, createNewFile, and outputSpecToPrompt precedence.
• newFileName uses the first missing candidate or the exact string supplied by the user.
• Style rules are backed by observed source evidence, fetched reference guidance, or explicit user instructions.
• Every inconsistency that is fixed or reported is tied to a counted minority pattern.

References

• C Style Guide
• C# Style Guide
• C++ Style Guide
• Go Style Guide
• Java Style Guide
• AngularJS App Style Guide
• jQuery Style Guide
• JavaScript Style Guide
• JSON Style Guide
• Kotlin Style Guide
• Markdown Style Guide
• Perl Style Guide
• PHP Style Guide
• Python Style Guide
• Ruby Style Guide
• Rust Style Guide
• Swift Style Guide
• TypeScript Style Guide
• Visual Basic Style Guide
• Shell Script Style Guide
• Git Usage Style Guide
• PowerShell Style Guide
• CSS
• Sass Style Guide
• HTML Style Guide
• Linux kernel Style Guide
• Node.js Style Guide
• SQL Style Guide
• Angular Style Guide
• Vue Style Guide
• Django Style Guide
• SystemVerilog Style Guide