21–30 of 73 posts
I'm not a Ruby programmer, but a couple of these things just look completely wrong: # good def some_method(some_arr) some_arr.size end Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional? #good do_something if something_else This, to me, is horrible. If you're just scanning down the…
Agree nearly 100%, except I see no problem with omitting parentheses around arguments in method definitions. I've never had any trouble parsing this and it's a bit cleaner to my eye.
I can't stress enough how important it is to _not_ use `and` and `or`. As a former die-hard fan of those operators, it bit me in the ass so hard when those didn't exactly work the way they were supposed to. I've been using && and || now for years and I haven't looked back. /PSA
To anyone who's wondering, it seems like 'and' and 'or' are the same as && and ||, but with lower precedence [0]. Does anyone have a good reason why they both exist? It's a pretty big gotcha. [0] http://stackoverflow.com/questions/1426826/difference-betwee...
if first_user = User.find(4) && second_user = User.find(6) ... end
I'm a little curious why %w(strings go here) is preferred to [strings, go, here] The first form requires extra work to escape spaces, the second form is a representation of an array everywhere in Ruby, including in the debugger and IRB.
> The first form requires extra work to escape spaces The first form is generally used for symbol-type strings (word lists, essentially, hence "w"). It is less syntactically noisy, shorter and requires less waffling around with non-word keys. That's especially flagrant if you don't ignore half the actual array, %w(foo bar baz) really results in ["foo", "bar", "baz"] (the quotes are rather important, because they're n…
I can't stress enough how important it is to _not_ use `and` and `or`. As a former die-hard fan of those operators, it bit me in the ass so hard when those didn't exactly work the way they were supposed to. I've been using && and || now for years and I haven't looked back. /PSA
I agree with almost everything except for using named groups over the $1-$9 variables in regular expression matching. This may be the case if there are many capture groups in the expression, but I would argue that /(? regexp)/ =~ string is a fair deal more difficult to read than simply /(regexp)/ =~ string Almost everybody familiar with PCRE will be familiar with the simpler form, and it's usually the case that the s…
if /(?regexp)/ =~ string
puts meaningful_var
end
if /(regexp)/ =~ string
puts $1
end
meaningful_var = $1
Earlier quoted context omitted.
To anyone who's wondering, it seems like 'and' and 'or' are the same as && and ||, but with lower precedence [0]. Does anyone have a good reason why they both exist? It's a pretty big gotcha. [0] http://stackoverflow.com/questions/1426826/difference-betwee...
&&/|| can bite you just as well: if first_user = User.find(4) && second_user = User.find(6) ... end
Agree nearly 100%, except I see no problem with omitting parentheses around arguments in method definitions. I've never had any trouble parsing this and it's a bit cleaner to my eye.
In team environments you typically sacrifice convenience for maintainability and while you may not have a problem with optional parenthesis, it invites ambiguity and a more junior programmer may make a mistake because of it so the idea is to close off that edge case completely and not have to worry about it. This is the same reason a lot of shops ban the terniary operator for anything more than the simplest of variab…
def reply_to_post text
end
What could anyone imagine text to be in this context aside from an argument? I get that using parentheses is more familiar coming from languages with C syntax, but I see no other rationale. I've never worked with anyone who stumbled over this. It's always just: 'oh cool, I didn't realize you could omit parentheses there.'
Earlier quoted context omitted.
&&/|| can bite you just as well: if first_user = User.find(4) && second_user = User.find(6) ... end
I may be missing something obvious here. How would this code bite you?
It looks like it would evaluate as: first_user = (User.find(4) and second_user = User.find(6))
That is to say, the assignment comes after the boolean operation, which is unexpected.
Earlier quoted context omitted.
I may be missing something obvious here. How would this code bite you?
> first_user = User.find(4) && second_user = User.find(6) It looks like it would evaluate as: first_user = (User.find(4) and second_user = User.find(6)) That is to say, the assignment comes after the boolean operation, which is unexpected.
first_user = User.find(4) && second_user = User.find(6)
second_user = User.find(6)
first_user = User.find(4) && second_user
Edit: I see. if you do something like
if (first_user = User.find(4) && second_user = User.find(6)) {
..
}
first_user = User.find(4)
second_user = User.find(6)
if (first_user && second_user) {
..
}