# ruby/did_you_mean: Typo Suggestions in Ruby Errors

> did_you_mean adds likely matches to Ruby exception messages for misspelled methods, classes, variables, hash keys, and require paths. It is most useful to Ruby developers debugging NameError, NoMethodError, KeyError, LoadError, and pattern matching failures.

**ruby/did_you_mean** — The gem that has been saving people from typos since 2014

- Repository: https://github.com/ruby/did_you_mean
- Stars: 1,879 · Forks: 115
- Language: Ruby
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/ruby-did-you-mean

## Why did_you_mean changes Ruby's exception output

did_you_mean addresses a specific diagnostic problem: Ruby can identify an undefined method, constant, variable, hash key, or library path, but the original exception may leave the developer to infer the intended spelling. The gem adds a "Did you mean?" line to supported errors. For example, `methosd` produces a NameError that points toward `methods` and `method`, while `OBject` points toward `Object`.

The correction is added to the exception output. The README does not say that did_you_mean rewrites the failed expression, defines the missing name, or continues execution. A typo still raises an exception. This makes the project appropriate for developers who want faster diagnosis while debugging Ruby code, rather than a general-purpose input validation system.

The documented error categories include NameError for method, class, instance variable, and class variable names. The gem also augments NoMethodError, KeyError, LoadError, and NoMatchingPatternKeyError. This range follows the different lookup contexts already present in Ruby exceptions, so the candidate set can reflect the object receiver, available hash keys, constants, or loadable file names rather than one fixed project dictionary.

## Supported typo contexts and their suggestion sources

The examples show that did_you_mean derives suggestions from the context of the failed operation. A misspelled method such as `starts_with?` is associated with `start_with?` through NoMethodError. A misspelled hash key such as `:fooo` is associated with `:foo` through KeyError. Pattern matching failures use NoMatchingPatternKeyError and receive the same kind of key guidance.

Class and variable cases follow a different path. `OBject` is reported as an uninitialized constant, with `Object` offered as the likely match. A reference to `full_name` when `@full_name` exists is associated with the instance variable. A misspelled class variable receives a suggestion for `@@full_name`. These examples indicate context-sensitive handling rather than simple string replacement across every identifier.

Load errors are also treated specially. The README shows `require 'net-http'` raising LoadError and suggesting `net/http`. In that case, the candidate comes from Ruby library path names rather than method names. The project therefore covers both code symbols and file paths, but the exact algorithm and threshold behavior are not documented in the README. Users should not assume that every edit distance produces a suggestion or that the first candidate is always the intended correction.

## Automatic loading in supported Ruby installations

There is no separate installation tutorial for current users because the README states that Ruby 2.3 and later ships with this gem. A Ruby process automatically requires it at startup, so no Bundler declaration or special setup is required merely to receive the documented exception suggestions.

For a first real use, create the misspelling deliberately and inspect the exception. This example uses the repository's documented NameError case. After a Ruby process raises the error, the output should include the definition of the NameError followed by a "Did you mean?" line containing `methods` and `method`.

```ruby
methosd
# => NameError: undefined local variable or method `methosd' for main:Object
#    Did you mean?  methods
#                   method
```

The absence of an installation command does not mean did_you_mean is absent from every environment. It means the supported Ruby distribution already contains and loads it. The README does not document behavior for Ruby versions earlier than 2.3, so adopting it in an older runtime requires checking that runtime's bundled gems rather than assuming compatibility.

## Programmatic closest-match lookup with SpellChecker

Applications that need candidates before an exception occurs can reuse `DidYouMean::SpellChecker`. The documented constructor accepts a `dictionary` array, and `correct` returns matching entries. The example uses three terms and shows how a transposed method spelling maps to the intended word.

```ruby
spell_checker = DidYouMean::SpellChecker.new(dictionary: ['email', 'fail', 'eval'])

spell_checker.correct('meail') # => ['email']
spell_checker.correct('afil')  # => ['fail']
```

This is the clearest programmatic interface documented by the project. It does not accept arbitrary application objects or named identifier categories in the example. Instead, the caller supplies a dictionary of strings and receives a list of close matches. That makes SpellChecker suitable for a controlled lookup task, such as checking a user-supplied term against a known set of supported terms. The README does not state how ties are ordered, what similarity threshold is used, or how large dictionaries affect performance.

For exception-oriented use, the caller must supply the dictionary itself. The automatic Ruby examples have access to the names and paths that caused the original exception, whereas a standalone `SpellChecker` instance only knows the dictionary passed during construction.

## Disabling suggestions without changing the original exception

The gem can be disabled when debugging the error object itself or when an unmodified error message is required. For a direct Ruby invocation, the README gives `--disable-did_you_mean` as a command-line option. The example deliberately calls `1.zeor?`, and the resulting output omits the suggestion.

```bash
$ ruby --disable-did_you_mean -e "1.zeor?"
-e:1:in `<main>': undefined method `zeor?' for 1:Integer (NameError)
```

When direct access to the `ruby` command is unavailable, such as in `rails console` or `irb`, the README documents applying the same option through `RUBYOPT`.

```bash
$ RUBYOPT='--disable-did_you_mean' irb
irb:0> 1.zeor?
# => NoMethodError (undefined method `zeor?' for 1:Integer)
```

Disabling the gem for an entire interactive session may hide suggestions that are normally useful. The documented use is narrower: disable it when inspecting the original error shape or isolating an issue in the error object.

There is also a per-error option through `#original_message`. It returns the exception text without suggestions, while leaving the normal `message` call in place. This avoids turning off did_you_mean for the whole process when only one captured exception needs its original wording.

## Limitations of automatic and dictionary-based correction

The main limitation is that a close textual match is not the same as a valid correction. The README does not provide confidence scores, explain how candidates are ranked, or guarantee that a returned method exists on every receiver. A receiver-specific call can produce a plausible method name that is still unavailable in the current execution context.

The standalone SpellChecker has a different limitation: it only has the dictionary supplied by the application. A term absent from that array cannot be matched, and a manually assembled dictionary may omit aliases, constants, or domain-specific values. The README does not document a file-based dictionary loader or a persistent user configuration.

There is also a maintenance cost around Ruby compatibility. Because did_you_mean is bundled and automatically loaded, its behavior is tied to the Ruby runtime rather than solely to an independently upgraded gem in the application. The repository is not archived, and its last push was on 2026-06-23. Release history includes v2.0.0 on 2024-12-04, after v1.6.3 on 2022-12-19. An upgrade should therefore be checked against the target Ruby release rather than treated as an isolated RubyGems update. The README does not provide rollback instructions or a compatibility table for v2.0.0.

## Validation before execution versus suggestions after failure

A real alternative is to validate input before execution and map accepted values in application code. This differs from did_you_mean in both timing and authority. Application validation can reject an unsupported command, typo, or option before invoking Ruby code. It also lets the project define exactly which substitutions are allowed instead of accepting any close textual candidate.

That approach requires maintaining a domain dictionary and writing the validation path. It is useful when accepting external commands, configuration keys, or other strings where execution with a near match could have consequences. did_you_mean is better suited to developer-facing diagnostics after Ruby has already raised a supported exception. Its suggestions do not execute the candidate, but they also do not claim that the candidate is safe or valid.

For application code that already uses strict argument parsing or an allowlist, did_you_mean remains a debugging aid rather than a replacement for those controls. For scripts whose main problem is an unknown method or misspelled constant, it adds useful context with no separate setup on Ruby 2.3 and later.

## Conclusion

Adopt did_you_mean when developers work directly with Ruby exceptions and want closer correction candidates without replacing runtime validation. Do not treat its suggestions as proof that an input is valid, especially in security-sensitive paths where an application should reject unknown values explicitly. Before upgrading from an earlier release, first check the target Ruby version, confirm that the v2.0.0 behavior matches the exception handling in the project, and inspect any use of --disable-did_you_mean or RUBYOPT because either can change which diagnostic behavior developers receive.

## FAQ

### Does did_you_mean come preinstalled with Ruby?

Yes. The README states that Ruby 2.3 and later ships with did_you_mean and automatically requires it when a Ruby process starts, so no special setup is required.

### Can I use did_you_mean without waiting for a Ruby exception?

Yes. You can construct `DidYouMean::SpellChecker` with your own dictionary and call `correct` to receive close matches, as shown with `meail` and `afil`.

### How do I disable did_you_mean or view the original error message?

Use the documented `--disable-did_you_mean` option for the Ruby process, or set it through `RUBYOPT` when direct command access is unavailable. For one error object, call `#original_message` to obtain the message without suggestions.

## Sources

- [Issues](https://github.com/ruby/did_you_mean/issues)
- [License: MIT](https://github.com/ruby/did_you_mean/blob/master/LICENSE)
- [README](https://github.com/ruby/did_you_mean/blob/master/README.md)
- [Releases](https://github.com/ruby/did_you_mean/releases)
- [ruby/did_you_mean on GitHub](https://github.com/ruby/did_you_mean)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ruby-did-you-mean