RuboCop 0.80: Ruby static code analyzer and code formatter
docs.rubocop.org
docs.rubocop.org
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
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.
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
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.
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.
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.
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
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.
Heck, I've got plenty of places in my code base where a 100+ line method is absolutely doing a single thing.
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.
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.
> 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.
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!)
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
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.
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.
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?
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 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 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.
You don't even know how long these 100 line functions really are! It's abusive, bottom line.
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?
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.
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...
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.