skip to content

In Ruby, in what order does a Hash return its entries, and what happens to that order when you update or re-add a key?

level: juniorimportance: should knowfreq 40%

answer

  1. order of creation
  2. updating keeps the position
  3. delete, then add, moves to the end
  4. shift takes the oldest entry
  5. == ignores order

basics

~20 s

A Ruby Hash presents entries in the order their keys were first inserted. Assigning a new value to an existing key keeps its position; deleting the key and adding it again moves it to the end.

solid answer

~40 s

Ruby documents that a `Hash` presents its entries **in the order of their creation**, and every order-sensitive method follows it: `each`, `keys`, `values`, `first`, `shift`, `to_a` and `inspect`. A literal's order is the order written. Updating an existing key with `h[k] = v` changes the value but keeps the key's position; `delete(k)` followed by `h[k] = v` puts it last. `merge` updates existing keys in place and appends new keys in the argument's order. `shift` removes and returns the oldest pair. Order does not affect equality: `{a: 1, b: 2} == {b: 2, a: 1}` is `true`. To reorder, build a new hash, for example by sorting the pairs and calling `to_h`.

code

ruby · 11 lines
ruby
counts = {"plot" => 2, "great" => 1}
counts["cast"] = 1     # new key goes last
counts["plot"] = 3     # update keeps position
counts                 # => {"plot" => 3, "great" => 1, "cast" => 1}

n = counts.delete("plot")
counts["plot"] = n     # re-added: now last
counts.keys            # => ["great", "cast", "plot"]

counts.shift           # => ["great", 1]
{a: 1, b: 2} == {b: 2, a: 1} # => true

go deeper

for a junior

Recall that hashes keep insertion order, that updates keep a key's place, and that delete then re-add moves it to the end.

for a middle

Explain which methods expose the order, how merge places keys, and why equality ignores order while to_a comparisons do not.

for a senior

Use order deliberately, such as first-seen reporting or oldest-first eviction with shift, and keep tests from depending on order they do not assert.

for a principal

Decide when relying on hash order is a clear contract and when an explicit sort or dedicated structure communicates intent better.

## Entry order is creation order A Ruby `Hash` is ordered. The core documentation states that a hash "presents its entries in the order of their creation", so the order is part of the class's contract rather than an implementation accident. Code can rely on it. - A **literal** keeps the order written: `{title: "Dune", rating: 5}` iterates `title` first. - A **new key** is appended at the end. - **Updating** an existing key keeps its place. - **Deleting** a key and adding it again puts it at the end. ## Update versus re-add | Starting hash | Operation | Result | |---|---|---| | `{b: 1, a: 2}` | `h[:c] = 3` | `{b: 1, a: 2, c: 3}` | | `{b: 1, a: 2}` | `h[:b] = 9` | `{b: 9, a: 2}` | | `{b: 1, a: 2}` | `h.delete(:b); h[:b] = 9` | `{a: 2, b: 9}` | | `{b: 1, a: 2}` | `h.merge(c: 3, b: 7)` | `{b: 7, a: 2, c: 3}` | `merge` and `update` follow the same rule: keys already present keep their position with the new value, and new keys are appended in the order the argument lists them. ## Methods that expose the order - **Iteration**: `each`, `each_pair`, `each_key`, `each_value`. - **Extraction**: `keys`, `values`, `to_a`, and `first`, which returns the oldest `[key, value]` pair. - **Removal**: `shift` removes and returns the **oldest** pair as a two-element array, or `nil` when the hash is empty. - **Display**: `inspect`, and therefore `p`, prints entries in order. ## Order and equality `Hash#==` compares entries, not positions. Two hashes are equal when they have the same keys and each key's values are `==`, **regardless of order**: ```ruby {a: 1, b: 2} == {b: 2, a: 1} # => true ``` If order matters to a test, compare `h.to_a` or `h.keys` instead. ## Order when building a hash from other data The same two rules, append new keys and keep the position of updated ones, explain every constructor: - **`to_h` on pairs** keeps the pairs' order, and a repeated key keeps its **first** position with its **last** value: `[[:a, 1], [:b, 2], [:a, 3]].to_h` is `{a: 3, b: 2}`. - **Filtering** methods such as `select` and `reject` return a new hash with the surviving entries in their original order. - **Counting** with `Hash.new(0)` while scanning review text records words in first-seen order. ## Putting order to work 1. **Preserve input order** when parsing: word counts built while reading a review list come out in first-seen order, which is often what a report wants. 2. **Move an entry to the end** to mark it as most recently used: `v = h.delete(k); h[k] = v`. 3. **Evict the oldest** entry with `shift` when a size limit is reached. 4. **Reorder** by building a new hash from sorted pairs, for example `h.sort_by { |_, n| -n }.to_h` to list the most frequent words first; sorting returns an array of pairs, and `to_h` turns it back into a hash in that order. `Hash` has no method that moves one key to a chosen position in place; reordering means rebuilding the hash or deleting and re-adding keys.

  • Does Hash#== consider the order of entries?
    No. `==` is true when both hashes have the same keys and equal values for each key, regardless of order, so `{a: 1, b: 2} == {b: 2, a: 1}` is `true`. Compare `to_a` or `keys` when a test must check order.
  • Where does merge place keys from its argument?
    Keys already in the receiver keep their positions and take the new values; keys that are new are appended at the end in the order the argument lists them. `{b: 1, a: 2}.merge(c: 3, b: 7)` returns `{b: 7, a: 2, c: 3}`.

saying these in an interview costs you the question

  • Ruby hashes are unordered, so iteration order is unpredictable
  • Updating an existing key moves it to the end
  • Two hashes with the same entries in a different order are not ==
  • Hash#keys returns the keys sorted
  • Hash#shift removes the most recently added entry