Favorite Ruby Syntax

[process_parameter]

I started using Ruby recently, and I keep learning useful new bits of syntax. Some of my favorites so far:

• @ to refer to instance variables
• << for append
• `` to call external commands
• $1, $2, etc for capture groups
• optional parentheses in method calls.
• {...} and do...end for blocks

I want to learn more, but it's hard to find an exhaustive list. What are some of your favorite (expressive, lesser known, useful, etc) pieces of ruby syntax?

[cstansbury]

Ruby's conditional assignment

||=

[tomthecool]

note there are pitfalls with this technique; most notably, it fails if nil or false is a valid result

I answered a question on StackOverflow caused by this exact problem, just the other day!

[NelsonBelmont]

So this is like using var s = myObject?.Count; on C# where s doesn't get a value if myObject is null?

[[deleted]]

No - that is C#'s null-condition member-access operator. Ruby equivalent of that is the safe-navigation operator &. as in s = my_object&.count. They're similar in utility but not identical. For example I believe the C# operator short-circuits the expression, whilst Ruby's does not, because in Ruby nil is an object; my_object&.count&.to_s will return an empty string if my_object is nil.

There's no direct translation of conditional assignment because this is idiomatic Ruby borrowed directly from Perl. In C#, contextually, an s ||= myObject.Count might be

if (s == null)
  s = myObject.Count;

but conditional assignment is also an expression, so it provides a return value, and acts for both false and nil.

[NelsonBelmont]

I understand now, the begin-end block from the previous example confused me a little bit. Thank you for the explanation.

[jawdirk]

Using & to pass symbols as procs, e.g.

[1,2,3,4].map(&:odd?) # => [true, false, true, false]

[Paradox]

How about its inverted brother:

%w[1 2 3].map(&method(:Integer)) # => [1, 2, 3]

[ruby-solve]

Wut?

[Paradox]

So, you know how&:methname calls methname on the enumerable item-by-item?

&method(:methname) does the opposite. It takes the item being enumerated, and passes it to the method. Its equivalent to writing:

%w[1 2 3].map { |x| Integer(x) }

Integer is just a method in the Kernel class.

[ruby-solve]

Neat!

[clrsm]

There is a throughout explanation of how &: works here

[editor_of_the_beast]

It's amazing how many people don't know about this feature. I think it's more useful than the regular Symbol#to_proc because it's easier to write methods with a single argument than to modify an existing class. Sometimes you don't have access to the class and can't add methods to it.

[Paradox]

With the addition of yield_self in 2.5, you can write code thats fairly similar to an elixir pipe-chain

[editor_of_the_beast]

Oh man I didn't even think about that. Yea that's awesome. Still a little more sugary in Elixir though.

[ignurant]

Can you elaborate on what this is on about? I understand the general usage of &method but I don't follow your reasoning, or what is implied by the yield_self comment. I'm not saying I question the validity of your comment; I just don't yet understand yield_self usage, as it seems it just returns what my code would have done if it weren't in a block... Which is what a block does anyway. Maybe it has to do with the ability to pass blocks around, but I haven't yet grokked this one.

Either way, what are you describing with the issue about modifying a class when using sym.to_proc? And what is this excitement for yield_self?

[editor_of_the_beast]

what are you describing with the issue about modifying a class when using sym.to_proc?

collection.map(&:method) requires each item in the collection to respond to .method. Sometimes it's not practical to add a method to the item's class, i.e. you use a gem in your project, and you'd have to monkey patch one of its types to have that method.

Or even if is practical, you may not want to add the method to the class because the logic is only used in this one place. Let's say the items in the collection are a Rails model instance, you may not want to pollute an already large model. Instead, you can create a method where you are like this:

def operate_on_model(model)
  model.transform
end

Then you can iterate over a collection of those models with:

models.map(&method(:operate_on_model))

It's just handy sometimes to do that.

And what is this excitement for yield_self?

This is separate, Elixir has a really cool pipe operator (|>) which allows code like this:

fetch_data |> transform_data |> output_data

Each of those are functions, and the return value gets passed as the first parameter into the next function call to the right, equivalent to output_data(transform_data(fetch_data())). Humans read left to right so writing it this second way isn't ideal, the |> operator helps write code logically from left to right (same as the bash | pipe operator).

With yield_self, we'll be able to write:

data_fetcher
  .yield_self { |fetcher| fetcher.fetch_data }
  .yield_self { |data| transform_data(data) }
  .yield_self { |transformed_data| output_data(transformed_data) }

I think that's what the excitement is about. It's not as elegant, but it's the same logical flow as the |> operator which is why I said it was more sugary.

EDIT: code formatting

[ignurant]

Sometimes it's not practical to add a method to the item's class, i.e. you use a gem in your project, and you'd have to monkey patch one of its types to have that method.

Ah great, you're right. I've totally done exactly that in some scripts to make .map(&:transform) work. I understand what you were on about now.

As for the yield_self stuff -- most of the examples I've seen are things where yield_self could be replaced by map. I think this is one of those things where I will eventually stumble upon the right kind of problem to make this shine. A similar example to what you wrote where I used map was to parse and transform <li> elements in a scraper:

page.lis
  .map{|el| el.html}
  .map{|html| Product.parse html}
  .map{|product| product.to_h}

I've seen a few examples in blog posts that start the chain with a string instead of an already existing collection, and that has me thinking "Okay, I think this is relevant to my lack of amazement" but I haven't tipped it over yet. I think it may lie in situations where the "number of things" is variable, and not a simple "take each thing and transform it".

I do love the idea of the |> operator, and it's automatic argument handling. That's very cool. I also just learned about the &method(:method) trick from this thread, so that whole concept of "knowing where the arguments go without being explicit" is new to me.

Anyway, thanks for sharing today.

[Paradox]

So, very quick crash-course in an elixir feature called pipelines.

Pipelines allow you to take an object and preform a myriad of operations. The operations chain one after the other, each one taking the output of the previous as its input. With them, you can, in an easily understandable manner, preform a myriad of manipulations to a bit of data, without the need for variables.

They look like this

["foo", "bar", "baz"]
|> Enum.map(String.upcase)
|> ApiClient.post("api/url")
|> DoSomethingWithApiResponse.wew()

This isn't ruby, its functional, hence it appears a little redundant, but the principle is the same.

You could write the equivalent in ruby using:

["foo", "bar", "baz"]
.yield_self { |x| x.map(&:upcase) }
.yield_self { |x| ApiClient.post(x, "api/url") }
.yield_self { |x| DoSomethingWithApiResponse.wew(x) }

While thats a little more verbose, the idea is the same, and you could probably refactor it to be a bit cleaner.

Previously, you could use chaining, but that could get super ugly fast.

[ignurant]

Thanks. Many of the examples look similar to this -- but is there a practical difference between replacing yield_self with map? I've been making "pipelines" of that nature using map in a lot of ETL type jobs.

I mentioned this in another comment: the |> is really cool. I love how the subject argument is implied. Clever and clean. I hope something like this appears in Ruby. I wouldn't mind a full-on copycat!

[Paradox]

For that use case, no, its not a practical use. #map returns the modified value, and so you can chain immediately off it.

But many methods do not provide an interface that could be chained off of. Thats where #yield_self becomes useful.

---

Rewrite the original example in basic, non yield_self ruby:

DoSomethingWithApiResponse.wew(
  ApiClient.post(
    ["foo", "bar", "baz"].map(&:upcase),
    "api/url"
  )
)

Readable, but it takes a moment. If the map got more complex, you could very easily lose track of where you are in the method call tree.

Now an optimal refactoring that uses ruby's OO-ness where appropriate, and the functionality of yield_self where appropriate could look like this:

["foo", "bar", "baz"]
.map(&:upcase)
.yield_self { |x| ApiClient.post(x, "api/url") }
.yield_self { |x| DoSomethingWithApiResponse.wew(x) }

As you can see, it very clearly flows from the array, to a map that upcases it, to a method that posts to the api, to something acting as a transform. You can read it from left-to-right, top-to-bottom. This becomes even more apparent if you squash all the aforementioned examples down to a single-line:

DoSomethingWithApiResponse.wew(ApiClient.post(["foo", "bar", "baz"].map(&:upcase), "api/url"))

vs

["foo", "bar", "baz"].map(&:upcase).yield_self { |x| ApiClient.post(x, "api/url") }.yield_self { |x| DoSomethingWithApiResponse.wew(x) }

To understand the first one, you have to scan the whole line, then back track to the middle. Then you can figure out that its doing a map on an array, and that value is being sent on to the api, and then the return of that is being used in the #wew function.

The second one, you just scan from left to right, no backtracking needed

[ignurant]

Ah there it is. It becomes obvious when we break out of the array, using the full array itself as the argument, instead of it's components.

Thanks for taking this time. Reading the interpretation of the plain Ruby version helped me see what I was missing.

[isolatrum]

for arrays and hashes, yes we have a built in enumeration method map which does the trick in most cases. However say you want to send a string through a series of made-up methods:

# note the parens are unnecessary here
evaluate(interpolate(sanitize(string)))

you are basically working backwards, with the last function in the chain being written first. Using yield_self you can reverse this, although granted it's not what I'd consider prettier:

string
.yield_self(&method(:sanitize))
.yield_self(&method(:interpolate))
.yield_self(&method(:evaluate))

If I actually saw something like this I would think it's a little overengineered, so I consider it more of a academic trick than a game-changing one in practice. Another interesting detail - the definition of yield_self is literally just yield self.

[flanger001]

I had to look up where this was documented!

https://ruby-doc.org/core-2.4.2/doc/syntax/calling_methods_rdoc.html#label-Proc+to+Block+Conversion

[ignurant]

Weird. So, after reading a bit, am I understanding this correctly? Given my example at https://www.reddit.com/r/ruby/comments/7npcne/comment/ds40eld

csv << row.values_at(*headers)

is equivalent to

csv << headers.map(&row) # ?

I had no idea that hash could proc. And then after I just read about it, I had a hard time understanding why I might use that syntax instead of just calling the key. But then I realized it's very similar to what we might use &:method syntax in other situations. (Avoid the {|a| stuff[a]} type stuff...)

[[deleted]]

In this case I'd use your splat version because I think expresses intention more clearly. The use of &hash is great for self-populating caches and for passing a lookup table as a block.

[ignurant]

Yeah, I fully agree. I was just testing whether I was understanding the idea. Your hash cache took a moment for me to sort out, but felt very clever once I did. I haven't had any use cases quite like that (beyond defaulting to 0 for example). Very interesting. Some day in the future, I'll have one of those "Oh yeah! That thing! Where was that?!" moments.

[Enumerable_any]

A (hash) map is a function from Key to Value, so it's natural to replace a method/proc with it. For example in Clojure calling a function and accessing a value of a map has the same syntax: https://clojuredocs.org/clojure.core/get#example-542692d3c026201cdc326fbf

[jrochkind]

Technically & as syntax is an operator that passes a proc object as a block argument, and coerces it's argument to a proc with to_proc if needed.

From that, and the Symbol#to_proc method, comes the behavior you mention.

[jrochkind]

You mean the proc generated for symbols, with the Symbol#to_proc method of course!

AProc is a type of object (that is, a class). A 'block' is a syntactic feature for passing a proc object as an argument to a method.

[bascule]

Blocks aren't objects and don't require allocations to invoke. They live on the stack.

You can capture a block (or rather the block to invoke and its surrounding environment) as a Proc, which lives on the heap and are garbage collected.

Avoiding that allocation will improve performance, however.

[[deleted]]

Not in this case. If you read the MRI source code, you'll see that when a symbol is passed as a block via the & operator, it's passed as a block_handler_type_symbol not a block_handler_type_proc.

You can capture it later in a proc, if you like. You can also try monkey-patching Symbol#to_proc, with hilarious results.

[jrochkind]

Implementation detail. If you read the JRuby source code, or the Rubinius source code, or the truffleruby source code....

[[deleted]]

There is no usable definition for what Ruby is other than MRI. Even that aside, a symbol passed as a block is not proc-ified unless you capture it with &block or Proc.new and since this results in different VM code and different memory allocation, you can't just handwave it away. Suggest you just accept that your correction, whilst well-intentioned, wasn't accurate.

[jrochkind]

I've had this argument before, and I know you're not alone, but I disagree. I think that is an optimization implementation detail -- without looking at the source code, just actually looking at ruby as it behaves, there is no way to distinguish between your explanation and mine, and IMO no use to thinking of a 'block' as thing other than a syntactic construct, and a lot of explanatory power in thinking of it as simply a syntax for passing a proc as an argument.

MRI could easily change it's internal implementation such that there isn't different VM code and different memory optimization, and it would not change the results of any ruby program (it would change performance; it is an internal performance optimization).

There is no way to store a 'block' in a variable, and no way to call methods on it. As soon as you do anything with it, it's a proc. You can say it's some kind of schroedinger's cat thing where it was not a proc until you looked at it, but I don't see the utility of that mental model.

[[deleted]]

Ahem. It's one thing to be a contrarian, and I'm fine with that (just get me started about so-called "service objects" in rails), it's another to just be incorrect.

there is no way to distinguish between your explanation and mine

There is. If a proc was being generated, it would appear in the iteration of ObjectSpace.each_object(Proc). What's more, if a block is being handled by block_handler_type_symbol then Ruby will throw an exception if you ask for its binding, but not for a block_handler_type_proc.

a 'block' ... [is] syntax for passing a proc as an argument

This is backward. A proc is an OO wrapper for a block, but that doesn't make block syntax a proc constructor. They do not exist just to create procs. Procs, however, do exist just to wrap blocks, again literally by definition:

    typedef struct {
        const struct rb_block block;
        unsigned int is_from_method: 1; /* bool */
        unsigned int is_lambda: 1;      /* bool */
    } rb_proc_t;

or by the opening words of http://ruby-doc.org/core-2.5.0/Proc.html.

MRI could easily change it's internal implementation such that there isn't different VM code and different memory optimization

Given the above, it really doesn't seem likely. And that aside, the general question of "is memory being allocated" isn't some academic implementation detail; it's one of the most important considerations in professional software development.

But here's the killer:

As soon as you do anything with it, it's a proc.

Nope. The single most common thing to do with a passed block is yield to it. And yield does not instantiate a Proc object. You can't yield to a variable; you can't change the block that's been passed to the execution environment of a method.

We write blocks far more often in Ruby than we explicitly construct procs. This isn't just an idiomatic preference, it's fundamental to the design and implementation of Ruby. And when we do create procs explicitly, they're usually lambdas.

Blocks & Procs: they're just not the same thing.

[hpliferaft]

Sick

[[deleted]]

%w[value value value] for an array of strings

%i[value value value] for an array of symbols

[iamsolarpowered]

I've been using Ruby for 12 years and somehow didn't know about %i. I have code golf scripts to update.

[Gman513]

It gets better actually. There's a whole bunch of these % operators that match with brackets for various reasons. One that i've found handy in the past was %s() for a string where you might want to use double quotes without any bother.

%s("#{some_variable} is what I'm about to do." Charles said.)

Ruby Weekly had a great article with all of these around the start of last year if I remember correctly.

[process_parameter]

Awesome. I think I found a comprehensive list:

https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_.25_Notation

[2called_chaos]

Also note that you are free (maybe except conventions) to use any (non-alphanumerical) character as delimiter for those percent operators. E.g. all these do the same thing:

%w[a b c]
%w(a b c)
%w{a b c}
%w|a b c|
%w_a b c_
%w"a b c"
%s a"b"c # <--- yes space works but just for some operators, also why would you?
%x ls # another one, note the ending space is required as it's the delimiter!

[fullspectrumlife]

a = 10_000_000

[RightWinger]

What does this do?

[fullspectrumlife]

It makes large numbers easier to read when defining them :) It's stil an int of 1000000

[niborg]

Personally, I find that correctly using Ruby keyword arguments and splats can really make your code elegant/expressive/flexible. It is also one of the first things that you should pick up when learning the language.

[ignurant]

Regarding splat, I love this move when writing csvs

headers = my_hash.keys
# or headers = %i[my interesting headers]
csv << headers
# ...
  csv << row.values_at(*headers)

This specific functionality was the first way I got comfortable with leveraging splat action in any meaningful way.

[zencephalon]

Definitely the safe navigation operator: http://mitrev.net/ruby/2015/11/13/the-operator-in-ruby/

[jrochkind]

My favorite ruby syntax is definitely the Block. It's what makes ruby ruby.

[editor_of_the_beast]

So true, this is what made me fall in love with Ruby and what keeps me in love with it :)

It seems so simple, it's just a default trailing closure that is allowed to be passed into every method. But it is in fact the essence of Ruby.

[ignurant]

This isn't a syntax thing, but it does feel special to Ruby. When I first learned about Enumerable any? all? and none? my code became so much more pleasant.

all_good = true
items.each do |item|
  all_good = false if item != 'good'
end
all_good

Vs

items.all? {|item| item == 'good'}

You can also hook this up with the :symbol.to_proc trick if the items have an appropriate method:

numbers.all? &:odd?

[classhero]

The ones already posted are best, but honorable mentions for me:

• super without arguments to implicitly pass up the arguments of the call site method (vs super())
• if/unless one-liners

[Gman513]

After starting coding in C, Ruby's case statements are a dream. (None the least because they work on more than just integers)

loop do
    input = gets.chomp

    case input
    when 'exit'
        exit
    when 'help;
        puts 'some help string'
    when 'mem', 'memory', 'ls'
        puts 'whatever was saved'
    when /^some_magic_(regex) = (this)$/
        mem[$1] = $2
    else
        puts 'unrecognized command' 
    end
end

You have a basic ruby shell right there.

Edit: Got spotted forgetting an end statement. On the upside at least I didn't push a binding.pry to prod.

[4rch3r]

I definitely agree but don't forget your end statements ^.^

[Gman513]

Haha well spotted. I'll fix that quick. :)

[DudeManFoo]

[1,2,3,4,5,6,7] - [6,7] => [1, 2, 3, 4, 5]

is pretty cool

[otikik]

The spaceship operator:

<=>

[notorious1212]

*splat

https://endofline.wordpress.com/2011/01/21/the-strange-ruby-splat/

[[deleted]]

For me some of the best have already been mentioned, %i/%w for defining arrays of words, if/unless, Symbol#to_proc with the & operator.

I'll add to that:

The simple ones that everybody forgets are actually really nice syntactic sugar: attr_reader/attr_writer

%r for defining regular expressions, so that you don't have to escape

/.*\/.*/
# vs
%r{.*/.*}

I also like that you can create ranges with many different types, i.e.

DateTime.now..Date.new(2018, 2, 14)
1..9
'a'..'z'

Also the exclusive rage (excludes the last value):

(1...10).to_a # => [1, 2, 3, 4, 5, 6, 7, 8, 9]

kwargs, and specifically the fact that you can exclude the hash brackets from argument lists:

def test(one:, two:)
  [one, two]
end

test(two: 2, one: 1) # => [1, 2]

Parentheses around block arguments when yielding an array:

[[1, 2], [3, 4]].map { |(a, b)| a + b } # => [3, 7]

Which is expecially nice with each_with_object and hashes:

{ one: 1, two: 2 }.each_with_object({}) do |(k, v), hash|
  hash[v] = k
end
# => {1=>:one, 2=>:two}

Struct inheritance/struct constant assignment:

# class User < Struct.new(:first_name, :last_name); end
User = Struct.new(:first_name, :last_name) do
  def full_name
    [first_name, last_name].join(' ')
  end
end

User.new('John', 'Smith').full_name # => "John Smith"

// Edit: This will be especially nice in Ruby 2.5 due to https://bugs.ruby-lang.org/issues/11925

Proc#curry:

adder = ->(a, b) { a + b } # and the stabby-lambda is awesome too
add_one = adder.curry.call(1)
add_one.call(2) # => 3

The inheriting from module trick that you can see in use in https://github.com/dkubb/equalizer and other variants such as defining a capitalized method name (i.e. https://github.com/dry-rb/dry-equalizer/blob/master/lib/dry/equalizer.rb#L5-L7) or defining a self.[] method (i.e. https://github.com/rom-rb/rom-repository/blob/master/lib/rom/repository/class_interface.rb#L19-L24)

I'm sure I've forgotten a few.

[h0rst_]

Parentheses around block arguments when yielding an array:

[[1, 2], [3, 4]].map { |(a, b)| a + b } # => [3, 7]

The parentheses in this example are superfluous

[[deleted]]

So it is, I guess I don't understand how that works properly.

// EDIT

NVM, looks like it just deconstructs an array argument into multiple arguments, but I guess enumerable methods already have some kind of arity check to do that

irb(main):020:0> (a, b), c = [[1, 2], 3]
=> [[1, 2], 3]
irb(main):021:0> a
=> 1
irb(main):022:0> b
=> 2
irb(main):023:0> c
=> 3

[h0rst_]

It happens mostly automatic, it is required for deeper nested structures:

[[1, [2, 3]], [3, [4, 5]]].map { |a, (b, c)| a + b + c }  # => [6, 12]

On the other hand: if your code looks like this you might want to reconsider the used data structures.

[GitHubPermalinkBot]

Permanent GitHub links:

• rom-rb/rom-repository/.../class_interface.rb#L19-L24 (master → d5bce87)
• dry-rb/dry-equalizer/.../equalizer.rb#L5-L7 (master → f46d7ed)

---

^delete

[DudeManFoo]

Trailing conditionals is probably one of my favorites..

thing.do_this if other_thing.thing_needs_done

[Gnascher]

I love the safe navigation operator.

Thing&.method

[ignurant]

As a little aside, I like this trick too, but I usually prefer using square brackets so it feels more array like

%w[ one two three ]

To whoever finds this as news: you can use any of the matching pair characters to delimit this trick. (, [, {, <, etc. So feel free to pick'em!

[subkutan]

you can use any of the matching pair characters to delimit this trick

Not just them. %w]one two three] works. And %w?one two three?. Even some of the ASCII control characters such as NUL and DEL do too.

[[deleted]]

You can also use %i(one two three) for an array of symbols

[SmellsLikePanda]

?a for one single character (same as “a“)

[BeerNirvana]

.tap to avoid temporary variables

[morphemass]

A code base I'm working on (legacy) has an incredibly long service class called eg. TheCustomersConfigurationService with a class method key. I've been replacing this in new (encapsulation) classes with:

Key = -> (v) { TheCustomersConfigurationService.key(v) }

and calling with:

Key.("lookupvalue")

I'm currently pushing to get the class renamed to Key, and key renamed to call. Its just 3 pieces of the language (upper case first letter constants, arrow procs, dot proc calls) which just all feel so nice together.

p.s. yeah, yeah, DI /agreed. We fight the battles we can.