Percent literal brackets

[christianrolle]

In general I agree with the percent literal styles.
It clearly makes sense to avoid other delimiters than brackets for escaping reasons.
Additionally I would like to question using squared brackets for Array literals is a bad practice, like:

%w[Ruby Javscript Python]

compared to:

%w(Ruby Javscript Python)

I am very interested in the reason for the decision.
From my point of view it expresses the Array character way more. Please let us discuss it.
My thoughts about percentage notations

[bbatsov]

I agree this is a reasonable usage of square brackets.

[christianrolle]

I am a little surprised. I expected some kind of refusal.
Agreeing this is a reasonable usage of square brackets contradicts the current published style guide.
What does your comment mean?
Does it mean that the style guide could be changed?

[bbatsov]

I am a little surprised. I expected some kind of refusal.
Agreeing this is a reasonable usage of square brackets contradicts the current published style guide.

Like most projects, the guide is never truly finished. :-) As I've said many times - I don't view myself as its author, but just its editor and I'm always open to reasonable suggestions.

Does it mean that the style guide could be changed?

Yes.

[christianrolle]

O.K. Then I'll send a pull request and let's see, what the community will think about it.

[onebree]

Some comments about percent-literal brackets:

1. Using hard brackets for percent-literal arrays natually convey the fact you are creating an array.
   • @dpisarewski - 8b14825#commitcomment-10694665
   • @onebree - 8b14825#commitcomment-10695190
2. If the rule states to only use parenthesis, then why does the "good" section list also curly braces?
   • @gkop - 8b14825#commitcomment-16597416

[ibartley]

I would like add a vote in favor of the use of square brackets when referencing or inferring a reference to an array. In my humble opinion parenthesis imply params. If %w is a function and the elements of an array are parameters then parens make sense, otherwise brackets seem to convey the message with natural clarity.

[Drenmi]

I am not a frequent user of this notation myself, but I can imagine the distinction between a bare array literal and these serves a purpose. If I'm looking at the trailing end of a percent literal like this:

... foo bar]

I must first notice the missing comma, and then follow the line to the beginning to see that it's actually a percent literal, and not a bare array literal with a syntax error.

Now, this is completely speculative, and I am slightly in favour of the change myself, but thought I'd try to argue for the other side for a balanced discussion. 😀

[savef]

I do use the percent literal arrays quite often and I disagree with this change. As @bbatsov does, I think square-bracket percent literals for arrays are perfectly reasonable, but I think rounded brackets are just as reasonable and that's where my personal preference lies. I don't think there's enough of a distinction between a normal array and the square bracket percent-literal array.

It makes sense to me that we have an array shorthand in-line with JSON in [one, two], and that an array of strings shorthand would require some special syntactic sugar that sets it apart from other arrays, and different brackets ensure that.

Both positions are personal preference, and as far as I've seen over the years the rounded brackets is the more popular option. Here are the stats on usage of 3 styles in the Rails codebase:

~/work/rails $ grep -rE "%w\(" | wc -l # %w(a b c)
683
~/work/rails $ grep -rE "%w\[" | wc -l # %w[a b c]
43
~/work/rails $ grep -rE "%w\{" | wc -l # %w{a b c}
85

By no means do I think of the Rails codebase as a style guide, but it's probably a decent indicator of popularity. So since there's no overwhelming majority one way or the other - and if anything a majority on the side of rounded brackets - I'm not sure why we would change it.

I appreciate that other people have different personal preferences (as I have plenty that differ from this style guide), but that's why we have the ability to configure options like this in RuboCop...

[bronson]

In light of #563, can this be closed?

[christianrolle]

Sure :)