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
EditorConfig – file format for defining coding styles and text editor plugins
21–30 of 32 posts
Re: EditorConfig – file format for defining coding styles and text editor plugins
#22Looks like 99% of this is covered by my editor being configured to autodetect existing indentation, and adjust itself accordingly: https://github.com/ciaranm/detectindent
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.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#23Looks like 99% of this is covered by my editor being configured to autodetect existing indentation, and adjust itself accordingly: https://github.com/ciaranm/detectindent
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
Re: EditorConfig – file format for defining coding styles and text editor plugins
#24Earlier quoted context omitted.
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 :)
Re: EditorConfig – file format for defining coding styles and text editor plugins
#25Looks like 99% of this is covered by my editor being configured to autodetect existing indentation, and adjust itself accordingly: https://github.com/ciaranm/detectindent
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.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#26Looks like 99% of this is covered by my editor being configured to autodetect existing indentation, and adjust itself accordingly: https://github.com/ciaranm/detectindent
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.)
Re: EditorConfig – file format for defining coding styles and text editor plugins
#27I 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.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#28I 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.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#29EditorConfig 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.
Re: EditorConfig – file format for defining coding styles and text editor plugins
#30Before 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…
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.