RuboCop 0.80: Ruby static code analyzer and code formatter(docs.rubocop.org)
docs.rubocop.org
RuboCop 0.80: Ruby static code analyzer and code formatter
https://docs.rubocop.org/en/stable/
53 comments
Every RuboCop rule is reasonable. That is, you can look up the reason and see if you agree or not.
Our team has overridden about a dozen rules (we bumped up line length and class length), but I find most of the default rules are fine.
Out of curiosity, what rules are unreasonable to you?
Our team has overridden about a dozen rules (we bumped up line length and class length), but I find most of the default rules are fine.
Out of curiosity, what rules are unreasonable to you?
In my opinion the rules about requiring or forbidding parentheses are fairly arbitrary.
Sometimes it's really nice to fit three panes of code on a single laptop screen. Long lines can also indicate a code smell. It's ironic that one of the first things most teams change is the 80 character line length.
Sometimes it's really nice to fit three panes of code on a single laptop screen. Long lines can also indicate a code smell. It's ironic that one of the first things most teams change is the 80 character line length.
I remember having a bug because Rubocop changed 'and' to '&&'. I don't think that a linter should have a rule that breaks the language rules
Yup. `conditional or return fallbackValue`. Rubocop desperately wants to change this to `conditional || return fallbackValue` but that's just.... not a thing.
Not every rule has a reason, some of it is just "because style guide" and if you try to look up the rationale there, you'll find none.
Classic example is Perl style %w(literal arrays) vs ['traditional', 'arrays'].
> Prefer `%w` to the literal array syntax when you need an array of strings
Which was introduced[1] into the style guide nearly 9 years ago with practically no reasoning. Prefer `%w` because why exactly?
[1] https://github.com/rubocop-hq/ruby-style-guide/commit/b27eff...
Classic example is Perl style %w(literal arrays) vs ['traditional', 'arrays'].
> Prefer `%w` to the literal array syntax when you need an array of strings
Which was introduced[1] into the style guide nearly 9 years ago with practically no reasoning. Prefer `%w` because why exactly?
[1] https://github.com/rubocop-hq/ruby-style-guide/commit/b27eff...
I prefer the brackets to parens because it makes it more clear at a glance that the result is an array.
Shorter. Different code coloring. I prefer %w where possible with or without Rubocop.
Some rules break Ruby semantics - if you apply their 'rule' you get a program that does something different! I think that's an unreasonable rule.
FWIW, I was just sharing this with someone the other day when discussing the same issue https://gist.github.com/whalesalad/820810f2e969eef816402241a...
Gems in Gemfile ordered alphabetically :/
‘private’ methods forced to be NOT indented.
The thing about that is, what's reasonable for you and your team is not always reasonable for me and my team.
Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen.
Most of the members of my team don't use this font, or even the same terminal, so I think that a 110 character limit is a good compromise, ...but I don't work alone, and so if we're going to set a standard, it should be a discussion and we should all have input before it's agreed to.
On the other hand you have tools like Rufo (or prettier, or gofmt) where these kinds of discussions are considered as wasteful and inviting unnecessary conflict about the color of the bike shed. There's a strong argument to be made that there is a reasonable default for standards, and it follows that we all should use the same standards as everyone else, and be glad that there's only one standard to worry about!
Rubocop is a much bigger tool than Rufo. I am glad, personally, that the developers of these tools talk to each other, and in some cases they have made efforts to make sure the defaults of both tools do not step on each other, which would make it impossible to use the two slightly orthogonal tools together on the same project. (I hope my team will find the means to adopt one or both of these tools soon!)
Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen.
Most of the members of my team don't use this font, or even the same terminal, so I think that a 110 character limit is a good compromise, ...but I don't work alone, and so if we're going to set a standard, it should be a discussion and we should all have input before it's agreed to.
On the other hand you have tools like Rufo (or prettier, or gofmt) where these kinds of discussions are considered as wasteful and inviting unnecessary conflict about the color of the bike shed. There's a strong argument to be made that there is a reasonable default for standards, and it follows that we all should use the same standards as everyone else, and be glad that there's only one standard to worry about!
Rubocop is a much bigger tool than Rufo. I am glad, personally, that the developers of these tools talk to each other, and in some cases they have made efforts to make sure the defaults of both tools do not step on each other, which would make it impossible to use the two slightly orthogonal tools together on the same project. (I hope my team will find the means to adopt one or both of these tools soon!)
80 characters is nice for side by side buffers. Also, lines that are too long horizontally are difficult to scan (especially if they are much longer than the lines around them) and can benefit from some work on vertical layout.
How much time do developers spend on side by side buffers?
I get the difficult to scan point (although I find it subjective) but the side-by-side argument is optimizing for a comparatively small use case.
I get the difficult to scan point (although I find it subjective) but the side-by-side argument is optimizing for a comparatively small use case.
> How much time do developers spend on side by side buffers?
I know this is a bit of a rare condition, but I have very sensitive eyes, so I need to work on a single small laptop screen with decently large font size, otherwise I get eyestrain and I'm out for a week. So when I have two emacs windows open even 80 characters wraps around. I put up with it, but when a codebase has something like 70 or less characters per line I find it much easier to develop in.
It's my default.
On the left buffer I've got the implementation, on the right buffer I've got the spec/test.
It's my default mode of working. Even in a statically-typed language (I mostly write Haskell these days), I often have one buffer for the things I'm working on, and 1..N buffers of references or parallel changes.
> Case and point, 80 character line limit: this was a reasonable limit when command lines were not usually rendered inside of high-res framebuffers, I have my font set to 12 point M+ font, which is a narrow width font, so my terminals are set to open at 180 characters wide and it only takes up half the width of my screen.
Use three terminals? No, seriously, you can pack even more information into the screen than you already do, which was already presumably your intent when you switched to the font. Wouldn't that be the logical end-limit here? After all, most tools still standardize around 80 characters, most terminals on GUI machines start up for the first time with 24 rows and 80 columns. It seems like you're arguing against an unnecessary standard.
Hell, wouldn't the proper solution here be to add a flag or a config file to the analyzer to alter the defaults, rather than. This is already a solved problem for code analyzers in general, most C linters (including clint) support these flags.
Use three terminals? No, seriously, you can pack even more information into the screen than you already do, which was already presumably your intent when you switched to the font. Wouldn't that be the logical end-limit here? After all, most tools still standardize around 80 characters, most terminals on GUI machines start up for the first time with 24 rows and 80 columns. It seems like you're arguing against an unnecessary standard.
Hell, wouldn't the proper solution here be to add a flag or a config file to the analyzer to alter the defaults, rather than. This is already a solved problem for code analyzers in general, most C linters (including clint) support these flags.
I'm actually not arguing to change the default, I'm arguing that the team should have a conversation and decide on whether the default is reasonable for them. I'm not using a narrow width font because I want to pack more information on the screen, in fact I'm using it because it's more readable, at any size (small or large.)
I actually hope that when I have this conversation with my team, someone looks at my screen and says "hey, that is a nice font, and more readable than what I've been using."
I actually hope that when I have this conversation with my team, someone looks at my screen and says "hey, that is a nice font, and more readable than what I've been using."
> After all, most tools still standardize around 80 characters
I use standard Linux tools for development, and none of the tools themselves have any column standard. Probably text-only emails are the only thing that have a "standard" of 80 columns.
> most terminals on GUI machines start up for the first time with 24 rows and 80 columns
This doesn't really mean anything. I don't think there's anybody who leaves the terminal as it is, as even on a modest 1080, that'd be one quarter of the screen area.
I use standard Linux tools for development, and none of the tools themselves have any column standard. Probably text-only emails are the only thing that have a "standard" of 80 columns.
> most terminals on GUI machines start up for the first time with 24 rows and 80 columns
This doesn't really mean anything. I don't think there's anybody who leaves the terminal as it is, as even on a modest 1080, that'd be one quarter of the screen area.
I get your point, but i think the main reason for using 80 character line length nowadays is that its more readable. Books use often line lenght of about 60 characters for this reason.
That's fine, when it is more readable... but there is a convention in Ruby of making your classes and method names as descriptively as possible, not even ruling out the possibility that they might be very nearly full sentences.
I am in strong agreement that there should be a character limit, and I'm even convinced that my 180 character wide terminal is longer than what would be an appropriate limit. But 80 characters is less than half of that, and so I'm not convinced that honoring a default 80 character limit is going to make anything more readable, more likely that it will just result in me turning up my font size so there is not so much unused space on my screen.
I think it's also true that most people use a larger than 80 character wide terminal today.
I guess the point is, without getting hung up on this knob in particular, that fewer knobs is pretty much always better; at least that was the central theme of the issue where I got the idea that Rufo maintainer team has this outlook: https://github.com/ruby-formatter/rufo/issues/2
I am in strong agreement that there should be a character limit, and I'm even convinced that my 180 character wide terminal is longer than what would be an appropriate limit. But 80 characters is less than half of that, and so I'm not convinced that honoring a default 80 character limit is going to make anything more readable, more likely that it will just result in me turning up my font size so there is not so much unused space on my screen.
I think it's also true that most people use a larger than 80 character wide terminal today.
I guess the point is, without getting hung up on this knob in particular, that fewer knobs is pretty much always better; at least that was the central theme of the issue where I got the idea that Rufo maintainer team has this outlook: https://github.com/ruby-formatter/rufo/issues/2
On that knob -- I prefer 80 characters today because it allows me to place two panes of code side-by-side without wrapping on one monitor. Sometimes I throw in a REPL pane as well as or instead of the second pane.
But I also have come to like prettier's approach. At least, I did last time I used it a year or two back. Almost no configuration, no bikeshedding, it just reformats your js code and doesn't sweat the rest. It's not having every style exactly how I like it, but it's much nicer than the eslint/jshint/etc hell I used to configure. Of course to some extent these tools solve some different problems but I didn't really feel much of a need to keep eslint around once prettier started enforcing its standards.
But I also have come to like prettier's approach. At least, I did last time I used it a year or two back. Almost no configuration, no bikeshedding, it just reformats your js code and doesn't sweat the rest. It's not having every style exactly how I like it, but it's much nicer than the eslint/jshint/etc hell I used to configure. Of course to some extent these tools solve some different problems but I didn't really feel much of a need to keep eslint around once prettier started enforcing its standards.
Definitely check out prettier for Ruby then! https://github.com/prettier/plugin-ruby. Actively working toward 1.0.
This! I prefer 80 characters so I can have two panes of code side by side or a REPL next to my code. It is near impossible to do that on a laptop if the line length is extended to 110 without a line wrap.
Point being, everyone has very different preferences and work practices. Team standards are going to be very different from team to team but standards do help reduce cognitive overhead on wondering if line lengths or other styles need to be different.
Point being, everyone has very different preferences and work practices. Team standards are going to be very different from team to team but standards do help reduce cognitive overhead on wondering if line lengths or other styles need to be different.
80 character is better for us old coders who need a larger font size but still want to see two files side by side on a small laptop screen without side scrolling.
I'd love to accommodate you, but I'm still struggling to get my team of 8 to agree that we should impose any line length limit. My terminal is 180 characters wide because I have some team members that don't seem to believe in line breaks as a force of habit.
You don't even know how long these 100 line functions really are! It's abusive, bottom line.
You don't even know how long these 100 line functions really are! It's abusive, bottom line.
80 characters is best for those of us with disabilities who still rely on limited real estate screens.
This has been my experience too. Fortunately rubocop makes it easy to distribute alternate settings as gems. I use https://github.com/sider/meowcop as a reasonable base setting. It's more relaxed about style and makes rubocop more of a linter, which is what I want.
This is exactly nice about it. With Rubocop standardrb (https://github.com/testdouble/standard) has a solid foundation to make everyone's live easy.
What are some pain points in your experience? You don't have to be super specific but I'm just curious what parts get in your way when you use it with standard config?
I'd say that in our environment we introduced Rubocop into a 4 year old Ruby project that started on Ruby 1.9 and is now on 2.5, our code has a lot of warts.
We run rubocop (including a handful of our own custom cops for enforcing US-english spelling, and some specific "remember to use a transaction here") only on changed files (using codeclimate)
That means as we gradually touch more and more of our older code, we slowly enforce the styleguide.
We don't run a lot of custom configs globally (none, I think) and disable selective overzealous cops on specific lines, or blocks.
Some notable annoyances are `def Something()` which is named this way to model it after the coercions in Kernel, which rubocop complains about because of the pascal casing, and a couple of cases of too-long-lines in long, long, long doubles/mocks in rspec specs, which is a separate problem of its own.
We run rubocop (including a handful of our own custom cops for enforcing US-english spelling, and some specific "remember to use a transaction here") only on changed files (using codeclimate)
That means as we gradually touch more and more of our older code, we slowly enforce the styleguide.
We don't run a lot of custom configs globally (none, I think) and disable selective overzealous cops on specific lines, or blocks.
Some notable annoyances are `def Something()` which is named this way to model it after the coercions in Kernel, which rubocop complains about because of the pascal casing, and a couple of cases of too-long-lines in long, long, long doubles/mocks in rspec specs, which is a separate problem of its own.
One option that's worked well for us was using rubocop's `--auto-gen-config`. This creates a specific ignore/TODO list on a per file basis.
I'm fairly new to Ruby after having many years of Python and JS experience. One of the most annoying things I find with Rubocop is it asks me to break every 5-10 lines or so into a separate method by default. I mean, Ruby is not a particularly verbose language, so I don't understand why a linter will encourage people to break non-reusable details that are only a couple of lines long into separate methods. I mean, if I have to jump around half a dozen different methods and classes every time I look at a method, does it really help comprehension at all? Do Rubyist really write code like this as a second nature?
Personally, I mostly set the length to 15 lines because too often 10 lines maximum just doesn't work in real life codebases
> Do Rubyist really write code like this as a second nature?
In my opinion yes, only the "old timers" that came from some other technologies write these annoyingly long methods (with many temp variables) and then they "wine" about rubocop.
> I mean, if I have to jump around half a dozen different methods and classes every time I look at a method, does it really help comprehension at all?
If you have to jump around, then the method names were chosen badly.
> Do Rubyist really write code like this as a second nature?
In my opinion yes, only the "old timers" that came from some other technologies write these annoyingly long methods (with many temp variables) and then they "wine" about rubocop.
> I mean, if I have to jump around half a dozen different methods and classes every time I look at a method, does it really help comprehension at all?
If you have to jump around, then the method names were chosen badly.
I would ask if you're doing Ruby, or object oriented design? Because the first rule of SOLID is Single-Responsibility, and there is this great concept frequently repeated in the OO design circles of Ruby conference talks, "I just want to send a method to an object." I can't say for sure that your method longer than 5 lines is breaking this rule, but if I was a betting man, I'd bet it's breaking one of those rules.
Check out sandi-meter, something much simpler than Rubocop, but also includes this rule about 5 lines method length limit. Maybe you know Sandi Metz, and if you do, maybe you haven't heard of the "Sandi Metz Rules" from POODR; rule number two is "more than 5 lines" – my favorite rule is "controllers with more than one instance variable."
https://github.com/makaroni4/sandi_meter
The great thing about this tool as opposed to RuboCop is that one thing should be really clear when you start using it on an existing code project... the way to interpret the big red spot on your chart is NOT that you should go out and change those things immediately to conform to the new rules.
I understand why you want one instance variable per controller, as the job of a controller is really straightforward, if it only exposes a RESTful interface to a single class of objects, but the more specialized features and bolt-ons it accumulates, the less straightforward it will be to understand and refactor the controller code. But when you're taking an existing controller and adding a new feature to it, the right abstraction to use is probably not obvious until you've spent some time with the idea of the feature, maybe tried out a few different implementations.
For a lot of this stuff, when it clicks, you get it, but before then it seems like these rules have no purpose and it doesn't benefit you to follow them blindly. It pays to know when a rule is important, and when you can safely ignore it.
So, what I would say in response to your question is that simply breaking the method in two is not necessarily the refactor that is suggested by the rules of OO design. You should go back to the principles and try to figure out why that method is longer than 5 lines, and what else about the class has resulted in methods that are so long; is it related to having broken one of the more fundamental rules of design, and is it likely to present an obstacle to later change? (Or is this method never likely to change, and you should just ignore it because... it's fine! This is often the answer.)
Maybe you wrote this method to honor some complicated scheme of ideas, that are really separate ideas, and maybe they should be extracted into separate classes so that it's easier to validate changes to the ideas when it's time to change those business rules. (Or, maybe none of that is true, and they should really be kept in one place because how else are you going to understand all the rules and interactions between them, than by having them together) – Chances are good, though, that the code has broken one of the more fundamental rules, like Open/Closed or Dependency Inversion, and that there is a way to make the method simpler without compromising readability. Maybe there are some heavy calculations that are done inside of the method, and it would be better for DRY to extract them into another method that has a descriptive name, and simply lives nearby.
POODR is a great read I'm told; Refactoring is also an important reference work, and if it's too dry for direct consumption, there are great adaptations that will help get you up to speed on code smells and remediation strategies like https://refactoring.guru
Check out sandi-meter, something much simpler than Rubocop, but also includes this rule about 5 lines method length limit. Maybe you know Sandi Metz, and if you do, maybe you haven't heard of the "Sandi Metz Rules" from POODR; rule number two is "more than 5 lines" – my favorite rule is "controllers with more than one instance variable."
https://github.com/makaroni4/sandi_meter
The great thing about this tool as opposed to RuboCop is that one thing should be really clear when you start using it on an existing code project... the way to interpret the big red spot on your chart is NOT that you should go out and change those things immediately to conform to the new rules.
I understand why you want one instance variable per controller, as the job of a controller is really straightforward, if it only exposes a RESTful interface to a single class of objects, but the more specialized features and bolt-ons it accumulates, the less straightforward it will be to understand and refactor the controller code. But when you're taking an existing controller and adding a new feature to it, the right abstraction to use is probably not obvious until you've spent some time with the idea of the feature, maybe tried out a few different implementations.
For a lot of this stuff, when it clicks, you get it, but before then it seems like these rules have no purpose and it doesn't benefit you to follow them blindly. It pays to know when a rule is important, and when you can safely ignore it.
So, what I would say in response to your question is that simply breaking the method in two is not necessarily the refactor that is suggested by the rules of OO design. You should go back to the principles and try to figure out why that method is longer than 5 lines, and what else about the class has resulted in methods that are so long; is it related to having broken one of the more fundamental rules of design, and is it likely to present an obstacle to later change? (Or is this method never likely to change, and you should just ignore it because... it's fine! This is often the answer.)
Maybe you wrote this method to honor some complicated scheme of ideas, that are really separate ideas, and maybe they should be extracted into separate classes so that it's easier to validate changes to the ideas when it's time to change those business rules. (Or, maybe none of that is true, and they should really be kept in one place because how else are you going to understand all the rules and interactions between them, than by having them together) – Chances are good, though, that the code has broken one of the more fundamental rules, like Open/Closed or Dependency Inversion, and that there is a way to make the method simpler without compromising readability. Maybe there are some heavy calculations that are done inside of the method, and it would be better for DRY to extract them into another method that has a descriptive name, and simply lives nearby.
POODR is a great read I'm told; Refactoring is also an important reference work, and if it's too dry for direct consumption, there are great adaptations that will help get you up to speed on code smells and remediation strategies like https://refactoring.guru
I appreciate this detailed response, but I'm afraid if it takes an essay to respond to a simple question of "why break out if more than 5 lines", and the reader with 15 years of programming experience who's well-versed in half a dozen general purpose prog langs still haven't got a clue after reading it, it suggests to me that this is cargo-cult programming.
Ruby is not the first language that has OOPish constructs, but no one else tells devs they are probably writing bad code if they need more than 5 lines of code in a method. I mean, what's wrong with a controller methods that just splits into 2 branches based on the existence of a param, and creates a model and save it to the DB? The entire method will consist of around 20 lines of code. There's no instance variable, no cache and no error handling whatsoever. Do Rubyist get a headache after reading 5?
I'm all for OOP but there seems to be quite some amount of OOP BS around, especially in the Ruby community.
Ruby is not the first language that has OOPish constructs, but no one else tells devs they are probably writing bad code if they need more than 5 lines of code in a method. I mean, what's wrong with a controller methods that just splits into 2 branches based on the existence of a param, and creates a model and save it to the DB? The entire method will consist of around 20 lines of code. There's no instance variable, no cache and no error handling whatsoever. Do Rubyist get a headache after reading 5?
I'm all for OOP but there seems to be quite some amount of OOP BS around, especially in the Ruby community.
Is it a method that's longer than 5 lines, or is it a method that is longer than 50? Because one of these things I could see being easily explained away without haranguing, but the other one is what I deal with on my team on a regular basis.
The point I was trying to make isn't that your methods shouldn't be longer than 5 lines, it's that they should be single-responsibility and descriptively named, like the well-designed classes they inhabit.
The 50+ line method which mixes query and command behaviors indiscriminately is the problem. The 5 line method rule is simply one possible distance to the goalposts (and you are free to move the goalpost, no bullshit intended!)
The point is not that methods should be 5 lines or less, full stop. The point is that people who are in the habit of writing methods that are above (threshold value X) ... and leave it this way, boilerplate and all, then spam the same 50 lines everywhere, except on Tuesday when it looks like this other variant... are perhaps contributing to some kind of a trouble state that should trigger at least a second glance whenever your process has you get around to doing code reviews. It's likely one of the same reasons you or your team has reached for this tool to begin with.
If the effect of implementing the tool into your process is that people are still squeezing command and query ideas that don't belong together into the same method, now in fewer lines than ever before, then it's not having all of the desired effect and it sounds like there is still a conversation that needs to happen about what is a good and bad design for a method.
I'm not saying that your personal boilerplate is wrong, (but I am suggesting it might be, based on a metric that is easy to compute.)
It's a tool that you use to identify symptoms of a problem. The symptoms are not the problem, and they may not even be indicative of any real problem. Sometimes you get a sniffle.
The point I was trying to make isn't that your methods shouldn't be longer than 5 lines, it's that they should be single-responsibility and descriptively named, like the well-designed classes they inhabit.
The 50+ line method which mixes query and command behaviors indiscriminately is the problem. The 5 line method rule is simply one possible distance to the goalposts (and you are free to move the goalpost, no bullshit intended!)
The point is not that methods should be 5 lines or less, full stop. The point is that people who are in the habit of writing methods that are above (threshold value X) ... and leave it this way, boilerplate and all, then spam the same 50 lines everywhere, except on Tuesday when it looks like this other variant... are perhaps contributing to some kind of a trouble state that should trigger at least a second glance whenever your process has you get around to doing code reviews. It's likely one of the same reasons you or your team has reached for this tool to begin with.
If the effect of implementing the tool into your process is that people are still squeezing command and query ideas that don't belong together into the same method, now in fewer lines than ever before, then it's not having all of the desired effect and it sounds like there is still a conversation that needs to happen about what is a good and bad design for a method.
I'm not saying that your personal boilerplate is wrong, (but I am suggesting it might be, based on a metric that is easy to compute.)
It's a tool that you use to identify symptoms of a problem. The symptoms are not the problem, and they may not even be indicative of any real problem. Sometimes you get a sniffle.
> The point is not that methods should be 5 lines or less, full stop.
But that's what a linter does! It just blindly says that shit is wrong. Linters should only emit warnings that people definitely should fix otherwise people stop paying attention and all the useful checks become just noise.
But that's what a linter does! It just blindly says that shit is wrong. Linters should only emit warnings that people definitely should fix otherwise people stop paying attention and all the useful checks become just noise.
I'm not saying that this rule is the most beautiful rule, or that you're a bad person if you write methods that are longer than 5 lines and don't get permission from a senior architect first. That's something dysfunctional teams might do.
Look at `--auto-gen-config` because you can totally still use rubocop on codebases that have loads of pre-existing violations in them without fanfare. Then each new violation needs a second look, and an addition in this file. And if the rule is too restrictive, you can change the default away from 5 lines to some bigger number. The principle I hope (Rubocop hopes) you will accept is that short methods are easier to understand than long methods, so shorter methods should be preferred, at least absent other pressures... that's all. The point I guess is to establish a standard, and then iterate on it.
I don't want to start name calling, but Sandi does this talk where she starts out "who knows code smells" and everyone puts their hand up, then she says "who can name 5 code smells" and all the hands go down. Watching this talk was eye opener for me.
Can you write a program that is well organized and doesn't have methods longer than 5 lines? I don't know if I can. Does that mean the metric is bad and should be thrown away without looking back? I'm not ready to go that far, I want to learn more and know how to make this possible, because Sandi and many others with 30+ years experience in OOP have taken time out from their busy day to suggest that it will result in more maintainable code for my team.
There is a big difference between cargo culting and listening to learned experience projected outwardly.
Edit: https://www.youtube.com/watch?v=PJjHfa5yxlU This is the talk about code smells! "Get a Whiff of This" by Sandi Metz, RailsConf 2016
Look at `--auto-gen-config` because you can totally still use rubocop on codebases that have loads of pre-existing violations in them without fanfare. Then each new violation needs a second look, and an addition in this file. And if the rule is too restrictive, you can change the default away from 5 lines to some bigger number. The principle I hope (Rubocop hopes) you will accept is that short methods are easier to understand than long methods, so shorter methods should be preferred, at least absent other pressures... that's all. The point I guess is to establish a standard, and then iterate on it.
I don't want to start name calling, but Sandi does this talk where she starts out "who knows code smells" and everyone puts their hand up, then she says "who can name 5 code smells" and all the hands go down. Watching this talk was eye opener for me.
Can you write a program that is well organized and doesn't have methods longer than 5 lines? I don't know if I can. Does that mean the metric is bad and should be thrown away without looking back? I'm not ready to go that far, I want to learn more and know how to make this possible, because Sandi and many others with 30+ years experience in OOP have taken time out from their busy day to suggest that it will result in more maintainable code for my team.
There is a big difference between cargo culting and listening to learned experience projected outwardly.
Edit: https://www.youtube.com/watch?v=PJjHfa5yxlU This is the talk about code smells! "Get a Whiff of This" by Sandi Metz, RailsConf 2016
I will say also that I have >15 years of experience programming in different languages and I've only felt a need to reach for these design concepts in the last 2.
Please don't feel like I'm talking down to you. We are the same. I don't even use these tools, and my methods are very often too long.
Please don't feel like I'm talking down to you. We are the same. I don't even use these tools, and my methods are very often too long.
Ruby is one of the few languages optimized for developer happiness. It consciously makes tradeoffs in favor of that primary purpose. It is natural to expect a focus on the developer experience among its users, such as ensuring code is highly readable (as embodied in the short method reasoning). I do think some developers become overzealous and do sometimes overstate Ruby's features.
I cannot possibly imagine how every method of more than five lines is doing more than one thing.
Heck, I've got plenty of places in my code base where a 100+ line method is absolutely doing a single thing.
Heck, I've got plenty of places in my code base where a 100+ line method is absolutely doing a single thing.
After spending some time to think about your reply, and watching an OO talk or two, I have a clearer way to state why your statement is unlikely to be true in context. I am not an OO "seer" or visionary, I don't mean to say you are broadly wrong, but in the framework of OOD and SOLID, I think that 100+ line method is almost definitely not just doing a single thing.
The Single Responsibility Principle is said to cover all the reasons why a class might need to change. There should be only one reason why a class changes – its single responsibility is that reason. That's for an entire class. Your method lives in the class, so get out your class and read down, method by method and line by line.
Ask yourself periodically while you do this, "can this line of code ever change, in some future state of development?" and "what are the reasons it might change?" – this is not a value judgement, I am just saying that I think by the time you get to the bottom of the method, you'll find the list has decidedly more than one distinct entry in it. (Maybe you don't, and in that case you could have a thing or two to tell me about how you made it that way... please be sure I'm not claiming superiority, especially given that I haven't actually read your code!)
Object Oriented Design is all about managing software change, and making change easy. Your 100+ line method is perhaps not easy to change (and validate.) Maybe it is only called by one other line of code anywhere, and my concerns are ill-founded! It does the same thing every time, and it's just one thing, even though it takes a while and perhaps has many un-named steps.
But if you can think of more than one reason for that method and the class it lives in to need to be changed, then the principles of OOD may say you have run afoul of the S in SOLID, and should maybe reconsider.
One of the things I think we all have a hard time coming to grips with is this maybe reconsider – just because you have identified a code smell, doesn't mean you should fix it! There might be (definitely is) more than one way to fix it, there's also a good chance it might never need fixing.
The Single Responsibility Principle is said to cover all the reasons why a class might need to change. There should be only one reason why a class changes – its single responsibility is that reason. That's for an entire class. Your method lives in the class, so get out your class and read down, method by method and line by line.
Ask yourself periodically while you do this, "can this line of code ever change, in some future state of development?" and "what are the reasons it might change?" – this is not a value judgement, I am just saying that I think by the time you get to the bottom of the method, you'll find the list has decidedly more than one distinct entry in it. (Maybe you don't, and in that case you could have a thing or two to tell me about how you made it that way... please be sure I'm not claiming superiority, especially given that I haven't actually read your code!)
Object Oriented Design is all about managing software change, and making change easy. Your 100+ line method is perhaps not easy to change (and validate.) Maybe it is only called by one other line of code anywhere, and my concerns are ill-founded! It does the same thing every time, and it's just one thing, even though it takes a while and perhaps has many un-named steps.
But if you can think of more than one reason for that method and the class it lives in to need to be changed, then the principles of OOD may say you have run afoul of the S in SOLID, and should maybe reconsider.
One of the things I think we all have a hard time coming to grips with is this maybe reconsider – just because you have identified a code smell, doesn't mean you should fix it! There might be (definitely is) more than one way to fix it, there's also a good chance it might never need fixing.
Here, this is the talk where the justification and case is made for the "cap your classes at 100 lines" and other 4 rules: https://www.youtube.com/watch?v=npOGOmkxuio
Your use of the word "every" makes me believe that I have not made my point clearly. I will try to restate it in less than 5 lines so that it can be understood better. (Zing!)
I'm not saying that your code is wrong, (but I am suggesting it might be, based on a metric that is easy to compute.)
It's a tool that you use to identify symptoms of a problem. The symptoms are not the problem.
I'm not saying that your code is wrong, (but I am suggesting it might be, based on a metric that is easy to compute.)
It's a tool that you use to identify symptoms of a problem. The symptoms are not the problem.
A related thread from 2015: https://news.ycombinator.com/item?id=9162711
Since the project hasn't been discussed much on HN, we changed the URL from https://github.com/rubocop-hq/rubocop/releases/tag/v0.80.0 to the project page.
Since the project hasn't been discussed much on HN, we changed the URL from https://github.com/rubocop-hq/rubocop/releases/tag/v0.80.0 to the project page.
Thanks, much appreciated! (RuboCop's author here)
Takes the prize for best open source project name (and logo). FWIW I was a huge Robocop fan as a child. It’s filled with fantastic one liners: “Dead or alive, you are coming with me.” “I’ll buy that for a dollar.” “Serve the public trust, protect the innocent, uphold the law.” “Who cares if it works or not? Spare parts for 25 years!”
I love it because it brings some order to a meta-everything world, but it'd be nice if it came with a reasonable set of rules by default