search

dwyl / goodparts

:see_no_evil: An ESLint Style that only allows JavaScript the Good Parts (and "Better Parts") in your code.
GNU General Public License v2.0
78 stars 26 forks source link

indent #201

Open eliasmalik opened 8 years ago

eliasmalik commented 8 years ago

http://eslint.org/docs/rules/indent

"indent": ["error", 2]

4-space indent is reccommended by goodparts http://jslint.com/help.html but going with 2

samhstn commented 8 years ago

I think quite a few people in our space are using a 2-space indent, my preference would be to use 2 spaces. Is there a reason to choose 4-space indent?

SimonLab commented 8 years ago

I think I prefer 2 spaces also, 4 looks a bit too much. @eliascodes @jrans @nelsonic what is your preference?

jrans commented 8 years ago

@simonLab @shouston3 2 please!

eliasmalik commented 8 years ago

My preference is 2 as well, but do any of us have a reason?

samhstn commented 8 years ago

@eliascodes I find it nicer to write and easier to read

nelsonic commented 8 years ago

@shouston3 @SimonLab @eliascodes @jrans (and anyone else interested...), While I agree with DC http://jslint.com/help.html that 4-space can be easier to scan when you are reading code, I prefer 2 spaces. Given that the 4 space convention does not affect the reliability or quality of our code, I'm happy to use two spaces ... good-parts-4-spaces

howardroark commented 7 years ago

I'd like to try this out, but I do use 4 space tabs everywhere... Think I'm out of luck?

Whitespace is kind of one of those things... a "when in rome" deal. Could it be more adaptive? As in... "I see you use 4 space tabs... ill make sure that persists".

nelsonic commented 7 years ago

@howardroark great question! We prefer 2-space in our JS code... but in Elm we use 4-space ... I think it really depends on the convention used in your team...

iteles commented 7 years ago

If we end up having them, this is probably the best candidate I've seen to date for custom rules: https://github.com/dwyl/goodparts/issues/231

eliasmalik commented 7 years ago

@iteles I think a custom rule would be something that the eslint parser doesn't currently support. It does support indent rules, the question is whether we want to allow it to be configurable (and whether that's even possible).

nelsonic commented 7 years ago

@eliascodes I think that for our purposes having a customisable indent is way beyond the scope of the required functionality for goodparts but if a community member wanted to PR that feature we would accept it to make the plugin useful to others... 😉

jrans commented 7 years ago

@howardroark I think it'd be really nice to be able to write over the rules you want to ignore easily.

I suggest you just take the rules object from the node module located at rules/ and then use it as a basis for your own eslint config.

In the process you may come up with a neat way to customise the default which you can share 😄

nelsonic commented 7 years ago

@howardroark the purpose of creating this repo was to have a standard across our projects using fewer well-defined language features so that code would look the same regardless of who wrote it. if you need configurability/customisation please see: https://github.com/sindresorhus/xo 👍

howardroark commented 7 years ago

Makes sense. I can just fork it anyway :) Thanks!

Fl4m3Ph03n1x commented 7 years ago

So, even though DC suggests 4 spaces, the project accepts 2 and there are no plans of a configuration file, correct?

To make everyone happy, could we not make it just a warning, instead of an error?

nelsonic commented 7 years ago

@Fl4m3Ph03n1x good question/point! We prefer 2-space, but a warning might be better than an error... however having many warnings in the console each time we make a commit (when using pre-commit hooks) will get v. noisy.

Fl4m3Ph03n1x commented 7 years ago

@nelsonic good point with with noise. I am all out of ideas then :P