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

by s_chaudhary • 9 years ago

164 31 9 years ago

lytedev• 9 years ago

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!

nmstoker• 9 years ago

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

qntmfred2• 9 years ago

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

andreineculau2• 9 years ago

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

Siilwyn• 9 years ago

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.

vortico2• 9 years ago

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.

Galanwe• 9 years ago

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.

serkanyersen2• 9 years ago

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.

vortico2• 9 years ago

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".

SideburnsOfDoom2• 9 years ago

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.

sametmax• 9 years ago

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.

qntmfred2• 9 years ago

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

Brajeshwar• 9 years ago

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.

StavrosK• 9 years ago

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.

andreineculau2• 9 years ago

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

https://github.com/jedmao/eclint

duncan_bayne• 9 years ago

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).

serkanyersen2• 9 years ago

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.

majewsky2• 9 years ago

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

JetSpiegel• 9 years ago

See also vim-sleuth

HyperMassive• 9 years ago

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.

to3m• 9 years ago

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.)

rxdazn• 9 years ago

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

majewsky2• 9 years ago

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

ewanm89• 9 years ago

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.

mrkgnao• 9 years ago

"LSP for indentation" :)

donatj• 9 years ago

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.

gibbitz• 9 years ago

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.

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

Related Stories