Live data from Hacker News

RuboCop 0.80: Ruby static code analyzer and code formatter

docs.rubocop.org

51–54 of 54 posts

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

#51

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

This is exactly nice about it. With Rubocop standardrb (https://github.com/testdouble/standard) has a solid foundation to make everyone's live easy.

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

#52

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

RuboCop's author here. On the subject of the defaults - it's extremely hard to come up with something that everyone agrees on. Originally RuboCop didn't have any config options and tried to be something like gofmt, prettier (not that it exist back then), etc, but soon we realized that Ruby has been around for way too long and there are way too many competing coding styles in circulations. Therefore our current approach - support every popular coding style, optimize by default for the community style guide (https://rubystyle.guide/). When it comes to style I think the most important thing is consistency and everything else is secondary to that. More on the subject - https://rubystyle.guide/#a-note-about-consistency

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

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

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.

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

#54
post #53

Earlier quoted context omitted.

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.

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…

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
Post reply on HN