ruby

Ruby Best Practices

Our team adheres to a strict set of Ruby best practices, primarily enforced by RuboCop and aligned with the official Ruby and Rails Style Guides. This document serves as your definitive reference for writing clean, efficient, and maintainable Ruby code.

1. Code Organization & Structure

Adhere to the Single Responsibility Principle (SRP) and keep files focused.

1.1 Single Class/Module Per File

Each Ruby file must define a single class or module. Name the file using snake_case corresponding to the CamelCase class/module name.

❌ BAD

# user.rb
class User; end
class UserProfile; end

✅ GOOD

# user.rb
class User; end

# user_profile.rb
class UserProfile; end

1.2 Rails Directory Structure

Follow Rails' "convention over configuration" for project structure.

❌ BAD

# app/services/user_management/create_user.rb
# app/validators/email_validator.rb

✅ GOOD

# app/services/user_management/create_user.rb (for complex logic)
# app/validators/email_validator.rb (standard Rails convention)

1.3 Configuration Files

Place custom initialization code in config/initializers. Keep gem-specific initializers in separate files named after the gem.

❌ BAD

# config/initializers/app_setup.rb
# Contains setup for CarrierWave, Sidekiq, and custom app config.

✅ GOOD

# config/initializers/carrierwave.rb
# config/initializers/sidekiq.rb
# config/initializers/custom_app_config.rb

2. Formatting

Consistency is paramount. RuboCop enforces these rules automatically.

2.1 Indentation & Line Length

Use two-space soft tabs. Limit lines to 120 characters to balance readability and screen real estate.

❌ BAD

def long_method_name(param1, param2, param3, param4, param5, param6, param7) # > 120 chars
    puts "This line is indented with four spaces."
end

✅ GOOD

def long_method_name(param1, param2, param3, param4, param5, param6, param7)
  puts "This line is indented with two spaces."
end