To clarify my thoughts on the issue:
I'm not sure that we need style section at all. I think defining things
like this:
rules: {
quote: [2, "double"],
indent: [2, "\t"],
semi: [2, "always"]
}
is perfectly fine. My concern, however, is that if semi rule has to support
both always requiring as well as prohibiting semicolons in a single file,
that file might become quite large and hard to deal with. In my mind,
styling rules like that are not really all that different from patterns, I
might not care at all about what type of indentation people use, and want
to just disable the whole thing. Also, creating another section, will make
it harder for others to create their rules. If somebody wants to create a
rule that they really think needs to go into "style" section, we will have
to provide a way to do that. I guess what I'm saying I'm not seeing much of
a benefit in separating styling rules from the rest.
Thanks,
Ilya Volodin
On Thursday, February 13, 2014 6:21:19 PM UTC-5, Nicholas Zakas wrote:
> 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]<javascript:>
> > 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] <javascript:>.
>> 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.
