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
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
EditorConfig – file format for defining coding styles and text editor plugins
31–32 of 32 posts
Re: EditorConfig – file format for defining coding styles and text editor plugins
#32Earlier quoted context omitted.
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…
I don't much care for Go the language, but shipping a formatter with the compiler is an utterly genius move.