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

LineLength: add an IgnoreComments parameter #977

Closed
chastell opened this issue Apr 9, 2014 · 5 comments
Closed

LineLength: add an IgnoreComments parameter #977

chastell opened this issue Apr 9, 2014 · 5 comments

Comments

@chastell
Copy link
Contributor

chastell commented Apr 9, 2014

Sometimes comments contain lines that can’t be easily wrapped (like URLs). Currently, the only way to not trigger LineLength with such comments is to exclude the whole file.

I think it would make sense to add an IgnoreComments parameter to LineLength, so that such comments wouldn’t trigger the cop.

@jonas054
Copy link
Collaborator

jonas054 commented Apr 9, 2014

In such cases I would use

# rubocop:disable LineLength
# section containing unbreakable long comments
# rubocop:enable LineLength

That would disable the cop in just the special part of the code that can't conform. Generally speaking, long comment lines are just as bad as long code lines, so I'd prefer leaving the checks enabled to the largest possible extent.

@chastell
Copy link
Contributor Author

chastell commented Apr 9, 2014

Ok, this makes sense. I’ll see how well the rest of the team likes this. ;)

@chastell chastell closed this as completed Apr 9, 2014
@yujinakayama
Copy link
Collaborator

I agree to the “long comment lines are just as bad as long code lines”, but at the same time I think putting rubocop:disable LineLength for each long URL (such as URL of a commit on GitHub) is ugly and annoying. I think probably we can detect URLs and automatically allow them.

@bbatsov
Copy link
Collaborator

bbatsov commented Apr 9, 2014

Maybe. I was thinking that such a problem exists in the code as well:

URL = 'http://veeeerrryyyyyyy.looooooooooooong-boooooooooooring-naaaaaaaaaaaaame.com'

@jdickey
Copy link

jdickey commented Apr 16, 2014

Good argument for URL shorteners. We've been using Bit.ly, coupled with explanatory comments, when we run into things like that. Yes, shorteners kill semantics and bring in an outside dependency, but does anyone have any better ideas? We'd experimented with a UrlRegistry class that basically just wrapped a Hash of "meaningful" short symbolic names associated with URL-as-string values; that seems almost as bad, complicating reuse across projects...

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

No branches or pull requests

5 participants