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 file, you can easily miss the if statement, and assume the do_something always goes off.
Also, it's incredibly hard to process when I'm mentally executing the code in my head. Generally if there's a method call on the left, you just do it... but now we hit this if statement, ok, so mentally undo the method call we just processed, now check the if statement... now skip back to the do_something and reapply the method call... and now skip the if statement and continue on in the code.
...or you could just do
if something_else then do_something
(if you really must have single line if statements, which I am also against, but not so much as the if statement after the method it's controlling access to)
and (without any form of negative judgement), this is why
> a couple of these things just look completely wrong
to you, because they're idiomatic of Ruby.
First, lack of return.
A random example in Rails's ActiveSupport[0]:
def to_s
"(GMT#{formatted_offset}) #{name}"
end
It just reads like ":to_s is defined as being a String constructed this way". Note that formatted_offset and name are resolved as methods in the context (i.e self), and self. is simply omitted, which is also idiomatic.
Not only functions always return something (their last statement's return value), every statement actually returns something, so
foo = if a == b then 1 else 2
works and is used, but also with case/when, and whatever you can think of. With proper indentation this is perfectly sane and readable, and avoid redundant, 'side effect' (from the point of view of code flow) assignments, easing comprehension and refactoring, while making mistakes less likely (foo will always and obviously be assigned something).
What's more, a Ruby construct known as blocks are used with methods (such as Enumerable#map or Enumerable#select) needing return values, and omitting return is a readability and typing boon.
That's not to say return has no use, but then when you use it, you mean it, so that it is used in match/exit pattern methods, where you're doing some checks, and dispatch-return according to various situations, i.e you return early.
It is also used in Procs, which differ from lambdas in that a return will return from the caller, not the Proc.
Second, right-side if.
This aids readability when you're concerned about doing a number of sequential tasks, and some of them are conditioned. All possible tasks are aligned, and all conditions are on the right side. An absence of condition means "always". Sounds almost like column-based source code (fortran, RPG on AS400...).
You mention scanning down the file, but idiomatic ruby would not make you scan down the file: you would be faced with a function, whose size would make its structure/pattern apparent, and with such a pattern the logic would be readily seen, dangling on the right side.
Such conditions are often used with the first part of this discussion, so that you see immediately what is returned right there on the left, possibly conditioned.
> Omitting the return statement is a good thing? How do you know if this method even returns anything?
All methods return something.
> If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.
This is actually one of the arguable points in that styleguide. Some people share your disapproval for inline if modifiers. Anyway it's not that bad after getting used to as long as lines aren't too long and predicates aren't too complex.
> Omitting the return statement is a good thing? How do you know if this method even returns anything?
In Ruby, all methods return the value of the last expression executed in the method.
> .size could be a method that doesn't return anything, right, since parens are optional?
This is in theory true but never happens in practice.
Edit: Ruby has no "non-method" properties on objects. Everything is a method call, regardless of use of parens.
> If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.
An experienced Rubyist would catch it, if not at first glance, with the second. This is used relatively sparingly, and in scenarios conceptually similar to an early bailout return statement. It makes sense where it makes sense, if you will.
Neither of these is a problem in practice. It may be an issue of familiarity and comfort with the language, but in my experience it doesn't take long to be comfortable with either of those conventions.
> .size could be a method that doesn't return anything, right, since parens are optional?
It can only be a method. Instance attributes can not be public in ruby (and are delineated by the `@` prefix sigil), the closest equivalent (attr_reader/attr_writer/attr_accessor) is a dynamically generated method (or pair of methods)
There may be such a thing as a "nice DSL" but the absurd proliferation of poorly-thought-out DSLs that results from ruby's syntax is really not a positive thing.
Ha ha, my cute gem makes it look like you're making static declarations in a domain-specific language, but what you're really creating is a bunch of code that executes at unpredictable times and in an order that's impossible to untangle! Good luck! On the upside, you can create a trivial example of [something] in four lines of code!
Understandable concern, but nobody can force you to use the said gem, can they? Such fluff shouldn't be a big deal as long as it is not ingrained in most developers' minds.
Besides, it looks like ruby community is currently gravitating towards more javaesque style of programming, heavy on patterns like dependency injection, very explicit, with lots of classes and almost none metaprogramming.
Comments
I'm not a Ruby programmer, but a couple of these things just look completely wrong:
# good
def some_method(some_arr)
endOmitting 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 file, you can easily miss the if statement, and assume the do_something always goes off.
Also, it's incredibly hard to process when I'm mentally executing the code in my head. Generally if there's a method call on the left, you just do it... but now we hit this if statement, ok, so mentally undo the method call we just processed, now check the if statement... now skip back to the do_something and reapply the method call... and now skip the if statement and continue on in the code.
...or you could just do if something_else then do_something (if you really must have single line if statements, which I am also against, but not so much as the if statement after the method it's controlling access to)
> I'm not a Ruby programmer
and (without any form of negative judgement), this is why
> a couple of these things just look completely wrong
to you, because they're idiomatic of Ruby.
First, lack of return.
A random example in Rails's ActiveSupport[0]:
It just reads like ":to_s is defined as being a String constructed this way". Note that formatted_offset and name are resolved as methods in the context (i.e self), and self. is simply omitted, which is also idiomatic.Not only functions always return something (their last statement's return value), every statement actually returns something, so
works and is used, but also with case/when, and whatever you can think of. With proper indentation this is perfectly sane and readable, and avoid redundant, 'side effect' (from the point of view of code flow) assignments, easing comprehension and refactoring, while making mistakes less likely (foo will always and obviously be assigned something).What's more, a Ruby construct known as blocks are used with methods (such as Enumerable#map or Enumerable#select) needing return values, and omitting return is a readability and typing boon.
That's not to say return has no use, but then when you use it, you mean it, so that it is used in match/exit pattern methods, where you're doing some checks, and dispatch-return according to various situations, i.e you return early.
It is also used in Procs, which differ from lambdas in that a return will return from the caller, not the Proc.
Second, right-side if.
This aids readability when you're concerned about doing a number of sequential tasks, and some of them are conditioned. All possible tasks are aligned, and all conditions are on the right side. An absence of condition means "always". Sounds almost like column-based source code (fortran, RPG on AS400...).
You mention scanning down the file, but idiomatic ruby would not make you scan down the file: you would be faced with a function, whose size would make its structure/pattern apparent, and with such a pattern the logic would be readily seen, dangling on the right side.
Such conditions are often used with the first part of this discussion, so that you see immediately what is returned right there on the left, possibly conditioned.
[0]: https://github.com/rails/rails/blob/5fe88b11f11bb3b30bc23c57...
> Omitting the return statement is a good thing? How do you know if this method even returns anything?
All methods return something.
> If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.
This is actually one of the arguable points in that styleguide. Some people share your disapproval for inline if modifiers. Anyway it's not that bad after getting used to as long as lines aren't too long and predicates aren't too complex.
> All methods return something.
Ahh, that helps, thanks.
> Omitting the return statement is a good thing? How do you know if this method even returns anything?
In Ruby, all methods return the value of the last expression executed in the method.
> .size could be a method that doesn't return anything, right, since parens are optional?
This is in theory true but never happens in practice.
Edit: Ruby has no "non-method" properties on objects. Everything is a method call, regardless of use of parens.
> If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.
An experienced Rubyist would catch it, if not at first glance, with the second. This is used relatively sparingly, and in scenarios conceptually similar to an early bailout return statement. It makes sense where it makes sense, if you will.
Neither of these is a problem in practice. It may be an issue of familiarity and comfort with the language, but in my experience it doesn't take long to be comfortable with either of those conventions.
> .size could be a method that doesn't return anything, right, since parens are optional?
It can only be a method. Instance attributes can not be public in ruby (and are delineated by the `@` prefix sigil), the closest equivalent (attr_reader/attr_writer/attr_accessor) is a dynamically generated method (or pair of methods)
Returning the last expression is quite handy for a lot of functional patterns. One gets used to it very quickly, especially one has used lisp at all.
Parens being optional is indeed a flaw in Ruby's design.
Post-if can be handy, sometimes.
> Parens being optional is indeed a flaw in Ruby's design.
This flaw allows us to have nice DSLs unencumbered with parens.
There may be such a thing as a "nice DSL" but the absurd proliferation of poorly-thought-out DSLs that results from ruby's syntax is really not a positive thing.
Ha ha, my cute gem makes it look like you're making static declarations in a domain-specific language, but what you're really creating is a bunch of code that executes at unpredictable times and in an order that's impossible to untangle! Good luck! On the upside, you can create a trivial example of [something] in four lines of code!
Understandable concern, but nobody can force you to use the said gem, can they? Such fluff shouldn't be a big deal as long as it is not ingrained in most developers' minds.
Besides, it looks like ruby community is currently gravitating towards more javaesque style of programming, heavy on patterns like dependency injection, very explicit, with lots of classes and almost none metaprogramming.