EditorConfig

Development teams using different editors and IDEs need consistent code formatting. EditorConfig provides cross-editor configuration defining indentation, line endings, encoding, and style rules ensuring code consistency regardless of developer tools. This skill generates EditorConfig files matching team standards enabling automatic formatting across editors.

What Is This?

Overview

EditorConfig produces .editorconfig files establishing coding style standards. It specifies indentation style and size for different file types, defines line ending conventions, sets character encoding, configures trailing whitespace handling, applies language-specific formatting rules, and supports hierarchical configuration for project organization.

The skill generates configurations compatible with Visual Studio, VS Code, JetBrains IDEs, Sublime Text, and other editors supporting EditorConfig. It follows INI-file format with glob patterns matching file types, making the syntax straightforward to read and maintain even for developers unfamiliar with the standard.

Who Should Use This

Team leads establishing standards. Development teams ensuring consistency. Open source maintainers defining conventions. Code reviewers reducing formatting noise. Multi-editor teams needing uniformity. Projects standardizing style across contributors working in different environments.

Why Use It?

Problems It Solves

Different editors apply different formatting causing noisy diffs. EditorConfig standardizes formatting across all tools, ensuring that a file edited in VS Code looks identical to one edited in Rider or Sublime Text.

Manual style enforcement in reviews wastes time. Automatic formatting reduces review overhead focusing on logic rather than whitespace corrections or line ending inconsistencies.

New team members use inconsistent styles. Configuration immediately applies team standards in any editor without requiring manual setup or memorization of style guides.

Mixed indentation and line endings cause merge conflicts. Consistent configuration prevents these formatting issues, particularly in cross-platform teams where Windows and Unix developers collaborate on the same codebase.

Core Highlights

Cross-editor compatibility. File type specific rules. Indentation configuration. Line ending standardization. Encoding specification. Whitespace handling. Language-specific settings. Hierarchical configuration. Git integration friendly.

How to Use It?

Basic Usage

Specify project languages and style preferences. The skill generates EditorConfig file applying standards.

Create EditorConfig for C# project with
4-space indentation and LF line endings

Generate EditorConfig for JavaScript project
using 2 spaces and semicolons

Specific Scenarios

For multi-language projects, configure per type.

Create EditorConfig with different rules for
TypeScript, Markdown, and YAML files

For team standards, match existing conventions.

Generate EditorConfig matching team's preferred
style for React and Node.js projects

For legacy projects, preserve existing style.

Create EditorConfig matching current formatting
in large codebase to avoid massive diffs

Real World Examples

A development team uses mix of VS Code, Visual Studio, and Rider. Code formatting differs causing review friction. EditorConfig is created with 4-space indentation for C#, 2-space for JavaScript, LF line endings throughout, UTF-8 encoding, and trim trailing whitespace. Pull requests become cleaner with consistent formatting regardless of editor.

An open source project receives contributions with inconsistent formatting. Maintainer spends time fixing styles. Generated EditorConfig specifies project conventions with indentation rules per file type, line ending configuration, insert final newline requirement, and whitespace trimming. Contributors' editors format automatically following project standards.

A company standardizes across multiple repositories. Manual configuration is tedious. EditorConfig template is created covering all languages used, deployed to all repositories, configured in CI to validate compliance, and documented in contribution guidelines. Code consistency improves organization-wide.

Advanced Tips

Place in repository root. Use glob patterns for file matching. Apply hierarchical configs for subdirectories. Combine with linters for complete formatting. Validate in CI pipelines. Document in contributing guide. Version control the config. Test across team editors. Use the root = true property at the top of the file to prevent EditorConfig from searching parent directories unexpectedly.

When to Use It?

Use Cases

Team standardization. Open source projects. Multi-editor environments. Code review efficiency. Onboarding automation. Style guide enforcement. Legacy project consistency. Cross-platform development.

Related Topics

Code formatting tools. Linters and style checkers. Git configuration. IDE settings. Team collaboration. Coding standards. Contribution guidelines. Continuous integration.

Important Notes

Requirements

EditorConfig plugin in editors. Team agreement on standards. Understanding of formatting preferences. Repository access for file placement. Editor support verification.

Usage Recommendations

Start with basic rules. Add rules incrementally. Test across team editors. Document in README. Combine with prettier or formatters. Validate in CI. Version control the file. Update as standards evolve. Keep configuration simple. Focus on important rules.

Limitations

Editor plugin required for enforcement. Limited to supported settings. Cannot enforce all style rules. May conflict with editor settings. No runtime enforcement. Requires team discipline. Some editors have limited support, so verifying compatibility before rolling out organization-wide standards is recommended.