airbnb/ruby

Ruby Style Guide

ruby's Issues

Link to rationales?

Perhaps a nice way to mitigate the concerns of those who want the guide to be approachable by non-rubyists, without compromising the terseness that some value, would be to add an explicit "Rationale" link to each rule/guideline that links to the pull request where it was discussed?

That would avoid readers having to hunt through git history to figure out why a rule exists.

Another alternative would be to make a separate rationales.md document that was a longer version of the guide, and we could deep link into that from the main readme.

Thoughts?

Editorconfig for airbinb ruby?

Is there an editorconfig for airbnb ruby? If so where can I get it for use.

return from block

The style guide ought to include a note about using return in a block.

From StackOverflow answer

Ruby has three constructs:

1. A block is not an object and is created by { ... } or do ... end.
2. A proc is a Proc object created by Proc.new or proc.
3. A lambda is a Proc created by lambda (or proc in Ruby 1.8).

Ruby has three keywords that return from something:

1. return terminates the method or lambda it is in.
2. next terminates the block, proc, or lambda it is in.
3. break terminates the method that yielded to the block or invoked the proc or lambda it is in.

In lambdas, return behaves like next, for whatever reason. next and break are named the way they are because they are most commonly used with methods like each, where terminating the block will cause the iteration to resume with the next element of the collection, and terminating each will cause you to break out of the loop.

Perhaps the following recommendation:

Avoid return in procs/blocks because return terminates the method calling a proc/block:

def all_even?
  self.numbers.all? do |num| 
    if num % 2 == 0
      # This will cause `all_even?` to return `true` when the first even number is reached
      return true
    else 
      return false
    end
  end
end

def all_even?
  self.numbers.all? do |num| 
    if num % 2 == 0
      # Proceed to the next iteration
      next true
    else 
     # Stop iterating, there is at least one odd number
      break false
    end
  end
end

Method arguments or parameters

I noticed some recent PRs changed the word 'arguments' to 'parameters' but not everywhere.

Any reason?

Ruby 3.1.3

This gem depends on such an outdated version of Rubocop, which is now at 1.39.0, that we're unable to use it with Ruby 3.1.3

Any chance this gem will be updated to support Ruby >= 3.1.3 (and a more recent rubocop version)?

Upgrade to rubocop 0.59.1

Since the version 0.59.1 of rubocop has been released, is there any plan to upgrade to it?

It's not a big issue but I'm still getting some conflicts because of the version 0.57.2 used by rubocop-airbnb.

I'm still a newbie to code but I can help if you tell me what to do to upgrade the dependency version. I guess we should do something like this. As a junior ruby developer, I would be very happy to help.

The negation operator

When I try to use the negation operator without parens, it doesn't work!
With which ruby version did you try the examples?

Method chaining

Hello, is there a rule regarding method chaining? For example:

person = Person.new

# bad
person.name("Peter").age(21).introduce

# good
person.name("Peter")
      .age(21)
      .introduce

If not, can I make a pull request to add one?

Portugueses translate

Hi !

I have translated this guide to pt-BR language.
The link is: https://github.com/caiogranero/ruby-airbnb

I create a pull request inserting the url to the oficial guide.

Add guideline about method calls

I'm not sure if this is an intentional omission, so I figured I'd throw it out there.

Ruby has a lot of syntactic sugar around method invocation. These are my rules around the use of that syntax:

• Use parenthesis...

  • If the method returns a value

    # bad
    @current_user = User.find_by_id 1964192
    
    # good
    @current_user = User.find_by_id(1964192)

  • If the first argument to the method uses a parenthesis

    # bad
    put! (x + y) % len, value
    
    # good
    put!((x + y) % len, value)

• Omit the parenthesis...

  • If the method accepts no arguments

    # bad
    nil?()
    
    # good
    nil?

  • If the method doesn't return a value (or we don't care about the return)

    # bad
    render(:partial => 'foo')
    
    # good
    render :partial => 'foo'

• If a method accepts an options hash as the last argument, do not use { } during invocation

  # bad
  get '/v1/reservations', { :id => 54875 }
  
  # good
  get '/v1/reservations', :id => 54875

Attributes

There is no style advice on attr_accessor, attr_reader, or attr_writer. Can this be added?

Nested or Compact Class and Module naming style?

Hi, is there any specific style that you guys follow for class and module naming style, either nested or compact??
In the rubystyle guide they prefer nested due to surprising constant lookups

Using the scope resolution operator can lead to surprising constant lookups due to Ruby’s lexical scoping
ref: https://rubystyle.guide/#namespace-definition

example of nested:

class Foo
  class Bar
  end
end

example of compact:

class Foo::Bar
end

Could you clarify why there is many disabled cops?

Hello,

first of all thank you to share this project.

I'd like to use the rubocop-airbnb gem in my projects but I'm wondering why there is many Rubocop cops disabled by default.

When I'm looking in the rubocop-airbnb/config folder, I can find 288 disabled cops.

For some of these cops, the disabling reason is documented. But for some others (a majority I guess), this is not the case.

Here are some examples of disabled cops for which I can't find the disabling reason:

• Metrics/MethodLength
• Metrics/PerceivedComplexity
• Naming/ConstantName
• Naming/MethodName
• Bundler/OrderedGems

Will all these disabled cops, I'm feeling like loosing some checks that are done by Rubocop by default.

Kind regards,
Stéphane

Any plans to depend on a more recent version of rubocop?

The gemspec rubocop dependency is set to ~> 0.93.1' locking rubocop to that version which was released on October 12, 2020.
Any plans to relax the dependency specification to perhaps '>= 0.93.1'?

1

https://jccapital.backlog.com/view/FUNDINNO-2835

[Done] Hi, I am translating this guide into chinese.

Repo is here:
https://github.com/1c7/ruby
not done yet, I would let you guys know once I finish it.

I was wondering if possible that, you guys put this link in README.md?

[中文版](https://github.com/1c7/ruby)

like this.

it mean [chinese version here].

thanks :D

Typo on "Concatenation"

"Prefer string interpolation instead of string concatentation:"

Tighten up line length section

I think, in line with the discussion going on in #74, that the current section on line length is probably quite a bit longer than needs to be in the main page. I think it's sufficient to say that lines shouldn't be over 100 characters, and link to a larger section in rationales.md explaining why and providing mitigation strategies. Thoughts?

AutoCorrect Bug

Hi there!

I'm not sure if autocorrect functionality is even supposed to be maintained by this gem as I don't see it in the readme.

However I wanted to open this issue to demonstrate an problem I have been getting when trying to use autocorrect with this gem loaded into my project.

Thanks for your time
-Dan

110 files inspected, 237 offenses detected, 126 offenses corrected
undefined method `range_by_whole_lines' for #<RuboCop::Cop::RSpec::LeadingSubject:0x007fc0d0ae2098>
/Library/Ruby/Gems/2.3.0/gems/rubocop-rspec-1.22.1/lib/rubocop/cop/rspec/leading_subject.rb:65:in `node_range'
/Library/Ruby/Gems/2.3.0/gems/rubocop-rspec-1.22.1/lib/rubocop/cop/rspec/leading_subject.rb:50:in `block in autocorrect'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/corrector.rb:61:in `block (2 levels) in rewrite'
/Library/Ruby/Gems/2.3.0/gems/parser-2.5.1.0/lib/parser/source/tree_rewriter.rb:220:in `transaction'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/corrector.rb:60:in `block in rewrite'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/corrector.rb:58:in `each'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/corrector.rb:58:in `rewrite'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/team.rb:126:in `autocorrect_all_cops'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/team.rb:70:in `autocorrect'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/team.rb:98:in `block in offenses'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/team.rb:115:in `investigate'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/team.rb:94:in `offenses'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cop/team.rb:44:in `inspect_file'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:265:in `inspect_file'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:212:in `block in do_inspection_loop'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:244:in `block in iterate_until_no_changes'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:237:in `loop'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:237:in `iterate_until_no_changes'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:208:in `do_inspection_loop'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:111:in `block in file_offenses'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:129:in `file_offense_cache'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:109:in `file_offenses'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:100:in `process_file'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:78:in `block in each_inspected_file'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:75:in `each'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:75:in `reduce'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:75:in `each_inspected_file'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:67:in `inspect_files'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/runner.rb:39:in `run'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cli.rb:160:in `execute_runner'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cli.rb:88:in `execute_runners'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/lib/rubocop/cli.rb:41:in `run'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/exe/rubocop:13:in `block in <top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/benchmark.rb:308:in `realtime'
/Library/Ruby/Gems/2.3.0/gems/rubocop-0.57.2/exe/rubocop:12:in `<top (required)>'
/usr/local/bin/rubocop:22:in `load'
/usr/local/bin/rubocop:22:in `<main>'

Spanish version

Hi! :D

I've decided to translate this guide into Spanish on behalf of @ruby-ve, greatly inspired by the work of @1c7 on #102

Just one question: Should I translate the fork or is it better to create a new repo for the translation?

Do not set DisableByDefault

You introduced this setting here but it breaks a lot of things, now even a malformed Ruby file (e.g. missing an end) passes as though it had no issue.

(Sorry for the terse issue, if you can't reproduce I will try to add more details later.)

Hash symbol key style is unclear

In the Collections section, we have this example:

# bad
hash = { 'one' => 1, 'two' => 2, 'three' => 3 }

# good
hash = { one: 1, two: 2, three: 3 }

The point of this example is to show using symbols as keys instead of strings. This would be a more clear example as:

# bad
hash = { 'one' => 1, 'two' => 2, 'three' => 3 }

# good
hash = { :one => 1, :two => 2, :three => 3 }

Also, the style guide doesn't seem to comment on the preferred style of symbol keys; the Ruby <= 1.8 style vs the Ruby >= 1.9 style:

# bad/good???
hash = { :one => 1, :two => 2, :three => 3 }

# bad/good???
hash = { one: 1, two: 2, three: 3 }

Allowing symbols when specifying class for Airbnb/ClassName and Airbnb/FactoryClassUseString

Airbnb/ClassName and Airbnb/FactoryClassUseString both work on the idea of not loading the classes. Using a symbol is also a valid way to specify the classes.

# Bad
class: MyClass

# Good
class: "MyClass"

# Also Good
class: :MyClass

Looking into it, it'd be a pretty simple to add the symbol check. I'd be interested in making the PR if this is a use-case you'll allow

Prefer map over collect ?

This style guide says that we should prefer map over collect. but this link (http://rubyinrails.com/2014/01/25/ruby-difference-between-collect-and-map/) clearly explains that in ruby there is no difference between map and collect. Then why to prefer map?
Am i missing something?

Broken link on http://airbnb.io/projects/ruby/

Hullo.

Firstly, thanks for the hard work and sharing your style guides.
http://airbnb.io/projects/ruby/ link to the Google C++ style guide is broken (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml).

The C++ guide now lives here: https://google.github.io/styleguide/cppguide.html

I know http://airbnb.io/projects/ruby/ isn't governed by this repo but that page links to this repo under the "start a convo" button. I did a bit of digging to find the repo containing the source for airbnb.io but couldn't find it.

Let me know if there's a more appropriate repo for this ticket and again THANKS!

Shorten example code

A lot of our sample code blocks are longer than they need to be to get the point across. I think we could do with cleaning these up a bit. The 100-char line limit addressed in #77 is but one example of this.

Discuss.

unable to use because of the rubocop version

$ rubocop --require rubocop-airbnb
Unable to activate rubocop-airbnb-3.0.2, because rubocop-0.82.0 conflicts with rubocop (~> 0.76.0)

Any prediction on when a version will be released?

Hi,

I noticed you're not releasing a new version on RubyGems for quite some time.
Do you have any predictions on when you're going to make the release?

Thanks,

trailing commas in multi-line method arguments

Which is the preferred style?

# 1
return I18n.t('Guest Profile Page: A note for the Host saying the potential Guest has '\
              'not cancelled a reservation since joining Airbnb.',
              :default => '%{guest_name} hasn’t canceled a reservation since joining '\
                          'Airbnb',
              :guest_name => @user.smart_name)

or

# 2
return I18n.t('Guest Profile Page: A note for the Host saying the potential Guest has '\
              'not cancelled a reservation since joining Airbnb.',
              :default => '%{guest_name} hasn’t canceled a reservation since joining '\
                          'Airbnb',
              :guest_name => @user.smart_name,
)

or

# 3
return I18n.t(
  'Guest Profile Page: A note for the Host saying the potential Guest has '\
  'not cancelled a reservation since joining Airbnb.',
  :default => '%{guest_name} hasn’t canceled a reservation since joining '\
              'Airbnb',
  :guest_name => @user.smart_name,
)

or

# 4
return I18n.t(
  'Guest Profile Page: A note for the Host saying the potential Guest has '\
  'not cancelled a reservation since joining Airbnb.',
  :default => '%{guest_name} hasn’t canceled a reservation since joining '\
              'Airbnb',
  :guest_name => @user.smart_name
)

Typo in Syntax Section

After reading through these Ruby style guidelines, I'm extremely impressed, but there is a minor typo. In the syntax section, it currently says...

Some will argue that multiline chaining would look OK with the use of {...}, but they should ask themselves - it this code really readable and can't the blocks contents be extracted into nifty methods.

It should say...

... but they should ask themselves (a) if this code is readable and (b) if the contents of the block could be extracted into nifty methods.

Or something similar. Hope this change can get merged in soon!

Support for 2.1 Syntax

Should the style guide mention:

1. Named parameters
2. Using the { key: value } rather than the { :key => value } syntax

RiskyActiverecordInvocation false positive

File.exists? should not be flagged by RiskyActiverecordInvocation.

Support ruby 2.6

The gem currently forces rubocop 0.58.0, therefore failing to run with Ruby 2.6, even though rubocop itself supports it:

Error: Unknown Ruby version 2.6 found in `.ruby-version`.
Supported versions: 2.2, 2.3, 2.4, 2.5

Link to rule

One of the awesome things about bbatsov's guide is that each rule is accompanied by a link to that particular rule, so that you can easily reference it in a discussion. We should do the same thing here!

License?

Hello,

I'd like to use this style guide as a basis to start our own for my team, but there's no license information and I don't want to step on toes. Can someone please specify how this is made available?

Thanks!

Rubocop dependency update to make VSC extension play well with it

The current gemspec rubocop dependency is set to ~> 1.32.0 locking rubocop to a version which has been released on July 21, 2022.
Any plans to relax the dependency specification to perhaps '>= 1.56.0'?

The real problem for us is that the official VSC extension for Rubocop requires at least version 1.53.0 of rubocop:

[client]   Version reported by `bundle exec rubocop -v`: 1.32.0 (>= 1.53.0 required)

otherwise it doesn't work and we miss the chance to have Rubocop running directly in the IDE.

Kali Linux ruby upgrade error

My problem is that

I use Kali Linux and I am trying to use the tool of "beef", however, for this ,I need to upgrade ruby because I see this error

'Ruby version 2.1.5 is no longer supported. Please upgrade to Ruby version 2.2 or later.'
When I check my version of the ruby it is 'ruby 2.1.5p273 (2014-11-13) [i386-linux-gnu]'.

And then I tried respectively

sudo apt-get install ruby2.0

sudo apt-get install ruby-full

apt-get upgrade

apt-get update
But still I could not upgrade it, how can I upgrade, could you help me, please?

Thank you.

Constants

Ruby style guide...

Use snake_case for methods and variables.
Use CamelCase for classes and modules. (Keep acronyms like HTTP, RFC, XML uppercase.)
Use SCREAMING_SNAKE_CASE for other constants.

^ This is bad style because it promotes unnecessary use of mutable state, which is a source of future bugs. SCREAMING_SNAKE_CASE is really ugly, so people tend to only use it when they feel obligated to, i.e. global constants. But GoF said that coders should favor immutability over mutability (everywhere), not just for global constants.

SCREAMING_SNAKE_CASE is okay for global constants, but what about all the local constants? I would argue that using SCREAMING_SNAKE_CASE for all the immutable local state would uglify the code and would obfuscate the difference between global immutable state and local immutable state. I would argue for a trailing underscore for local constants (so as to differentiate them from class names).

Use snake_case for methods and variables ( def spectacular_flight, bengal_tiger = :tigger ).
Use Camel_Case (with trailing underscore) for local constants (Bengal_tiger_ = :tiger).
Use SCREAMING_SNAKE_CASE for global constants._

I would also argue that snake case doesn't work well with the red and blue underlines in the IDE because the underlines make it hard to see the non-trailing underscores, but the important thing is that compared to other programming languages, Ruby has too much mutable state.

Is it good to use `reverse_merge!` on the optional hash argument of a method?

I found an example in this guide

def obliterate(things, options = {})
  default_options = {
    :gently => true, # obliterate with soft-delete
    :except => [], # skip obliterating these things
    :at => Time.now, # don't obliterate them until later
  }
  options.reverse_merge!(default_options)

  ...
end

I'm wondering whether this is a good practice. When you use this method, the input options hash might be modified by reverse_merge! method, which, in my opinion, is very error-prone process in a big project.

Rubocop ruleset?

Is there a rubocop ruleset for this coding style similar to your eslint for js?

config/default.yml does not match Rubocop of the same version

It looks like this file: https://github.com/airbnb/ruby/blob/master/rubocop-airbnb/config/default.yml must be updated. It has not been updated for 3 years even though rubocop dependency has been updated for many times since then.

This gem is dependent on 'rubocop', '~> 0.80.0', but config/default.yml in this repo is not the same as default.yml in rubocop 0.80.0. This is an issue because this file lists all cops and supported styles for them. So if one wants to use a style that was added in 0.80.0, they cannot because of the outdated default.yml. Therefore, the possibilities of configuration are greatly restricted.

Is there a reason why this file is so old?

`RuboCop::Cop::Airbnb::ModuleMethodInWrongFile` returns incorrect error message when defining a method inside singleton class

When developing PR #189, tests were changed to use new rspec-rubocop syntax which also checks that the message generated is correct. After doing this, the spec that checks that an error is returned when using "<<" static methods and a non-matching name failed with an incorrect message:

Method baz should be defined in foo/foo.rb

When the expected message was:

Method baz should be defined in foo.rb

After digging a little about it to understand what was happening, we realized that this incorrect message is also present on master – but there are no assertions respecting the offense's text, thus the test succeeds.
The issue seems to be caused by the method normalize_module_name(node.parent_module_name) (on module_method_in_wrong_file.rb#L88) which returns Foo::Foo instead of just Foo.