I can see your point. My main concern was about trying to determine the
correct name for rules. Right now, we do "no-*" to say something is
disallowed while "*" says something is enforced. So having something like:
semi: [2, "none"]
means that semicolons are disallowed, but then why do we have:
no-floating-decimal: 2
Should that now be:
floating-decimal: [ 2, "none" ]
I just really want to do something that is unambiguous and easy for
end-users to modify.
On Thu, Feb 13, 2014 at 3:35 PM, Ilya Volodin <[email protected]> wrote:
> 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]> 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.
>
--
______________________________
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.
