Rules for spaces inside various parens

[jscs-dev]

Rules for spaces inside various parens

[mdevils]

Looks like a complex behavior. Try to split in a row of simple rules. (See current rules for examples)

[jzaefferer]

@markelog is this something you could look into? Would be useful to get this into the jQuery preset.

[markelog]

@jzaefferer yes, it's on my list, although there is couple more issues with jscs and grunt plugin that has to be fixed before i can work on this ticket.

[mikesherov]

@markelog are you prepared to take this one on? If not, I can jump in on it later this week unless you'd like to continue on it. Just let me know. Thanks!

[markelog]

@mikesherov hey! i want to do cool things too you know :-).

I also wanted to work on this in this week, how about if i fail to get time on it, you would pick it up?

[mikesherov]

@markelog take your time! I was just trying to triage everything that remains open. Glad to have you take it on and I'll wait patiently :-)

[markelog]

array = [ a, b ];
object = { a: b };

Already supported by requireSpacesInsideObjectBrackets and requireSpacesInsideArrayBrackets rules.

But there should be abilities to check for cases like these:
if(...), for(...), while(...), catch(...), switch(...), case(...), with(...), FE, FD and etc; plus function calls.

Which would be easy enough to implement as antonim of disallowSpacesInsideParentheses, like requireSpacesInsideParentheses.

But problem with it, is that parentheses could also be used for grouping, for that case it's preferable to check for absence of extra spaces, i.e. this case –

for ( ; (elem = elems[ i ]) != null; i++ ) {

should be valid, but this one shouldn't –

for ( ; ( elem = elems[ i ] ) != null; i++ ) {

In style guide mentioned above, this case is not explicitly included, but it will be, if it could be automatically checked.

So all that could be done with rules like these –

"requireSpacesInsideParenthesesForKeywords": ["for", "function"],
"requireSpacesInsideParenthesesForFunctionsCalls": true
// or with possible object value like this –
"requireSpacesInsideParenthesesForFunctionsCalls": {
    "exceptForClosestPunctuators": ["{", "}"], 
},
"disallowSpacesInsideGroupingParethenses": true

Or something less verbose or contrariwise?

But such tactic (especially with disallowSpacesInsideParentheses rule at hand and possible future opposite rules for those above) would contribute to bloatedness of current options.

@mikesherov, @mdevils thoughts?

[markelog]

Oh, yes, empty parentheses should be treated tolerably, similar to requireSpacesInsideObjectBrackets and requireSpacesInsideArrayBrackets.

[jzaefferer]

The jQuery style guide used to have exceptions for nested parens, those were removed. So in your two for examples, the first one is invalid, the second one valid.

Do requireSpacesInsideObjectBrackets etc. accept [] and {} as valid?

[mikesherov]

Only allows no spaces if you use "allButNested". 

My 2 cents is that the jQuery nested spacing rules belongs as a custom rule in the jQuery preset because it has enough caveats to cause a "generic" rule to have too many options. 

This would require us to use my proposal for presets, which not only allows preset configuration, but also custom rules for that "standard".

jQuery would be able to distribute their own JSCS standard, or we could have JSCS-standard-jQuery and go the grunt route of npm based plugins. 

Mike

On Sun, Jan 12, 2014 at 2:21 PM, Jörn Zaefferer [email protected]
wrote:

The jQuery style guide used to have exceptions for nested parens, those were removed. So in your two for examples, the first one is invalid, the second one valid.

Do requireSpacesInsideObjectBrackets etc. accept [] and {} as valid?

Reply to this email directly or view it on GitHub:
#92 (comment)

[markelog]

@jzaefferer

The jQuery style guide used to have exceptions for nested parens, those were removed

it's not about nested parentheses, it's about parentheses that used for grouping and grouping only, nested parentheses still require spaces.

@mikesherov custom rules and custom presets are nice, but i think it would be cooler if jscs would at least support
google, ours and idiomatic code styles right from the start, as they are most used code styles as far as i know.

And they could be a good examples for what you can do with jscs.

[markelog]

Only allows no spaces if you use "allButNested".

No actually :-)

[markelog]

@jzaefferer

Do requireSpacesInsideObjectBrackets etc. accept [] and {} as valid?

Yep.

[mikesherov]

@markelog does this issue get solved by #333 If not, I'll take a stab at implementing this rule soon.

[markelog]

No, we need something that can separate grouping parentheses from all other ones also we need an exception mechanism so we could do:

// Function with a callback, object, or array as the first argument:
// No space before the first argument
foo(function() {
    // Do stuff
}, options );

[mikesherov]

@markelog I think this is a perfect example of a rule that needs to come with JSCS but exists in the jQuery preset only (perhaps even living in that subdir so the preset loads its own special rules). This would help lay groundwork for jQuery specific rules like chaining style as well.

Thoughts?

[markelog]

I think this is a perfect example

This exceptions are exist in idiomatic and jQuery code styles, mediawiki probably could use that to in some way, so i wouldn't say so.

What rules are redundant? What rules are needed? What rules should be added to jscs and what rules should be used only as plugins?

Those are difficult questions, right now, we're subjective about it - we might think some rules are needles or otherwise, but we don't know for sure, we don't know how much people using them or how much people would be using some perspective new rule.

I guess the best way to differentiate them and be objective, is to judge if some popular preset needed it, if it does, then it should be added. No? Use a plugin then.

Pretty simple and easy to understand for rule writers. I would employ this strategy for any new possible rule that could be proposed to jscs core.

@mdevils thoughts?

[mikesherov]

I guess the best way to differentiate them and be objective, is to judge if some popular preset needed it, if it does, then it should be added. No? Use a plugin then.

Not saying it belongs in a jQuery plugin. I was saying it belongs in the jQuery preset as an additionalRule.

[markelog]

Not saying it belongs in a jQuery plugin. I was saying it belongs in the jQuery preset as an additionalRule.

perhaps even living in that subdir so the preset loads its own special rules

Basically, what i'm proposing that if you can't include rule in some of the presets then it shouldn't be in jscs, but if some preset is incomplete without some rule then it should be available in jscs, because it's definitely needed, whereas we can't use phrase "definitely needed" for rule that is not used by one of presets.

[markelog]

So you see, presets could be a measure of importance/popularity of the rule

[markelog]

@mikesherov I guess this should not be a different rule but extension of *SpacesInsideParentheses

[mikesherov]

OK, so then for right now, I think we only need to add rules to cover call expression argument spacing to match the written jQuery style guide. @markelog are you going to tackle this or should I?

[markelog]

Will definitely cover #406 and #402

That is pretty bad-ass problem (grouping parentheses i mean), try it do before, but didn't get anywhere, if you like, you can take a swing at this.

[mikesherov]

But I mean, the jQuery rule is for call expressions seems simple: always space after open parens and before close parens unless the argument is a function expression, array literal, or object literal, right? Or am I missing something?

[jzaefferer]

I may be missing something, but the commit that closed that issue doesn't make any changes to the jQuery preset. Is that intended? Seems like new options would need to be added to the preset...

[markelog]

No, it was a mistake, that commit addressed that issue only partially

[mikesherov]

The saga of this issue has now been resolved by simplifying the jQuery style guide. I'm going to close this issue and file another one just for adding existing rules to the jQuery style guide.