6 ms·

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

Zombieball 11y ago
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).
beaker52 11y ago
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.
- beaker52 11y ago
  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.
  - Maken 11y ago
    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.
- teamhappy 11y ago
  But editors can infer these settings anyway.
  - beaker52 11y ago
    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/UTF-8/list.htm http://www.fileformat.info/info/charset/US-ASCII/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.
    - teamhappy 11y ago
      > 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.
      - beaker52 11y ago
        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.
      - 1wd 11y ago
        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.)
sotojuan 11y ago
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 https://github.com/feross/standard [2] https://github.com/Flet/semistandard https://github.com/Flet/semistandard
- Killswitch 11y ago
  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.
hoorayimhelping 11y ago
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.
maaaats 11y ago
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.

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).

beaker52 11y ago

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.

beaker52 11y ago
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.
- Maken 11y ago
  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.
teamhappy 11y ago
But editors can infer these settings anyway.
- beaker52 11y ago
  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/UTF-8/list.htm http://www.fileformat.info/info/charset/US-ASCII/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.
  - teamhappy 11y ago
    > 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.
    - beaker52 11y ago
      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.
    - 1wd 11y ago
      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.)

sotojuan 11y ago

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 https://github.com/feross/standard [2] https://github.com/Flet/semistandard https://github.com/Flet/semistandard

Killswitch 11y ago
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.

hoorayimhelping 11y ago

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.

maaaats 11y ago

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.