
So, how about a vendor-agnostic solution where editors are responsible for utilizing a shared configuration instead? How EditorConfig Helpsĭefining conventions helps everyone throughout a project's life-cycle.

You'll bloat your project with unrelated files if you add the configuration for every editor someone might use. mixes tabs and spaces, here's how it looks on GitHub with a tab size of 8.Ī common solution is to share editor settings as part of the project, but this assumes all committers are using the same editor as you, which probably isn't the case.įor Java development alone, the following are all popular choices: Without consistency, the code can appear untidy and be a pain to read, depending on a user's development environment.

They can be read by IDEs (Integrated Development Environments), code editors, or build tools to enforce or apply formatting conventions. It relies on third-party tools or integrations to implement support for the rules declared in the file.

It's great because it's widely supported, and it's not tied to any particular language, framework, or code editor.ĮditorConfig on its own is just a vendor-agnostic configuration file. You use EditorConfig to define formatting conventions for textual files in a project.
