Ruby style guide

This is a GitLab-specific style guide for Ruby code. Everything documented in this page can be reopened for discussion.

We use RuboCop to enforce Ruby style guide rules.

Where a RuboCop rule is absent, refer to the following style guides as general guidelines to write idiomatic Ruby:

Generally, if a style is not covered by existing RuboCop rules or the above style guides, it shouldn’t be a blocker.

Some styles we have decided no one should not have a strong opinion on.

See also:

Styles we have no rule for

These styles are not backed by a RuboCop rule.

For every style added to this section, link the discussion from the section’s version history note to provide context and serve as a reference.

Instance variable access using attr_reader

Introduced in GitLab 14.1.

Instance variables can be accessed in a variety of ways in a class:

# public
class Foo
  attr_reader :my_var

  def initialize(my_var)
    @my_var = my_var
  end

  def do_stuff
    puts my_var
  end
end

# private
class Foo
  def initialize(my_var)
    @my_var = my_var
  end

  private

  attr_reader :my_var

  def do_stuff
    puts my_var
  end
end

# direct
class Foo
  def initialize(my_var)
    @my_var = my_var
  end

  private

  def do_stuff
    puts @my_var
  end
end

Public attributes should only be used if they are accessed outside of the class. There is not a strong opinion on what strategy is used when attributes are only accessed internally, as long as there is consistency in related code.

Newlines style guide

In addition to the RuboCops Layout/EmptyLinesAroundMethodBody and Cop/LineBreakAroundConditionalBlock that enforce some newline styles, we have the following guidelines that are not backed by RuboCop.

# bad
def method
  issue = Issue.new

  issue.save

  render json: issue
end

# good
def method
  issue = Issue.new
  issue.save

  render json: issue
end

Rule: newline before block 

# bad
def method
  issue = Issue.new
  if issue.save
    render json: issue
  end
end

# good
def method
  issue = Issue.new

  if issue.save
    render json: issue
  end
end
Exception: no need for a newline when code block starts or ends right inside another code block 
# bad
def method
  if issue

    if issue.valid?
      issue.save
    end

  end
end

# good
def method
  if issue
    if issue.valid?
      issue.save
    end
  end
end

Styles we have no opinion on

If a RuboCop rule is proposed and we choose not to add it, we should document that decision in this guide so it is more discoverable and link the relevant discussion as a reference.

Quoting string literals

Due to the sheer amount of work to rectify, we do not care whether string literals are single or double-quoted.

Previous discussions include:

Type safety

Now that we’ve upgraded to Ruby 3, we have more options available to enforce type safety.

Some of these options are supported as part of the Ruby syntax and do not require the use of specific type safety tools like Sorbet or RBS. However, we might consider these tools in the future as well.

For more information, see Type safety in the remote_development domain README.

Functional patterns

Although Ruby and especially Rails are primarily based on object-oriented programming patterns, Ruby is a very flexible language and supports functional programming patterns as well.

Functional programming patterns, especially in domain logic, can often result in more readable, maintainable, and bug-resistant code while still using idiomatic and familiar Ruby patterns. However, functional programming patterns should be used carefully because some patterns would cause confusion and should be avoided even if they’re directly supported by Ruby. The curry method is a likely example.

For more information, see: