Adding an editorconfig file to maintain consistent coding

[mikealmond]

See http://editorconfig.org/

[treyhunner]

That file works as long as jQuery and Modernizr are not expected to be edited.

I personally prefer to be more explicit (also doesn't catch jQuery and Modernizr this way):

[**.html]
indent_style = space
indent_size = 4

[css/*.css]
indent_style = space
indent_size = 4

[js/*.js]
indent_style = space
indent_size = 4

However, the less verbose (and less explicit) style might be more fitting for HTML 5 Boilerplate.

[necolas]

Not sure this is going to be very useful for the project. I suspect the reality is that most people won't have their editor set up to use it, or will follow their own style independent of our source style.

[treyhunner]

Yes, using a different independent style could be an issue (bad documentation is worse than none at all).

If an .editorconfig file is included maybe it should be included more as a suggestion (similar to the humans.txt file).

Example:

; editorconfig.org
root = true

; Uncomment to use Unix-style files with 4 spaces for indentation
; [*]
; end_of_line = LF
; indent_style = space
; indent_size = 4

[.htaccess]
indent_style = space
indent_size = 2

[drublic]

I like the idea of including it.
We serve a set of files that should be ignored by git, we include a robots.txt, a humans.txt, so why not include a good set of rules for the editor that we think are a good decision to use in every project.

Users who do not want to use this kind of style in their editor might change/remove the file. The same goes for the other files mentioned. I think it does not hurt anyone's project.

I'm +1 on this.

[mikealmond]

The reasons I had for including this were exactly the same as @drublic's. I see this file more like a boilerplate than a strict standard that everybody must follow. Everybody has their own opinions on style individually and when working with a team. Having this included in the H5BP repo, would allow people to easily change it to match their defaults. If they don't want to use it, the boilerplate is delete key friendly.

[necolas]

We've also attempted to remove a lot of clutter from the project. Ignores, Robots - they serve an important function. I don't think "delete key friendly" should be used as a justification for adding more to the project without serious consideration. The amount of content in the boilerplate, the number of dirs, the large number of inline comments, etc., seemed to be putting some people off and perpetuating the myth that the boilerplate was "bloated".

We removed the build script, which is really useful, because not enough people were using it. I suspect even fewer people are going to use an editorconfig or take the time to download a plugin (if there is one) for their IDE. So I want to be sure of the value and use of things before we start adding more.

[alilleybrinker]

I'm -1 on this. As @necolas said, there is already a perception amongst some that the project is bloated. The inclusion of this sort of file which many people won't understand, and which may or may not be supported by their chosen editor seems like a bad idea. Besides, are there really that many issues with people using different editors that this is a must-include? The boilerplate is supposed to be about providing a solid starting point for web development, and should only address those issues that are widespread and pressing. Smaller issues like discrepancies between editors seem to fall outside of the range of the project.

[mikealmond]

@AndrewBrinker I don't see this as a discrepancy between editors. I see this more as a way for contributors of web projects to have a clear set of rules to follow on a project-by-project basis. Which is something a boilerplate can handle.

Regarding bloat of the H5BP project, could this be solved with #1048 or removing 5 of the apple touch icons?

[necolas]

Removing the touch icons would remove end-user features.

[treyhunner]

The boilerplate is supposed to be about providing a solid starting point for web development, and should only address those issues that are widespread and pressing. Smaller issues like discrepancies between editors seem to fall outside of the range of the project.

The primary purpose of a .editorconfig file is to unify indentation (and other file format properties). The issue isn't one of differences between editors so much as differences in preference. The only developers that told me this was a non-issue for them were using company computers with a uniform indentation company-wide.

In H5BP this would be a suggested solution to a common problem and may be removed/ignored when it is unnecessary (like .gitignore, .gitattributes, .htaccess). However, if this is included in H5BP if style is enforced using wildcards (*), this would be making a statement about the correct indentation to use for the files matched. I think that may be a bad thing.

[drublic]

As Trey said, HTML5BP is a role-model and if we suggest to use a certain syntax we should be sure about it. I think it will help the HTML5BP project, as we encourage users to stick to a certain syntax they decided on and not to mix stuff.

For my projects I'm currently using another configuration and I think everyone who wants to have other styles may change the .editorconfig. Many people may not respect the editor-config at all for their own projects.

[sindresorhus]

I think this should be included. Indentation, EOL, etc, inconsistencies has been an issue in almost all OS projects I've been involved with. IMHO provide sane defaults and let the user customize if needed.

EditorConfig is soon getting more properties like; charset, trim_trailing_whitespace and insert_final_newline, which will make it even more useful.

[necolas]

I like the idea of enforcing code consistency, but I'm not entirely sold on EditorConfig yet (and its inclusion by default here) since it requires the use of an appropriate editor plugin to have any effect.

[sindresorhus]

Would it help if I said I was working on a grunt plugin :p

Also, most of the popular text editors are supported:

Code::Blocks
Emacs
Geany
Gedit
jEdit
Notepad++
Sublime Text 2
TextMate
Vim
Visual Studio

I can see your concern with the user having to install a plugin. But this is really a chicken/egg problem. User won't have the plugin if they don't know about it, and you're concerned about including it since user probably don't have the plugin. Having this in H5BP would really help the adoption and would in my opinion make Open Source codebases more sane.

And remember it's not all or nothing. Some people might have the plugin and get the benefit, some don't. You would still have the guidelines in written form. The EditorConfig plugins are just an automatic enforcement convenience.

[necolas]

I guess it doesn't help that the Vim plugin doesn't fill me with confidence, as it requires Vim to be compiled with python (or you have to install the EditorConfig core too). If I can do all this in a couple of lines of code in Vim, I'm not that excited about having to add all that stuff to have it happen via an EditorConfig instead.

[treyhunner]

I agree that the difficulty of installing some of the plugins is a problem. As Sindre noted, this is a bit of a chicken and egg problem. Most text editors probably won't add support unless the file format is widely used and many developers won't add support until they can actually use the file format with their text editor of choice. The editor plugins will hopefully serve as a compromise until we can get native editor support for the file format.

As for the vim plugin specifically, I've considered re-implementing a version in pure VimScript (we actually used to have one that didn't quite work), but we haven't heard any complaints about Vim being compiled without Python support yet so I delayed that project.

[Garbee]

I am opposed to this inclusion. I don't see how this in any way affects a site. It only affects the style of development which each person has their own style as previously stated. I think the Boilerplate should remain aimed towards getting a site going quickly, not editor preferences.

[irae]

I agree with this inclusion, but as noted before, for me the greater benefit for is that by providing an .editorconfig file H5BP will be suggesting that people use one on the projects they are starting.

Recently I added this file to all of my current projects and never had a problem again with white space configuration and team collaboration. Providing a file with comments and some reasonable defaults, IMHO will be beneficial to every project that uses HT5BP.

[sindresorhus]

^ +1

[paulirish]

The humans.txt file has no benefit, but is lovely for the developer group working on the project (i just saw this xoogler startup one today )

the editorconfig file, similarly, is part of an emerging defacto standard. But helps greatly in keeping editors consistent and avoiding bad merges and repetitive communication about coding standards. I would love to see it in h5bp and have also been quite happy with its inclusion in my projects.

[christianbundy]

Using .editorconfig standardizes coding style, which is necessary on a project of this magnitude. Whether or not h5bp is bloated or not is irrelevant - the fact remains that the current state of the project could benefit from standardization.

We're web developers. Let's make a standard, and stick to it.

[necolas]

Using .editorconfig standardizes coding style

Only if you use an appropriate plugin. At the moment, we don't have any significant style issues in the code and none that would have been prevented by using something like editorconfig.

I'm going to close this for now.