Making code more readable is by far the most important reason to use it.

There are namely three ways it saves time. 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. Various indentation sizes across files.Files may not have the desired character encoding.(Usually not a significant issue with Git.) This can result in projects feeling inconsistent or messy, with some or all of the following issues: The user's style settings get applied to the files they modify. What happens when they're contributing to a shared project? This might be a project at work, or an open-source project on GitLab or GitHub. Unfortunately, their preferences probably don't correlate with yours. Users usually configure the code style settings in an editor to their preferences. 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.

Tabs spaces visual studio code github