Back to all reviewers

Use descriptive identifiers

discourse/discourse
Based on 12 comments
Ruby

Choose names that clearly communicate purpose and reduce cognitive load for future readers. Avoid generic, abbreviated, or ambiguous identifiers in favor of self-documenting ones.

Naming Conventions Ruby

Reviewer Prompt

Choose names that clearly communicate purpose and reduce cognitive load for future readers. Avoid generic, abbreviated, or ambiguous identifiers in favor of self-documenting ones.

Key principles:

  • Variables: Use descriptive names that indicate content and purpose (@tags_with_synonyms instead of @synonym_target_tag_ids)
  • Parameters: Make parameter names explicit about what they accept (post_or_post_id instead of post_id when accepting both Post objects and IDs)
  • Methods: Include context when it aids clarity (update_category_read_restricted instead of update_read_restricted_flags)
  • Constants: Use descriptive names over generic ones (NO_DESTINATION_COOKIE instead of NO_COOKIE)
  • SQL aliases: Prefer readable aliases over cryptic abbreviations (mapped_categories instead of mc)

Example:

# Avoid: Generic parameter name that doesn't indicate flexibility
def reset_bumped_at(post_id = nil)
  post = post_id.is_a?(Post) ? post_id : Post.find(post_id)
end

# Prefer: Clear parameter name indicating it accepts both types
def reset_bumped_at(post_or_post_id = nil)
  post = post_or_post_id.is_a?(Post) ? post_or_post_id : Post.find(post_or_post_id)
end

The goal is to write code that reads like well-written prose, where the intent is immediately clear without requiring additional mental parsing or context switching.

12
Comments Analyzed
Ruby
Primary Language
Naming Conventions
Category

Source Discussions