Variable Naming: Ruby Best Practices
Top 10 Tips You Need to Know
When naming variables in Ruby, it’s important to follow certain best practices to ensure code readability and maintainability. Here are ten best practices for naming variables in Ruby:
Use descriptive names
Choose variable names that clearly indicate their purpose and meaning. Avoid using single-letter or cryptic names that can be confusing to other developers.
Single-letter variable names are bad.
Examples:
# Bad
a = 5
# Good
age = 5
# Bad
x = 10
y = 5
result = x + y
# Good
num1 = 10
num2 = 5
sum = num1 + num2Cryptic variable names are bad.
Examples:
# Bad
fn = "John"
ln = "Doe"
# Good
first_name = "John"
last_name = "Doe"
# Bad
temp = get_temp("New York", "2023-07-14")
# Good
temperature = get_temperature("New York", "2023-07-14")
# Bad
el = find_element_by_id("submit-btn")
# Good
submit_button = find_element_by_id("submit-btn")Use lowercase with underscores
Follow the snake_case convention for variable names, where words are separated by underscores and all letters are lowercase. For example, user_name or total_amount.
Be consistent
Maintain a consistent naming style throughout your codebase to enhance readability and make it easier for others to understand your code.
Avoid reserved keywords
Do not use Ruby reserved keywords like if, class, or end as variable names. Using reserved keywords can lead to syntax errors and confusion.
Reserved keyword variables are bad.
# Bad
class = "User"
# Good
user_class = "User"
# Bad
if = true
# Good
is_valid = true
# Bad
end = Time.now
# Good
end_time = Time.now
# Bad
end = Time.now
# Good
end_time = Time.now
# Bad
private = true
# Good
is_private = trueSingular or plural
Choose variable names that reflect whether the variable represents a single item or a collection. For example, use user for a single user and users for a collection of users.
Get Patrick Karsh’s stories in your inbox
Join Medium for free to get updates from this writer.
Example:
# Single user
user = User.new
# Collection of users
users = User.allAvoid abbreviations
Aim for clarity by avoiding excessive abbreviations in variable names. Instead, use descriptive names that convey the purpose of the variable.
Examples:
# Bad
cust_addr = "123 Main St"
# Good
customer_address = "123 Main St"
# Bad
num_items = 5
# Good
number_of_items = 5
# Bad
qty = 10
# Good
quantity = 10
# Bad
prod_desc = "Ruby book"
# Good
product_description = "Ruby book"Use nouns for objects
When naming variables that represent objects or entities, use nouns or noun phrases. For example, customer, product_list, or order_amount.
Examples:
# Bad
fetch = Customer.fetch_data
# Good
customer = Customer.fetch_data
# Bad
prod = Product.new
# Good
product = Product.new
# Bad
user_info = User.get_info
# Good
user = User.get_info
# Bad
amt = order.total_amount
# Good
order_amount = order.total_amountUse verbs for actions
If a variable represents an action or a boolean value, consider using a verb or verb phrase as the variable name. For example, is_valid, calculate_total, or fetch_data.
Example:
# Checking if a user is logged in
is_logged_in = true
# Calculating the total amount
total_amount = calculate_total(items)Avoid unnecessary prefixes or suffixes
In most cases, it’s best to avoid adding prefixes like my_ or suffixes like _var to variable names. These additions often add noise and reduce readability without providing much value.
Unnecessary prefix examples:
# Bad
my_name = "John"
# Good
name = "John"
# Bad
my_array = [1, 2, 3]
# Good
array = [1, 2, 3]
# Bad
my_object = create_object
# Good
object = create_objectUnnecessary suffix examples:
# Bad
count_var = 5
# Good
count = 5
# Bad
price_val = calculate_price(quantity)
# Good
price = calculate_price(quantity)Adding prefixes like my_ or suffixes like _var to variable names often adds unnecessary noise and reduces readability without providing valuable information. In most cases, it’s best to choose concise and meaningful names that clearly represent the purpose of the variable. By avoiding unnecessary prefixes or suffixes, you can keep your code clean, clear, and easier to understand for both yourself and other developers working with your code.
Update variable names when their purpose changes
If the purpose of a variable changes during the course of development, make sure to update its name accordingly to reflect its new role. This helps prevent confusion and maintain code clarity.
Conclusion
Remember, the ultimate goal is to write code that is easy to understand, both for yourself and other developers who may read or maintain your code in the future.







