Code Styles Conventions via EditorConfig

[tajmone]

I propose enforcing code style conventions via EditorConfig settings in order to keep commits clean from whitespace noise. I usually set up my documentation proejcts to use EClint for validating all commits and PRs via Travis CI.

I'll happily volounteer to setup the whole EditorConfig, EClint and Travis CI setup and submit a PR — i.e., if the proposal is accepted.

[FichteFoll]

Could you point me/us to an example project using editorconfig? I suppose the only configuration we would be interested in is using LF line endings and a newline at the end.

[tajmone]

Could you point me/us to an example project using editorconfig?

This is an AsciiDoc documentation project, but it also contains markdown files:

https://github.com/tajmone/hugo-book

The files in question are:

• .editorconfig
• .travis.yml
• validate.sh

I suppose the only configuration we would be interested in is using LF line endings and a newline at the end.

For line-endings, EditorConfig is useful only when you need to enforce an EOL for all OSs, otherwise to use native EOL .gitattributes are fine.

Besides the empty line at the end of file, EditorConfig can also check that there's not trailing space/tabs at line ends, and can enforce indentation styles (spaces vs tabs) and size (optionally, for spaces), as well as encoding.

[FichteFoll]

I'm not concerned about encoding, as I trust everyone and everything to be using UTF-8 by now. Trailing spaces are a good point, if EC has a setting for that. Markdown does have significant trailing spaces in the form of two spaces to indicate a line break, but I hate that feature and always use <br> instead. It would be good to enforce this on the code base, I believe.

With Markdown, the indent style basically has to be spaces, but I would always prefer visual indentation for indented lists over set indentation rules. Besides, text indented with 4 spaces or more is considered an inline code block.

I'll probably set something up over the weekend. Thanks for the references.

[tajmone]

Markdown does have significant trailing spaces in the form of two spaces to indicate a line break,

This is only supported in some markdown specs, so it can't be relied upon for all markdown converters. I usually work with pandoc, wich supports most markdown features and allow to enable specific features like this one in case they're needed.

With Markdown, the indent style basically has to be spaces, but I would always prefer visual indentation for indented lists over set indentation rules. Besides, text indented with 4 spaces or more is considered an inline code block.

Indentation is best set as "spaces" with unset width (or "1"), because inclusion of code examples often leads to odd indentations that would raise a validation error in case multiples of 2 (i.e. even) where specified. Of course, the markdown specs allows tabs indentation, but personally I prefer setting it to spaces, especially since in case of an added space after a tab (for alignment) the validator would fail the test.

The whole idea of using EditorConfig is that its settings are automatically picked up by most modern editors and IDEs, allowing project specific settings to override user settings. So, ultimately, end users wouldn't have to worry about the details, as long as their editor supports EditorConfig.