EditorConfig – file format for defining coding styles and text editor plugins | Hacker News Reader

EditorConfig – file format for defining coding styles and text editor plugins

editorconfig.org

164 pointss_chaudhary31 comments

People comparing EditorConfig to eslint or prettier does not really understand it's purpose.

yes they have intersecting features, but EditorConfig's main feature is that it lets you set file type specific whitespace rules automatically, across almost all editors.

- Most editors will have a global whitespace rule and you have to use that same rule for every file.

- Some editors can be configured to have different rules per file type but then it can't be done per project. So every project has to use the same rules.

- Some editors will let you configure all of these per project, but you have to save this project-settings file somewhere. Editor specific code is no good in the repo, so you need to maintain/backup it yourself.

EditorConfig solves all of these issues for me.

Before clicking on the link, I thought "Oh, just another attempt at standardizing editor preferences from a file in a repo." But looking at their list of editors which natively support EditorConfig and the list of plugins for editors which don't, this is far better support than I imagined. This is it! Problem solved.

Honestly I don't think much is solved by EditorConfig.

I mean, the idea is great, but the small amount of parameters supported makes it pretty much useless. Indentation character and size, line termination, ... and that's all. I would need a hundred of these (like clang-format, yapf, etc have) to switch to EditorConfig. Unfortunately, looking at the commit log frequency, I doubt EditorConfig will ever have more than the 10 or so parameters that it already have.

but what more could it have? Editor config is not a "should there be a space between function name and parens" kind of tool.

It's only meant to automatically configure your editor to use the defined tab/space newline preferences per file type.

that's it.

Yes, it doesn't have many features, but most everything I might want should be defined elsewhere. Astyle configs should go in its own `.astylerc` file, Python style in `.style.yapf`, clang-format in `.clang-format`, build system in `Makefile` or `Gruntfile` or whatever is most common in your language, `.gitignore` for useless files, etc. But just for displaying a file perfectly, all that's needed is file encoding and indent width, and a couple other things EditorConfig defines. It's not supposed to be an "IDEConfig".

> Honestly I don't think much is solved by EditorConfig.

No, it doesn't solve all the things. My experience is that it addresses one specific annoyance - team members checking in changes with varying line endings and spaces/tabs settings - and makes it a thing of the past.

For solving that one thing, I like it a lot.

Well, it moves the problem to making sure that all team members have the right plugins installed and bother to use them. Depending on the make up of your team, that could be a hard problem.

It moves the problem from "could you submit your PR with spaces not tabs, the spurious diff is not good" and "but it doesn't matter, I don't care" on a regular basis; to "let's install this plugin to your IDE and neither of us has to worry about it again - you get ease and I get consistency".

If this is really a hard problem for a team then it's down to the people not the tools.

There is in my experience no "bother to use them" part, it happens automatically when a file is saved.

Even better, "the right plugins" might be none at all. Some IDEs come with editorconfig support out of the box: https://sorokoletov.com/2016/11/28/editorconfig-in-visualstu...

In short, if you have these specific problems, life really is easier with editorconfig.

I hope it does. It's to add them slowly though. Especially since most editors have built in settings for spacing but not for linting. I wish for stuff like allowed_var_name_regex that would mean nothing to most editors unless you install a plugin.

EditorConfig is awesome, especially for a distributed remote team. I've standardized everyone whom I ever worked with few initial project settings and EditorConfig is such one must-do item. Been using it (I think) for the past 5 years or so.

Same here, and I love it for another reason as well: It can configure my editor to have different indentation settings for different filetypes.

No longer does JSON get the four spaces that Python does.

I made this a standard for all my engineers years ago. anything I can do to automate consistency and "correctness" in coding style and let my team focus on doing the real work

Looks like 99% of this is covered by my editor being configured to autodetect existing indentation, and adjust itself accordingly: https://github.com/ciaranm/detectindent

See also vim-sleuth

I think you might be missing the point, not everyone (your collaborators) will use the same editor, the same white-space rules. And some developers couldn't care less about consistent code and quality at all.

But having a EditorConfig file means writing none compliant code becomes a defiant choice.

Typically the whitespace rules are part of the standards as well. Spaces after if, spaces after commas, spaces before stars, after stars, around stars, alignment, newlines, two spaces after a full stop in a comment, the full works. People have spent entire meetings trying to come to agreement on this stuff. And then afterwards people keep checking in stuff that's "wrong", not intentionally, but because they've spent literally their entire lives doing it the other way, and they're stuck with the muscle memory.

If you want the computer to make your entire codebase look roughly the same, you'll need more than a .editorconfig file...

(For C and C++, I've been quite pleased with clang-format, provided somebody else gets to set it up. Of course, as well as the code layout, it also sorts out tabs vs spaces, line ending type, and indent width.)

EditorConfig's not about that kind of whitespace though. That's a language-specific thing, best solved with an autoformatting tool like the utterly magnificent one that comes with Go.

I don't much care for Go the language, but shipping a formatter with the compiler is an utterly genius move.

it's meant to be used within teams, with people who might not have the same editor (or the same set of plugins) as you

you just drop an .editorconfig at the root of your project and you'll know for sure that any code written by anyone will have the same indentation, encoding, and final newline config

Is that widely implemented enough to be useful? Because I'm literally seeing this for the first time today.

The other useful case is when you open project on another machine for some reason and you find your usual editor not installed and configured. Open any editor and away you go with this, for those quick dirty edits. I require all editors installed to be able to read .editorconfig files and use them accordingly.

I've evangelised this tool on every team I've worked with for years. It eliminates _so_ many forms of conflict and bikeshedding. (Plus I have contributed in a trivial way to the Emacs plugin; they very happily accept PRs).

At least in the JavaScript world, this was a lovely thing to have. Now we have linters which are even better! Still nice to include this so that all collaborators don't need to modify their editors to jump in!

It's the simple cross editor convenience this brings that really appeals to me.

and now we have https://prettier.io/docs/en/why-prettier.html we can automatically enforce and fix all these style rules

I haven't used prettier but eslint can also fix style

And of course there's https://github.com/prettier/prettier-eslint to fix it using both :)

Do not compare it to linters they serve a different purpose. Editorconfig is for using the right editor settings, linters are for programmatically checking and formatting code. So Editorconfig and a linter should be used together.

I prefer tabs to spaces, not here to argue, and editorconfig is read by GitHub and let's me change tabs to display as 4 spaces instead of eight. A major win. Also allows me to default their editor to tabs.

This is the main reason I use this, though I use 2 space tabs and my coworkers use 4 space tabs. Things get ugly without editorconfig playing cop. I also force it to show rulers. It doesn't make the other devs grow a conscience, tho.

The companion would be eclint in order to lint as part of a git hook or CI test run

https://github.com/jedmao/eclint

"LSP for indentation" :)

Reply on news.ycombinator.com