Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates to rubocop_rails / rubocop linters #19

Closed
wants to merge 1 commit into from

Conversation

taylorkearns
Copy link
Contributor

  • Exclude the bin and config directories.
  • Disable Style/BlockComments: I see no reason to not allow block comments, and they get used in third-party documentation (spec_helper).
  • Ignore seeds.rb for block length, line length, and module length.
  • Ignore single/double quotes in generated files (Gemfile, Rakefile, etc)

- Exclude the `bin` and `config` directories.
- Disable `Style/BlockComments`: I see no reason to not allow block comments, and they get used in third-party documentation (spec_helper).
- Ignore `seeds.rb` for block length, line length, and module length.
- Ignore single/double quotes in generated files (Gemfile, Rakefile,
etc)
Copy link
Contributor

@kevin-j-m kevin-j-m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, I think this may benefit from smaller, more targeted changes so they can be discussed specifically, as this is addressing a number of (as far as I can tell) unrelated things, some of which the team may agree to and others the team may not. I'm not sure if combining them together makes sense.

However, given they're all here now, I've provided my comments/thoughts on each. If this gets broken out into separate PRs, please consider these comments in those subsequent PRs as part of the discussion.

@@ -41,3 +41,6 @@ Metrics/BlockLength:
Metrics/ModuleLength:
Exclude:
- 'spec/**/*'

Style/BlockComments:
Enabled: false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on your description comment, I'm not sure I follow where you see block comments in a spec helper (by default) that you want to retain. From the documentation describing block comments:

This cop looks for uses of block comments (=begin…=end).

# bad
=begin
Multiple lines
of comments...
=end

# good
# Multiple lines
# of comments...

Moreover, while consistency throughout an application is important, a primary concern of this style configuration is for managing code that we write, not necessarily those of our dependencies (however, I understand the confusion/tension that generated/default code that doesn't adhere to the standard can create).

I personally don't see a need to introduce block comments, and am fine with the default of warning against them.


Metrics/LineLength:
Exclude:
- 'db/seeds.rb'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why shouldn't we adhere to our line length convention in this file?

Style/StringLiterals:
Exclude:
- 'config.ru'
- 'Gemfile'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Gemfile is excluded from the double-quotes cop in our base cop already.

Metrics/BlockLength:
Exclude:
- 'db/seeds.rb'
- 'spec/**/*'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already disabled in our base cop file. This should be unnecessary, and if you're seeing notifications for violating this cop in spec files right now, that points to a different bug or configuration setting that should be addressed differently from specifying it here.

- 'vendor/**/*'

Rails:
Enabled: true

Metrics/BlockLength:
Exclude:
- 'db/seeds.rb'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the justification for removing block length notifications in seeds? I see no problem with being warned about a long block in this location.

- 'config.ru'
- 'Gemfile'
- 'Rakefile'
- 'spec/rails_helper.rb'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file in particular is likely to have things changed in it over time, and I think it should adhere to our quoting standard.

@@ -3,11 +3,34 @@ inherit_from: rubocop.yml
AllCops:
Exclude:
- db/schema.rb
- 'bin/**/*'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm good with this.

@@ -3,11 +3,34 @@ inherit_from: rubocop.yml
AllCops:
Exclude:
- db/schema.rb
- 'bin/**/*'
- 'config/**/*'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we change things in here, I'd rather see that they adhere to our coding standard; however, I know that some cops are violated out of the box, and also that some, like module length, may not make sense to adhere to in these files. However, turning off all cops seems a bit too generic for me.

Exclude:
- 'config.ru'
- 'Gemfile'
- 'Rakefile'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specific for config.ru and Rakefile, is the concern just to get a clean rubocop run with no warnings with generated code? If so, the autoformatter could clean that up for you quickly, and specifically for those 2 files they're unlikely to churn/be seen much over the life of the project.

- 'db/seeds.rb'
- 'spec/**/*'

Style/StringLiterals:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that there is an open issue in gnarails so that projects generated via that template have the provided code adhere to our coding standards defined here out of the box.

@kevin-j-m
Copy link
Contributor

@taylorkearns how can I help with this?

@taylorkearns
Copy link
Contributor Author

Sorry to lag on this, it seems like perhaps this PR should be closed and we should open up smaller PRs to more completely discuss/merge specific changes. Does that sound accurate?

@kevin-j-m
Copy link
Contributor

That works for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants