Ruby adds experimental support for rightward assignments
blog.saeloun.com
Ruby adds experimental support for rightward assignments
1–10 of 172 posts
Re: Ruby adds experimental support for rightward assignments
#2[question]: Is the main benefit of "Rightward assignments" readability and does this provide more benefits?
Re: Ruby adds experimental support for rightward assignments
#3This hurts readability of code with lengthy expressions. Knowing the target of the assignment is usually more important than the particulars of the expression when you're skimming unfamiliar code. Having the variable pushed out to random locations on a ragged right side isn't helpful.
Re: Ruby adds experimental support for rightward assignments
#4Rightward assignment is pretty strongly discouraged in the R community, due to the effect it has of burying the lede. That said, I always felt the same about Ruby’s inline if/unless (`puts "still working" unless done`) so maybe it will have a better reception in this community.
Re: Ruby adds experimental support for rightward assignments
#5[question]: Is the main benefit of "Rightward assignments" readability and does this provide more benefits?
Ruby currently supports "Rightward conditionals":
user.delete() if deleteUser
Re: Ruby adds experimental support for rightward assignments
#6This hurts readability of code with lengthy expressions. Knowing the target of the assignment is usually more important than the particulars of the expression when you're skimming unfamiliar code. Having the variable pushed out to random locations on a ragged right side isn't helpful.
One of Ruby's philosophies is to provide multiple ways to express the same fundamental operation so that it can conform to your thoughts instead of forcing your thoughts to conform to it. You can still do it the old way where it makes sense. Whether this philosophy is helpful or harmful is another debate.
Re: Ruby adds experimental support for rightward assignments
#7> While the above pattern has become standardized, it feels somewhat unnatural as we read most of the spoken languages from left to right.
Is this true (the 'unnatural' part)? Reading left to right, `age = 42` can be read as "age is 42" which feels perfectly natural in English. `42 => age` would be read as "assign 42 to age"? This feels more awkward to me. I'm not sure I understand why anyone would want Rightward assignment.
Re: Ruby adds experimental support for rightward assignments
#8This hurts readability of code with lengthy expressions. Knowing the target of the assignment is usually more important than the particulars of the expression when you're skimming unfamiliar code. Having the variable pushed out to random locations on a ragged right side isn't helpful.
Is this like 'unless'?
Unless is great if it's the first or second clause on the line. If it's the tenth, then it feels more like slapstick and I am the butt of the joke. Haha, just kidding, we aren't really going to call that function.
Similarly, rightward:
someBigFunction(thatNeedsAnswersFrom(), otherFunctions(), true) => variableIAmDebugging
- Nobody reads your unit tests in a PR
- People glaze over at the end of long lines of code
- Merges are hard
#2 and #3 combine to cause over half of the bad merges I have had to diagnose. Don't save the important bits for the end of a line. If I were still writing Ruby code, I'd be prepping to see more of them.
Re: Ruby adds experimental support for rightward assignments
#9Is this really just syntactic sugar? None of the examples in the article seemed to show why code would be more readable (array assignment maybe, but the leftward seems just as readable).
Re: Ruby adds experimental support for rightward assignments
#10[question]: Is the main benefit of "Rightward assignments" readability and does this provide more benefits?
I am also struggling to think of a situation where I would want to reach for this feature. The only examples I can muster are just minor improvements to readability, like you pointed out. I would love to see a solid example where this is a must have feature.