Perhaps my personal favorite recommendation for learning to program Ruby like a Rubyist, Eloquent Ruby is a book I recommend frequently to this day. That said, it was released in 2011 and things have changed a bit since then.
This series will focus on reading over Eloquent Ruby, noting things that may have changed or been updated since 2011 (around Ruby 1.9.2) to today (2021 — Ruby 3.0.x).
Note: This is an updated version of a previous unfinished Medium series of mine you can find here.
Chapter 2. Chose the Right Control Structure
This chapter covers the use of control structures in Ruby like if
, unless
, and other branch type methods.
If, Unless, While, and Until
if
statements look pretty well the same as you’d expect, except for the lack of parens:
class Document
attr_accessor :writeable
attr_reader :title. :author, :content
# Much of the class omitted...
def title=(new_title)
if @writeable
@title = new_title
end
end
# Similar author= and content= methods omitted...
end
Now the interesting part in Ruby is if we inverted that logic to say something quite the opposite, as the book mentions:
def title=(new_title)
if !@read_ony
@title = new_title
end
end
(Note that I’d switched *not*
with *!*
as english operators aren’t often used. Granted I abuse this, but again, grain of salt)
The book mentions inverse operators, essentially saying:
if ! == unless
while ! == until
They’re just more concise ways to say the opposite.
It should be noted that in the case of unless
, it’s typically considered bad form to use an else
branch in the Ruby Style Guide:
unless condition
# ...
else
# ...
end
This is done to assert the positive part of the condition first and foremost, as else
is essentially the inverse of an unless
condition.
Use the modifier forms where appropriate
If you’re wondering why I didn’t mention the post conditional form earlier, it’s because the book brings it up in this section.
Essentially the post conditional, or modifier form is taking this:
unless @read_only
@title = new_title
end
and writing it with the condition as a suffix:
@title = new_title unless @read_only
This can be done with while
and until
as well
document.print_next_page until document.printed?
These are very widely used, but be careful when lines start getting long and blocks get involved:
data.each do |datum|
# ...
end if condition
...because that becomes less readable and more a battle of remembering to check the end of the block for surprises.
This is one of the few cases where I’d argue against 80+ characters on a line: If you cannot see the intent of a line at a glance while reading down the page it’s too long. Doubly so for modifiers at the end of them.
Use each, not for
Ruby does have a for loop, but it’s also slower and implemented in terms of each:
for font in fonts
puts font
end
each
is preferred, especially once you get into Enumerable methods which build off of it:
fonts.each do |font|
puts font
end
There are additional advantages to using block style methods, primarily around block functions themselves and symbol’s fun little to_proc
coercion:
fonts.each(&:register)
# ...is the same as:
fonts.each { |font| font.register }
If you end up into composition and other things, the fact that all these methods take blocks becomes an insane advantage for more advanced Ruby.
Put bluntly there are no advantages to using a for
loop in Ruby except that it feels more like another language.
A case of programming logic
The case statement is one of my personal favorites:
case title
when 'War And Peace'
puts 'Tolstoy'
when 'Romeo And Juliet'
puts 'Shakespeare'
else
puts "Don't know"
end
As it’s an expression, much like if, we can use it to assign a variable:
author =
case title
when 'War And Peace'
'Tolstoy'
when 'Romeo And Juliet'
'Shakespeare'
else
"Don't know"
end
A Note on Indentation
You might notice my style of indentation is different here. The original looks like this:
author = case title
when 'War And Peace'
'Tolstoy'
when 'Romeo And Juliet'
'Shakespeare'
else
"Don't know"
end
The problem with this style of indentation is that it will be subject to the variable name. What if I changed it to author_name
? Now I have to indent every other branch in the statement to match it:
author_name = case title
when 'War And Peace'
'Tolstoy'
when 'Romeo And Juliet'
'Shakespeare'
else
"Don't know"
end
Instead, I would advocate for using a line-break and two space indentation as mentioned above:
author =
case title
when 'War And Peace'
'Tolstoy'
when 'Romeo And Juliet'
'Shakespeare'
else
"Don't know"
end
Now I could call the variable whatever, and I don’t have any additional work. It also shortens the length of the expression line, making it easier to read at a glance.
The biggest reason? Code diffs will be much easier to parse through and reconcile later.
Triple Equals
Case statements use ===
behind the scenes, and that’s precisely why I like them so much. If you haven't yet I would encourage reading an article on ===
.
It’ll be mentioned more in chapter 12, but if you want to explore a bit it’s quite a ride.
Also remember that case statements can use commas to separate multiple conditions like an OR
of sorts:
type_name =
case 1
when Integer, Float
"Number!"
when String
"String!"
else
"Dunno, too lazy"
end
Really it gets a bit close to pattern matching after a fashion. I'll mention that a bit more in a moment.
The chapter mentions the use of Regex as well to match against titles. That’s because regex use ===
too. I’m telling you, it’s Ruby’s best magic, especially once you figure out you can implement your own.
Pattern Matching
Where this gets very powerful is from Ruby 2.7 onwards, which introduced an additional pattern matching syntax to case
statements:
Point = Struct.new(:x, :y)
case Point[1, 2]
in Point[0.., 0..] then :positive
in Point[..0, ..0] then :negative
else :unsure
end
# => :positive
big_point = Point[10, 10]
case big_point
in Point[x: 10.. => x, y: 10.. => y] then Point[x + 1, y + 1]
else big_point
end
# > #<struct Point x=11, y=11>
I would suggest reading through the Pattern Matching Applied series I've written if you really want to dig into this.
Staying out of trouble
The chapter mentions that 0
is truthy in Ruby. That’s still the case, much to the annoyance of other language programmers. If it’s not false
or nil
it’s truthy.
puts 'Sorry Dennis Ritchie, but 0 is true!' if 0
( Dennis Ritchie created the C programming language among other things. He’ll be missed. )
Now it’s mentioned that the string "false"
isn’t false. When it was said earlier that everything is truthy except nil
and false
that includes things which “look” like them. It’s certainly given lots of extra fun to Rails programmers with stringy booleans. Well, nightmares.
puts 'Sorry but "false" is not false' if 'false'
Explicit truthy comparisons are rare in Ruby, even today:
if flag == true
# do something
end
One of the main reasons that comes up is duck typing. We only really care if something is an approximation of truthyness. That, and it involves extra typing.
defined?
is used as an example of where this can go wrong:
doc = Document.new('A Question', 'Shakespeare', 'To be...')
flag = defined?(doc)
defined?
is an odd one, it returns a string for what type the variable is, but not as in data types:
defined? a
# => nil
a = 5
# => 5
defined? a
# => "local-variable"
So to compare that explicitly to true would break the intent of what we’re probably checking for if we were to do this:
if defined?(a)
# ...
end
It’s mentioned as being in a Boolean context. Granted it’s this Rubyist's opinion that methods ending with a question mark should return a straightforward Boolean answer, but such it is.
The next issue that’s brought up is by not paying close attention to nil
:
# Broken in a subtle way...
while next_object = get_next_object
# Do something with the object
end
Remember how false
and nil
are both falsy? If you’re expecting nil
explicitly, you should say so to prevent Ruby from breaking out of that loop early:
until (next_object = get_next_object).nil?
# Do something with the object
end
Likewise this does horrid things to ||=
, but that’s mentioned in the next section so we’ll defer until then.
In the wild
The example used for a bit of a larger if
block is from Ruby’s X509 certificate validation (with some cleaning):
ret =
if @not_before && @not_before > time
[false, :expired, "not valid before '#{@not_before}"]
elsif @not_after && @not_after < time
[false, :expired, "not valid after '#{@not_after}'"]
elsif issuer_cert && !verify(issuer_cert.public_key)
[false, :issuer, "#{issuer_cert.subject} is not an issuer"]
else
[true, :ok, 'Valid certificate']
end
Now one of the fun things to change in Ruby since 2011 is the null coercion, or lonely operator (&.
), which lets us do this (assuming verify
deals well with nil
):
ret =
if @not_before&.> time
[false, :expired, "not valid before '#{@not_before}"]
elsif @not_after&.< time
[false, :expired, "not valid after '#{@not_after}'"]
elsif !verify(issuer_cert&.public_key)
[false, :issuer, "#{issuer_cert.subject} is not an issuer"]
else
[true, :ok, 'Valid certificate']
end
Note that I’m not using the instance variable interpolation syntax,
"#@var"
, as it’s exceptionally rare to see out in the wild. It's only real benefit is being a character shorter while making code a bit more confusing for newer programmers. When possible stick with common over clever.
Another example used is the classic ternary operator:
file = all ? 'specs' : 'latest_specs'
It’s still very much in use, and the reason why sometimes I tend to use parens around methods ending in question marks for clarity like defined?(a)
. Visual cues go a long way for understandability some times.
I’ve seen this done before, but at this point just use an if
statement instead:
file =
all ?
'specs' :
'latest_specs'
…and please don’t use multiple nested ternaries, that’s just right unpleasant to read.
Next up postfix expressions!
@first_name = '' unless @first_name
Though more commonly, and noted in the book, this is used:
@first_name ||= ''
which is to say essentially:
@first_name = @first_name || ''
Same rules of truthyness apply here, and remember, only false
and nil
. Is an empty string one of those? No? Then it’s still truthy, be very careful to remember this.
The book goes on to compare this to +=
from the example:
count += 1
The same idea applies. If we were to go into a bit more depth, Ruby literally uses the operators for this type of syntax sugar. If you were to define your own +
or ||
it’d override the +=
and ||=
respectively to potentially do very bad things.
Wrapping Up
Most everything you’re going to see for control structures like if
and friends has not changed much, and the warnings are still very relevant. Take heed as there’s some advice in programming which ages quite well.
Next up we get the fun of Arrays and Hashes to play with, and oh my do they have some lovely new features.
Top comments (0)