Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RuboCop 0.80: Ruby static code analyzer and code formatter

docs.rubocop.org

Post reply on HN
Print view View original

31–40 of 54 posts

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#31

Post by UncleMeat »

yebyen wrote: post #13
wyuenho wrote: post #7

Earlier quoted context omitted.

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 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. Ch…

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.

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#32

Post by UncleMeat »

yebyen wrote: post #18
wyuenho wrote: post #16

Earlier quoted context omitted.

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, b…

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-des…

> 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.

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#33

Post by yebyen »

UncleMeat wrote: post #32
yebyen wrote: post #18

Earlier quoted context omitted.

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-des…

> 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.

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

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#34

Post by yebyen »

UncleMeat wrote: post #31
yebyen wrote: post #13

Earlier quoted context omitted.

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. Ch…

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.

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.

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#35

Post by 22c »

phaedryx wrote: post #6
StaticRedux wrote: post #2

In my opinion RuboCop is too strict. Every code standard analyzer takes some tweaking to get it set up for a particular project and team standards, but RuboCop needs changing of a ton of rules to make it even usable in a reasonable fashion. 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

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?

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...

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#36

Post by sbaha88 »

phaedryx wrote: post #6
StaticRedux wrote: post #2

In my opinion RuboCop is too strict. Every code standard analyzer takes some tweaking to get it set up for a particular project and team standards, but RuboCop needs changing of a ton of rules to make it even usable in a reasonable fashion. 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

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?

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

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#37

Post by joeframbach »

sbaha88 wrote: post #36
phaedryx wrote: post #6

Earlier quoted context omitted.

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?

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.

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#38

Post by hirundo »

22c wrote: post #35
phaedryx wrote: post #6

Earlier quoted context omitted.

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?

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…

I prefer the brackets to parens because it makes it more clear at a glance that the result is an array.

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#39

Post by hirundo »

yebyen wrote: post #4
StaticRedux wrote: post #2

In my opinion RuboCop is too strict. Every code standard analyzer takes some tweaking to get it set up for a particular project and team standards, but RuboCop needs changing of a ton of rules to make it even usable in a reasonable fashion. 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

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…

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.

Re: RuboCop 0.80: Ruby static code analyzer and code formatter

#40

Post by yebyen »

hirundo wrote: post #39
yebyen wrote: post #4

Earlier quoted context omitted.

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…

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.

Post reply on HN