DEV Community: Raquel

Using `Hash#fetch` in Ruby for better nil handling

Raquel — Thu, 21 Mar 2019 02:01:54 +0000

Using `Hash#fetch` in Ruby for better nil handling

Pulling values out of a Hash in Ruby is simple with the [] method, but problems can occur when the value you’re looking up isn’t there. This can result in cumbersome nil checks, or our absolute favourite error Undefined method for nil:NilClass.

Let’s look at an example of a classifieds site that sorts its listings when displaying them for the user, and some of the ways we can use Hash#fetch to proactively handle those nils before they happen.

Just a quick note on the code—these examples are moderately contrived and not necessarily how you’d solve these problems in production, but hey, at least they illustrate my points!

Using Hash#fetch to set a default

def index
  valid_sort_orders = {
    lowest_price: :asc,
    highest_price: :desc
  }

  sort_order = valid_sort_orders[listings_params[:sort]]

  @listings = Listing.order(price: sort_order)
end

We have a problem here—what if the sort parameter is not provided by the user, or they provide something that’s invalid? There’s many ways to handle this problem, for example, we could set a default with the || operator. This is a pretty common pattern, and a perfectly fine way to handle this case.

def index
  valid_sort_orders = {
    lowest_price: :asc,
    highest_price: :desc
  }

  sort_order = valid_sort_orders[listings_params[:sort]] || :asc

  @listings = Listing.order(price: sort_order)
end

Personally, I prefer to use the Hash#fetch method for a slightly more elegant solution. With Hash#fetch, if a key is not found in a hash, we can provide a default key to look for, which is quite a nice way to handle our nil situation.

def index
  valid_sort_orders = {
    lowest_price: :asc,
    highest_price: :desc
  }

  sort_order = valid_sort_orders.fetch(listings_params[:sort], :asc)

  @listings = Listing.order(price: sort_order)
end

Semantics alone aren’t a great reason to use this pattern though, so lets look at some more interesting examples where Hash#fetch can be used to proactively handle nils.

Using `Hash#fetch` to set a falsey value

This pattern is useful when you want to accept falsey values from a caller, but default to a truthy value. Let’s look at an example.

Here we want to be able to control with parameters whether to include a seller’s details in the response, with a default value of true. It’s easy to accidentally do something like this:

def index
  @include_seller_details = listings_params[:include_metadata] || true

  valid_sort_orders = {
    lowest_price: :asc,
    highest_price: :desc
  }

  sort_order = valid_sort_orders.fetch(listings_params[:sort], :asc)

  @listings = Listing.order(price: sort_order)
end

Which is not going to work correctly! Because if listing_params[:include_metadata] is a falsey value, this will evaluate to true anyway. It’s probably not disasterous, but it means that we’re going to be sending more information in the response than we want to, which is impolite at best and could be a security concern at worst.

One way to fix this would be to use Hash#fetch

def index
  @include_seller_details = listing_params.fetch(:include_metadata, true)

  valid_sort_orders = {
    lowest_price: :asc,
    highest_price: :desc
  }

  sort_order = valid_sort_orders.fetch(listings_params[:sort], :asc)

  @listings = Listing.order(price: sort_order)
end

In this example, if there is any value at :include_metadata, including a falsey value, it will be set, which is exactly what we want.

Run a block of code if you don’t find what you’re looking for

In the case where you don’t find what you’re looking for in a hash, returning a default value is nice, as we’ve seen. Sometimes, though, a simple value won’t do, and you might want to run a block of code as a fallback instead. Hash#fetch accepts a block to help you achieve this, which is pretty nifty!

In this example, if a user sends an invalid sort order to the API, we will record that in an analytics service. That will help us decide if we want to build that feature for our users next. If a lot of users are requesting to order Listings by popular or new, it’s handy for us to know that. So, we’ll report the value, then return the default.

def index
  @include_seller_details = listing_params.fetch(:include_metadata, true)

  valid_sort_orders = {
    lowest_price: :asc,
    highest_price: :desc
  }

  sort_order = valid_sort_orders.fetch(listings_params[:sort]) do |value|
    Analytics.report("user requested to sort listings by #{value}")
    :asc
  end

  @listings = Listing.order(price: sort_order)
end

Safer handling of environment variables with `Hash#fetch`

Poor handling of environment variables can make for some pretty disasterous outcomes (…ask me how I know). After being bitten more than once, I like to use Hash#fetch when retrieving environment variables.

This is especially important if you are using environment variables to feature flag releases, or if adding/removing environment variables is something that is handled separately to your normal code deploy process.

code expecting an environment variable + a silent failure if it’s not there + failing to correctly set an environment variable = potentially very costly mistake

🙃

def index
  seasonal_discount = ENV["SEASONAL_DISCOUNT"]

  valid_sort_orders = {
    lowest_price: :asc,
    highest_price: :desc
  }

  sort_order = valid_sort_orders.fetch(listings_params[:sort], :asc)

  @listings = Listing.order(price: sort_order)

  if seasonal_discount
    @listings = @listings.map(&:apply_seasonal_discount)
  end
end

In this case, if someone fails to set the SEASONAL_DISCOUNT environment variable, we might fail to notice because nothing here is going to throw an error. Our customers will miss out on a good deal!

We can use Hash#fetch so that this fails noisily when no env var is found.

def index
  seasonal_discount = ENV.fetch("SEASONAL_DISCOUNT")

  valid_sort_orders = {
    lowest_price: :asc,
    highest_price: :desc
  }

  sort_order = valid_sort_orders.fetch(listings_params[:sort], :asc)

  @listings = Listing.order(price: sort_order)

  if seasonal_discount
    @listings = @listings.map(&:apply_seasonal_discount)
  end
end

If no environment variable is found, this will fail noisily and your code probably won’t even deploy correctly. You could also choose to set a default if it makes more sense to do so, but there are often cases when a noisy failure is preferable.

Those are some of my favourite uses for `Hash#fetch`. It's a really useful tool for any Rubyist, and I think it’s good to remember that `[]` is not the only way to retrieve values from a Hash.

How To Review Code You Don't Understand

Raquel — Wed, 20 Jun 2018 16:02:20 +0000

I recently read an article by Max Bittker called “How to Review Code You Don’t Understand”, and it got me to thinking about times when I’ve been tasked with doing just that.

One of the troubles I have with code review is understanding the context around a change. Given a diff, I can work through it line-by-line and understand most of what’s going on there, probably. At least, I can understand the mechanics of it. But is that the same as understanding what the code is trying to achieve? In my opinion, no.

Since becoming a developer, one of the struggles I’ve had with reading code is that whatever I’m looking at, I’m seeing the solution, not the problem. And in fact, I’m only seeing one particular solution, the one I’m tasked with reviewing.

When reviewing code, I want to give thoughtful suggestions, learn something new, and pick up bugs that I am able to see. (In Ruby, 90% of the time I’m asking (“Hey, do you want to do a nil check here?”).

So, how can I do that when I am only seeing the output of (usually) one developer’s understanding, problem-solving process, and personal style? It’s hard — arguably one of the harder parts of my job. Lacking copious code comments, or some sort narration available to me while I read the code (imagine that — like director’s commentary for code), all of that important context gets lost.

Assuming that we’re not going to overhaul our team’s processes entirely, or build better code-reviewing tools from the ground up, what are some things we could go ahead and do tomorrow at work to improve our code review experience?

Ask the submitter to review the code

If your colleague hasn’t already self-reviewed their diff and left in-line comments, ask them to do so. This will provide some valuable insight — why they made a particular choice, what they struggled with, why something might seem overly complex. They might point out particular areas they’d like reviewers to focus on, or point to areas where they might be unsure about their decision-making. This will go a small part of the way towards capturing the developer’s thought process as they wrote the code.

Seek to understand what the developer was trying to achieve

If your workplace is like mine, you might start a code review with a pull request, a user story, some mock-ups, and a general idea of the larger context surrounding the piece of work.

We don’t live in a perfect world, though. Perhaps the user story will be vague (I’m yet to find a team that writes impeccable stories). Maybe there’s no mock-ups, and maybe you’re not too familiar around the context.

So before proceeding, seek to understand.

The gotcha here getting to the point where you have the right amount of understanding. Sometimes, a story or PR’s description might be too broad.

For example, you might know that the overarching goal is Display a user’s address on their invoice PDF. Great, that’s what this code is going to do, right?

What you might not know, is that a user’s address is owned by another service, and the app that you’re looking at has to request that information. So, the developer has had to think about distributed transactions, data integrity, and gracefully handling HTTP request failures. Perhaps they’ve thought about where this code should sit, and chosen one option of several.

You need to ask some questions to get enough context.

What sort of approach did you take? is a good question to ask your colleague. Did you explore any other approaches and decide against them? is another good one.

Follow-on questions might explore the trade-offs that they made. If you’re newer to being a developer, that might sound intimidating, but it doesn’t have to be. Why? is good follow-up question. It might even be a good idea to do a 5 Whys exercise.

Whatever you do, get into the habit of asking questions before reviewing the pull request.

Go through the code on your own*

Armed with the submitter’s self-review, and your understanding of the approach they took, read through the code, and leave in-line comments. They could be questions, or notes to yourself, or feedback for the submitter.

I particularly like Github’s feature where you’re able to ‘stage’ all of your review notes and then submit them all at once. This leaves me free to write notes to myself, delete any questions that are answered further down the diff (RAFO!), and edit my notes without flooding the submitter with a deluge of emails.

Go through the code with them, if possible

In person, ideally. Get answers to your questions and discuss any changes to the work.

This is also an opportunity to talk about alternate approaches, which actually leads me back to my previous conundrum with code reviews.

When you’re reading code that’s been submitted for review, you’re seeing one solution to the problem at hand. One solution. When you’re looking at the solution, it’s hard to consider other possible solutions.

I’ve found that it’s easier with more experience, but for newer developers, or for developers reviewing code that’s very different from their usual wheelhouse, it can be very tricky to think outside what has already been presented to you. It’s like the Einstellung Effect.

If you’re reviewing a pull request, and you’re finding it hard to consider other approaches, talk to the submitter. Ask them: Did you consider other ways to do this? What were they?

If it turns out they hadn’t considered any other ways to approach the problem, and you haven’t thought of any either, that’s okay. It’s good to get into the habit of asking those questions anyway.

Follow up on any discussed changes, then give it the tick!

Hopefully by taking this approach, you’ve both learned something. Perhaps you’ve gained more understanding of your domain, and the code-base. You and the submitter might have talked about different approaches to solving the problem, or at least spent two minutes trying to think of a different approach. Ka pai 😄.

This isn’t the approach that I would take with every pull request. Some, blessedly, are more straightforward than others! But if you find yourself tasked with reviewing something that’s quite chunky, consider taking some of these ideas and giving them a try.

*If it’s a large changeset, ask the submitter if they can break it down for you any more — not necessarily into separate PRs (though that might be desirable if it’s doable), but perhaps they could take you through a slice of the work, in whatever way makes sense. What we really need is a better tool for reasoning about code diffs, but that’s a blog post for another day.

DEV Community: Raquel

Using `Hash#fetch` in Ruby for better nil handling

Using Hash#fetch in Ruby for better nil handling

Using Hash#fetch to set a default

Using Hash#fetch to set a falsey value

Run a block of code if you don’t find what you’re looking for

Safer handling of environment variables with Hash#fetch

Those are some of my favourite uses for Hash#fetch. It's a really useful tool for any Rubyist, and I think it’s good to remember that [] is not the only way to retrieve values from a Hash.

How To Review Code You Don't Understand

Ask the submitter to review the code

Seek to understand what the developer was trying to achieve

Go through the code on your own*

Go through the code with them, if possible

Follow up on any discussed changes, then give it the tick!

Using `Hash#fetch` in Ruby for better nil handling

Using `Hash#fetch` to set a falsey value

Safer handling of environment variables with `Hash#fetch`

Those are some of my favourite uses for `Hash#fetch`. It's a really useful tool for any Rubyist, and I think it’s good to remember that `[]` is not the only way to retrieve values from a Hash.