We can handle confusion with clear documentation. We can easily define
style to mean white space, semicolons, and quotes, and that's it.
Everything else falls more into the category of patterns than style.
I think what you're talking about is doing this:
style: [2, {
quotes: "double",
indent: "\t"
}],
That is definitely an option as well. My only concern was with having a
giant blob in the middle of the other rules, but perhaps that's not such a
big deal.
On Thu, Feb 13, 2014 at 2:51 PM, Ilya Volodin <[email protected]> wrote:
> I'm not sure I fully understand the reason behind separate section and
> options style. Why can't we just make sure that style rules accept
> parameters that can switch between tri-states? We already have a mechanism
> for that. I do agree with parameters vs. separate rules, however. In my
> mind, a lot of our rules that aren't specifically styling (in terms of how
> the code looks) but fall under broader styling bracket (like
> consistent-return, max-params, no-extra-boolean-cast, etc). I feel like
> people might be confused by section separation.
>
> My only concern with the way we do things now, is that if all styling
> rules will support tri-state, some of them might become quite big and
> complex. Would love some mechanism to separate them out, while only expose
> one rule in config.
>
> Thanks,
>
> Ilya Volodin
>
>
> On Thursday, February 13, 2014 5:17:12 PM UTC-5, Nicholas Zakas wrote:
>
>> Hi all,
>>
>> I'd like to get some opinions on this. As I've been reviewing the
>> existing rules, we have a bunch that fall into the category styling: line
>> length, semicolons, etc. I've been having some heartache around the
>> tri-state nature of these rules. What I mean is, our rules are mostly
>> binary (on vs. off), but in reality there are three states:
>>
>> 1) Require something
>> 2) Disallow something
>> 3) Turn the rule off
>>
>> So for the semicolons rule, right now we can enforce semicolons or else
>> the rule is off. We don't have a way of saying "require that semicolons ARE
>> NOT used". If we wanted to add that, what would we do? I don't like the
>> idea of adding a no-semi rule, because that makes semi and no-semi mutually
>> exclusive without any way of indicating this is so (this is what JSCS does,
>> and I really don't like that approach).
>>
>> What I've been thinking is to have a single rule that is responsible for
>> style and add a special section in the conf to specify styling preferences,
>> such as:
>>
>> style: {
>> quotes: "double",
>> semi: "require", // or "disallow" or remove this setting if you
>> don't care
>> indent: "\t",
>> spaces: {
>> inside-parents: true,
>> },
>> newlines: {
>> // etc
>> }
>> },
>>
>> rules: {
>> style: 2
>> }
>>
>> Then there would be a "style" rule that is responsible for applying
>> everything in the style section.
>>
>> This is still a very raw idea in my brain, so I'd like to hear some
>> opinions on this.
>>
>> Thanks.
>>
>>
>>
>> --
>>
>> ______________________________
>> Nicholas C. Zakas
>> @slicknet
>>
>> Author, Professional JavaScript for Web Developers
>> Buy it at Amazon.com: http://www.amazon.com/Professional-JavaScript-
>> Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ESLint" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
______________________________
Nicholas C. Zakas
@slicknet
Author, Professional JavaScript for Web Developers
Buy it at Amazon.com:
http://www.amazon.com/Professional-JavaScript-Developers-Nicholas-Zakas/dp/1118026691/ref=sr_1_3
--
You received this message because you are subscribed to the Google Groups
"ESLint" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
