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 0.80: Ruby static code analyzer and code formatter
51–54 of 54 posts
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#52In 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
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#53Earlier 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.
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
#54Earlier 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…