- Styles we have no rule for
- Styles we have no opinion on
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.
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.
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.
In addition to the RuboCops
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
# 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
# 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
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.
Due to the sheer amount of work to rectify, we do not care whether string literals are single or double-quoted.
Previous discussions include: