-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rubocop multiline chaining #553
Comments
Are you referring to the indenting or to the dots? |
Uh, sorry, from the issue it's obviously the indenting. |
I tend to change that cop's setting to a = [1, 3, 5].map { |i| i + 1 }.
map { |i| i + 2 } I would then probably move the first map to a separate line: a = [1, 3, 5].
map { |i| i + 1 }.
map { |i| i + 2 } I'm not a fan of lining up at later points in the line since it involves a lot of hand-indenting. |
Ok, then it's a tie.:) |
Note that I don't particulary like our current settings, which do: a = [1, 3, 5].map { |i| i + 1 }.
map { |i| i + 2 } |
I really dislike the dots at the end – my brain recognises them much more when they’re at the beginning and it’s so much more obvious that |
This issue is about the indenting @chastell, we can discuss the dots some other time 😄. |
Ah, good point, I got side-tracked by the example. :) Unfortunately, I dislike both a = [1, 3, 5].map { |i| i + 1 }.
map { |i| i + 2 } and a = [1, 3, 5].map { |i| i + 1 }.
map { |i| i + 2 } I’d either indent as deep as necessary to sync the identifiers (sorry!), or – which I would actually do in 99% of the cases – I’d introduce a temp variable so that I don’t have to wrap any lines. The number of lines would stay the same, but the brain won’t have to remember that the weirdly indented ones are continuations. |
Well, like I said, I would put the first Then, I prefer this: a = [1, 3, 5].
map { |i| i + 1 }.
map { |i| i + 2 } Over this: a = [1, 3, 5].
map { |i| i + 1 }.
map { |i| i + 2 } We can also disable this cop and allow this 😄 : a = [1, 3, 5].
map { |i| i + 1 }.
map { |i| i + 2 } My vote would be to either use |
I’m ok with either as long as we agree on the general notion to introduce wraped lines only if temp variables can’t be used in an elegant way. :) |
Ok, I'm lost. Did we agree on something now? a = [1, 3, 5].map { |i| i + 1 }
.map { |i| i + 2 } We can also go withh @mvz suggestion: a = [1, 3, 5].
map { |i| i + 1 }.
map { |i| i + 2 } @chastell now it's up to you to say [1] or [2]. Or to suggest something completely different.:) |
HEY I REALLY TRIED NOT TO PICK SIDES HERE I find [1] more readable, but I understand [2]’s practicality (no need to hand-indent and it’s Vim default), although the lack of prefix dots throws me off a bit (I KNOW, I KNOW, IT’S A DIFFERENT DISCUSSION).
I would like to push the notion that in most cases we shouldn’t have this problem to begin with and simply introduce extra variables (rather than wrap the lines). :P |
So you're voting for [1], right?.:) |
@troessner I'm confused. Does [1] include the change in dots? Also, how would you format [1] if you moved the first map on its own line? Put another way, I like [1] a lot if I had to put the first map on the first line. |
The dots would be on the same line.
No, I would have them on the same line. Haha.:) Maybe we can compromise on this a = [1, 3, 5]
.map { |i| i + 1 }
.map { |i| i + 2 } ? |
Hm, ok. That looks like a solution that RubuCop can enforce automatically. I'm not a fan of leading dots, but I can live with it. |
Ok, then how about this: a = [1, 3, 5].
map { |i| i + 1 }.
map { |i| i + 2 } cause that would work for me very well.:) |
A most interesting discussion so far with many good points. My vote goes for: a = [1, 3, 5]
.map { |i| i + 1 }
.map { |i| i + 2 } To me this is the most "symmetrical", but mostly the placement of the dots implies that the message is being sent to the value of the previous line. |
You could (and I do 😄) argue the other way around: The dot at the end of the line implies that the line is not done yet. The indenting at the start of the line implies that it is a continuation of the previous line. |
Works for me 👍. |
Two points: |
@PeterCamilleri we use RuboCop to enforce consistent dot placement. Reek itself does not check style issues. In our current RuboCop configuration, the trailing dot is enforced. RuboCop allows both styles. Apart from that, I like to keep my lines short enough so I can scan both beginning and end. Otherwise, it is too easy to miss trailing dots, other continuation characters (operators etc.), and funny logic. |
My bad... Since this a discussion about reek, I was confused and thought this might be about something going into reek. |
@mvz then let's configure rubocop accordingly. Whoever has time to look into this first .:) |
Done. Only makes a difference in about 3 places. WDYT, better or worse? |
Better! Closing this issue..;) |
See rubocop/rubocop#1591
I find the default rubocop strategy for this highly annoying and badly readable and would suggest that we go with something like:
WDYT?
The text was updated successfully, but these errors were encountered: