> For Windows Users: To create an .editorconfig file within Windows Explorer, you need to create a file named .editorconfig., which Windows Explorer will automatically rename to .editorconfig

What a neat trick I had no idea. Been renaming those files on the cli all this time.

On a related note: Why has it gone the way that I must look at code your way. Is there no chance of decoupling the presentation with logic like the web has long preached us (not saying that worked). Tabs to spaces shouldn't be some messy commit regardless of your preference on the matter.

Anyway, nice project. I understand your search preferences up from the project root not down from my preferences because it's controlling other people's coding standards.

You can _look_ at it whatevery way you want - that's the job of your IDE. But if you _edit_ (in) it, your changes should be saved in the way the author decided to keep one standard in one codebase.

PS: Whooop on the Windows trick! So useful.

That's assuming the code-base was still saved as a representation rather than a syntax tree that can be viewed in whatever way a given developer prefer. There's no reason that has to be the case. In fact intuitively i'd be inclined to say its probably easier to write a VCS for a syntax tree than a free text string?

Last time I checked my codebases were all plain text files.

But yes, having a syntax tree would solve this problem quite nicely.

(But to make it work universally you have to decide on a representation of this syntax tree to be able to represent it in plain text files to make it work with all the editors and IDEs that don't support that syntax tree stuff... And then we're back to .editorconfig, aren't we?)

The modern/popular way is to run a format tool before you commit. (gofmt, clang-format, etc)

A VCS for syntax trees means you need the One True Data Format(tm) for syntax trees in any language. Finding consensus on formatting per project is easier than unifying all syntax tree representations globally.

Additionally, there are many reasons you might want to commit work in progress code that doesn't/won't parse correctly to a "proper" syntax tree. While there are certainly workarounds (pseudo-trees for "malformed"/"unfinished" sections), there's entire neighborhoods of bikesheds to paint there. (Amongst the major compilers thus far the only ones I've seen invest useful time in mostly unified intermediate syntax trees is the Roslyn compilers for C#/VB, often compilers don't care but Roslyn had the opportunity/drive/interest to try to merge a lot of editor support directly into the compiler infrastructure.)

(Aside: I built a cool proof of concept for what I think is the most useful "smart middle ground" here, which is to use syntax highlighting lexers (tokenizers) for a useful effect in creating smart character-based diffs. Syntax highlighting lexers are designed for intermediate code and with output as ordinary character diffs you don't have to bikeshed a universal token stream format. The tokenized diffs were cleaner and faster than the equivalent non-tokenized character diff. https://github.com/WorldMaker/tokdiff if anyone wants to play with it.)

The two examples I can think of is ColorForth[1] (not sure what the representation is there, or how/if one would couple it with a (D)VCS), and of course Smalltak with it's DVCS Monticello:

http://news.squeak.org/2008/08/15/all-new-monticello-2/

I had no idea there was such a new rewrite (2008), but then I keep forgetting that DVCS are rather new (as in popular, free-software DVCS are pretty new - git is just over 10 years).

[1] http://www.colorforth.com/cf.htm [It would appear that the on-disk representation is rather simple and straight forward, but you're only supposed to use a ColorForth aware editor (eg: ColorForth)]

> I keep forgetting that DVCS are rather new (as in popular, free-software DVCS are pretty new - git is just over 10 years).

Are you saying git is not popular, is not free software, or something else?

I'm saying 10 years is new (and that eg: bitkeeper and monotone is older than git).

No, they're saying that unpopular, unfree DVCSes are less new.

Performing merges and handling conflicts seems like a harder problem than for text.

I've often wondered this. I find columnar alignment of key:value pairs (in CSS, dictionaries, etc) to be much easier to read, but I find that I'm an outlier because most people get upset when they see whitespace changes in a diff. (FWIW, `?w=0` will hide whitespace changes on GitHub).

It would be rad if an editor like Sublime or Atom understood columns and displayed code that way without needing to reindent everything in the file every time you add a longer key.

It's called elastic tabstops. [1] The page links some editors that implement this and some plugins for other editors. Apparently SublimeText's plugin is incorrect though. It does not mention Atom, but it was discussed in [2].

[1] http://nickgravgaard.com/elastic-tabstops/ [2] https://discuss.atom.io/t/elastic-tabstops/16/23

I find it more readable up until the difference in key lengths becomes larger (font and text-decoration for example), at which point I have trouble matching the values with the shorter names.

Just right-align your property names. I know that sounds ridiculous, but give it a go:

  body {
             font-size:  16px;
         margin-bottom: 100px;
           padding-top:  40px;
                 color: rgb(100, 100, 100);
      background-color: rgb( 90, 255,   3);
  }

Oh way better yes. I sometimes like to indent dependent properties too:

  body {
    width: 400px;
    margin: 20px;
    position: absolute;
        bottom: 0;
        right: 0;
    background: #ccc;
  }

For those who don't know, github recently started supporting editorconfig[0] files in repos, which means that if your repo has an editorconfig, it will be respected by github in the online code viewer. Without an editorconfig file, the default indentation on github is 8 spaces, because that's how pre tags work. See the link for more info.

[0]: https://github.com/isaacs/github/issues/170#issuecomment-137...

For more see the numerous older discussions of this https://news.ycombinator.com/from?site=editorconfig.org

HN has a direct link to this feature now. There's a link under the story labeled "past." Although it goes to the official search instead of your link. Cheers.

Nice. I'm addicted to automatically running `gofmt` on .go file saves.

Now I'm crazy sensitive to whitespace and formatting discrepancies that show up in .js or .css files from different environments. It seems like EditorConfig has a shot at improving this, particularly since GitHub supports it.

Next step, strict linters/formatters for all languages.

Edit: Based on other comments pointing to the Javascript standard style project, I found this to auto format .js files in Sublime Text:

https://packagecontrol.io/packages/StandardFormat

The IDE has now become an abstraction. Love it.

Wasn't there an old standard for text format strings that could be placed at the end of source files that would be understood by Vim and Emacs? I never used it, but this reminds me of it.

Vim has modeline[0]. Is that what you meant?

[0] http://vimdoc.sourceforge.net/htmldoc/options.html#%27modeli...

And the Emacs equivalent, file-local variables[0]. However, these are editor-specific, as far as I'm aware, although Python was able to extract the commonalities between them to support file encoding in PEP 0263[1].

[0] http://www.gnu.org/software/emacs/manual/html_node/emacs/Spe...

[1] https://www.python.org/dev/peps/pep-0263/

Could this be extended to keyboard shortcuts? I always feel like the effort I have to do setting the shortcuts on a new IDE is redundant, and shared with a lot of people

Um... No thank you?

pd: the last thing I want as a developer is a developer on Windows overriding my OSX keyboard shortcuts (or viceversa).

I think that is a different problem than what this solves, as this tries to make it easy to enforce a code style for a project across multiple editors, while shortcuts are inherently more personal and editor-specific.

SublimeText shortcuts and other preferences are just text files on the filesystem, which you can share. Hell, in SublimeText, the menu items to change keyboard prefs just opens the JSON for for you to edit by hand

yes, because coding style can be reduced to charset and indentation choice

It's one less thing to think about.

Anyway, for JavaScript there's the standard[1] and semistandard[2] projects. They are different from other style guides because they're standalone applications that would fail your tests if your files do not adhere to the standard (if set up correctly). Think of them as unconfigurable linters.

[1] https://github.com/feross/standard [2] https://github.com/Flet/semistandard

I use Standard and love it. Every project I build gets standard as a devDependency in my package.json and I use linter and linter-js-standard plugins for Atom to automatically detect it and lint my project as I write it.

Then have some hooks in place that will run code through standard again in a pre-commit hook, and then PR's on GitHub are also ran through standard.

No, but ignoring these basic project conventions can lead to issues when another developer tries to work with the file, specifically around charset and line endings.

editorconfig only defines the following properties:

  charset
  indent_style
  indent_size
  tab_width
  end_of_line
  trim_trailing_whitespace
  insert_final_newline

These are all sensible things to enforce (with the exception of tab_width, which is actually a display preference). Subjectively, other things are mostly flexible.

There are more properties listed in the complete list (link is above the short list), mostly about parenthesis and braces. I guess they aren't listed in the main page because they are language-specific.

But editors can infer these settings anyway.

Partially. Some editors can infer things like indentation and new lines by looking at the existing file, yes. Crucially, what about new files?

For charset, this needs to be defined since charsets share byte encodings:

http://www.fileformat.info/info/charset/UTF-8/list.htm

http://www.fileformat.info/info/charset/US-ASCII/list.htm

Same goes for new line at the end of the file, how do you know ALL files of this type are meant to end with a new line or not?

Inference doesn't completely solve the problem that editorconfig solves. That said, if you don't want editorconfig then don't use it. If you're working on a project that uses editorconfig, feel free to ignore it - as long as you adhere to the code style of that project. editorconfig is simply a tool to help you adhere to a project code guidelines.

    > Crucially, what about new files?

vim-sleuth handles this one by looking at similar files in the same directory (or the rest of the tree, if it doesn't find any.)

    > For charset, [...]

Almost all code bases use UTF-8 without BOM, which also happens to be the default encoding in most editors.

    > Same goes for new line at the end of the file, 
    > how do you know ALL files of this type are meant
    > to end with a new line [...] ?

POSIX wants the newline.

I get your point though. I used to use editorconfig myself, but it didn't really do anything for me. IMHO linters/formatters do a much better job.

That's cool, but that's one plugin for one editor - editorconfig is a simple plugin with a very wide range of support to solve the problem it solves.

Linters and formatters are great for enforcing code styles but they tend to be per language and require more configuration, shy of ripping off an existing spec.

If you don't want to go the whole hog and only need some basic constraints then editorconfig is easy to throw into a repo root.

Notepad++ defaults to Ansi (although it can be changed). Visual Studio defaults to UTF-8 with BOM. (And I don't think you can change that easily.)

"ANSI" hardly counts as a default. (ANSI is MS's incorrect term to mean the system's encoding, which can be any of a number of different character sets.)

c'mon, really? Did anyone say anything about reducing coding style to indentation? Standardizing these things is actually what gives you a platform for your beautiful and unique coding style to emerge for everyone to admire and coo over. If everyone is always arguing over tabs vs spaces and which charset to use, no one will notice how your beautifully styled guard statements have changed their entire outlook on writing code.

I also noticed the limited set of rules.

Does anyone on HN have suggestions for code style guides with cross IDE support? Ideally I would like something similar to Google's code style guidelines with settings to import into IntelliJ and Eclipse for Java, html/css, sass, JavaScript, maybe even frameworks such angular. The Google guidelines only appear to have IDE settings for Java (in this list).

What about listing what you think it misses so an actual discussion can be had? Much better than dismissing someone's work in a stupid way.