Ruby Best Practices and Common Mistakes

Ruby is forgiving enough that a lot of non-idiomatic code still runs fine. That doesn't mean it's a good idea. Here's a checklist worth returning to.

Follow snake_case and existing naming conventions

# Avoid
def GetUserName(userID)
  UserName = userID.to_s
end

# Prefer
def get_user_name(user_id)
  user_name = user_id.to_s
end

Methods and variables are snake_case, classes and modules are CamelCase, constants are SCREAMING_SNAKE_CASE. This isn't enforced by the interpreter, but violating it makes Ruby code immediately look foreign to anyone else who reads it — these conventions are followed with unusual consistency across the whole Ruby ecosystem.

Use guard clauses instead of nested conditionals

# Avoid: nested and hard to scan
def process(user)
  if user
    if user.active?
      "Processing #{user.name}"
    else
      "User inactive"
    end
  else
    "No user"
  end
end

# Prefer: flat, with early returns
def process(user)
  return "No user" unless user
  return "User inactive" unless user.active?
  "Processing #{user.name}"
end

Guard clauses (from the conditionals lesson) keep the "happy path" unindented and at the bottom, which is usually the part worth reading most carefully.

Prefer Enumerable methods over manual loops

# Avoid
total = 0
[1, 2, 3, 4].each { |n| total += n if n.even? }

# Prefer
total = [1, 2, 3, 4].select(&:even?).sum

This isn't just style — chained Enumerable methods state intent directly ("select the even ones, then sum them") instead of making the reader trace a mutating accumulator variable to figure out what the loop computes.

Don't rescue Exception, and don't swallow errors silently

# Avoid: hides real bugs, catches things you shouldn't
begin
  risky_call
rescue Exception
  nil
end

# Prefer: specific, and does something with the failure
begin
  risky_call
rescue StandardError => e
  logger.error("risky_call failed: #{e.message}")
  nil
end

Covered in depth in the exception handling lesson — worth repeating here because a swallowed exception is one of the hardest bugs to track down later, since nothing about the program's behavior indicates that anything went wrong at all.

Keep methods short and focused

A method that's doing three unrelated things is a method that's hard to test and hard to name honestly. If you can't summarize a method in one clear sentence, it's probably doing too much — split it into smaller methods with names that describe each piece.

Use a linter

RuboCop is the de facto standard Ruby linter and style-checker, and most professional Ruby codebases run it in CI. It catches style inconsistencies, some categories of bugs, and enforces a shared convention across a team automatically, rather than relying on every reviewer to remember and flag the same things by hand in every pull request.

A final checklist

• [ ] Methods and variables are snake_case; classes are CamelCase.
• [ ] Predicate methods (empty?, valid?) return a boolean; mutating methods are marked with !.
• [ ] Guard clauses replace deeply nested ifs where possible.
• [ ] Enumerable methods (map, select, reduce) are used instead of manual loops for transforming collections.
• [ ] rescue targets specific error classes, never bare Exception.
• [ ] Dependencies are managed through a Gemfile, with Gemfile.lock committed.
• [ ] A linter (RuboCop) runs in CI, not just on one developer's machine.

None of these are exotic — they're the same tools and syntax covered throughout this course, applied with a bit more discipline. That discipline is most of what separates Ruby that merely works from Ruby that's genuinely pleasant to maintain.