161

I would like Rubocop to ignore lines with comments (just a comment or some code with an end of line comment) when checking if a line is too long. Is there a way to do this?

BinaryButterfly
  • 18,137
  • 13
  • 50
  • 91
Twiek
  • 2,013
  • 2
  • 14
  • 14

5 Answers5

278

There is a way to ignore cops on a per line basis.

There is also a way to do it via configuration file.

Run rubocop --auto-gen-config and it will generate a file that you can use to disable the offenses.

The command also gives a hint on what to do to load those options.

On a line per line basis, you can enable and disable the cops as well.

# rubocop:disable RuleByName
This is a long line 
# rubocop:enable RuleByName

You can also do more than one rule at a time in your code.

# rubocop:disable BlockComments, AsciiComments

By using an inline directive, the directive becomes valid only for that line, and it would look like this:

# Thanks to @jnt30 for the comment!
method(argument) # rubocop:disable SomeRule, SomeOtherRule

You can read a ton more about RuboCop in its official manual.

To find all the rule names its worth looking in the rubocop config files

cyberwiz says - "run rubocop -D when I need the rule names rather than looking in the documentation." Update: This is now the default behavior without the flag.

The -D is now default, so we would get that for "free" now.

vgoff
  • 10,980
  • 3
  • 38
  • 56
  • 1
    Well, the comments may explain the deviation from a style that has been accepted by the team, so this is not a bad thing, right? Otherwise you place it in the rubocop.yml file, and then it is not an accepted style exception, and doesn't need a comment. The comment says "I meant to do that!". Not a bad thing at all. – vgoff Oct 17 '14 at 17:28
  • 2
    comments are not code, so checking them is semantically different and IMO rubocop should treat it that way. – phoet Oct 17 '14 at 17:52
  • 2
    Comments are a part of code, and when you deal with code in e-mail or on a terminal. I think that it is bad taste to not have your comments adhere to the same line lengths that have been adopted by "the team" as the code. They shouldn't disrupt the flow just because they are comments. I am sure that rubocop doesn't check comments for anything, other than directives, semantically (meaningfully). It does check line length and the style of comments. So no, it isn't looking for meaning, it is only checking style. Don't discount that "comments are not code" doesn't have to be. – vgoff Oct 18 '14 at 21:15
  • Indeed, even the `#!/bin/env ruby` comment line is a comment, yet code, and is semantically important. Comments aren't always only "comments". – vgoff Oct 18 '14 at 21:18
  • FYI, the docs for this feature have moved to: http://rubocop.readthedocs.io/en/latest/configuration/#disabling-cops-within-source-code – Ajedi32 Jul 22 '16 at 16:55
  • 1
    Another thing to note, you can also use an "inline" disable by terminating your line with the exclusion so you don't have to enabled it again. Doing so will only disable that rule for the given line, not all coming after it. – jnt30 Oct 19 '16 at 21:22
  • 1
    @Twiek is there anything missing from this answer that you are looking for? – vgoff Oct 24 '16 at 17:05
  • I know it is a late answer @jnt30 and in the case of a long line, perhaps it is long enough that you would not note the directive if it is past the end of the visible line. In shorter lines, where we might have deviated from the style, this does make sense to do! – vgoff Sep 13 '22 at 18:16
49

It's possible to define regex patterns to automatically ignore certain lines in rubocop.yml, so you could choose to ignore all lines starting with a # character:

Layout/LineLength:
  Max: 80
  AllowedPatterns: ['\A#']

Or:

Layout/LineLength:
  Max: 80
  AllowedPatterns:
    - !ruby/regexp /\A#/

This could be improved so that "indented" comment lines (i.e. whitespace followed by a # character) are also ignored, if that's what you want. e.g.

Layout/LineLength:
  Max: 80
  AllowedPatterns:
    - !ruby/regexp /\A *# /

Note that this doesn't account for lines of code that end with a comment, though:

some_code(that_does_something) # This line would NOT be ignored by Rubocop.
pdobb
  • 17,688
  • 5
  • 59
  • 74
GoBusto
  • 4,632
  • 6
  • 28
  • 45
  • 13
    You can expand that regexp by include lines that can have whitespaces: `IgnorePatterns: ['(\A|\s)#']` – poustovitss Nov 10 '17 at 13:21
  • 3
    **Thanks** @poustovitss. There's a typo: it should be `IgnoredPatterns` instead `IgnorePatterns` (it's missing the letter 'd'). – Horacio Dec 11 '17 at 22:44
  • 3
    I used: `IgnoredPatterns: ['^ *# '] ` This allows full-line comments with any indentation. It does not ignore code with trailing comments, which is my preference. – David Hempy Sep 24 '20 at 19:50
  • 2
    Warning: obsolete parameter `IgnoredPatterns` (for `Layout/LineLength`) found in .rubocop.yml `IgnoredPatterns` has been renamed to `AllowedPatterns`. <- for latest versions – dcangulo Apr 30 '22 at 02:41
  • I don't understand why `IgnoredPatterns` was renamed `AllowedPatterns`, the words Ignored and Allowed have opposite meaning. – David Cruwys Jun 04 '22 at 05:02
  • 1
    @DavidCruwys same thought! super confusing. – courtsimas Aug 11 '22 at 02:49
  • Allowed* is the standardized wording throughout Rubocop now. I find that it means the same as "Ignored" in the sense that: "IgnoredPatterns" are things that the cop will ignore (let slide), and "AllowedPatterns" are things that the cop will allow (not arrest you for). – pdobb May 20 '23 at 02:28
24

You can use the following comment with rubocop to ignore a specific rule:

# rubocop:disable Layout/LineLength
def this_could_be_a_very_long_line_that_extends_forever_into_infinity
end
# rubocop:enable Layout/LineLength

You can also ignore whole files by adding them to .rubocop.yml:

AllCops:
  Exclude:
    - path/to/file.rb
Mick F
  • 7,312
  • 6
  • 51
  • 98
5

i think the basic idea here is that you want to enforce line length, no matter what is after n characters. the default to 80 characters is some cargo cult for old terminal windows that could only hold that number of chars. the only option that i saw in the code is an option to allow urls that might exceed the character limit.

you can ignore whole files, i guess that's not what you are looking for.

phoet
  • 18,688
  • 4
  • 46
  • 74
  • 8
    These days, the idea behind 80 chars isn't so much "cargo cult" for the terminal, there's still a logical reason for it: anyone can split their editor or IDE windows however they want, and as long as they're just wider than 80 characters, they won't need to change the width or experience wrapping. – Jason Antman Feb 17 '16 at 15:38
  • 2
    IMO if you don't have an IDE that supports soft wrapping, your tooling is not up to date. – phoet Feb 20 '16 at 08:55
  • 8
    80 chars is also pretty readable, whereas 40 or 200 is less so, so it's also a usability thing – Toni Leigh Apr 18 '16 at 07:43
  • #1 "as long as they're just wider than 80 characters" 800x600 is wider than 80 chars, and you have same problem viewing side-by-side 2 80 chars files. This is nonsense and only applies to 1366 res. With 1920+ taking over, the next argument will be "I can split 3, 4 files" – Andre Figueiredo Jul 05 '17 at 14:12
  • #2 "80 chars is also pretty readable, whereas 40 or 200 is less so" Another common Straw Man argument, it's pretty fine goes with 100 chars. Commonly 100 chars, you have 10 first white space, you can split, you can wrap, you have HOME/END keys on your keyboard, you have plenty options of Diff plugins/tools... – Andre Figueiredo Jul 05 '17 at 14:19
  • 1
    we had it at 80, then changed it to 120. Looking at PR's while doing code review on Github in a split-screen view on 13" laptops became a problem. we switched back to 80. – AndreiMotinga Oct 07 '19 at 15:55
0

The following configuration worked for me:

Layout/LineLength:
  AllowedPatterns: ['^(\s*#)']

This regex only works when the entire line is commented out. Code followed by a long comment on the same line will still trigger a Rubocop lint error, which is by design.

Vadim
  • 1,916
  • 2
  • 19
  • 39