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!”
RuboCop 0.80: Ruby static code analyzer and code formatter
21–30 of 54 posts
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#22Earlier 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 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…
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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#23In 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?
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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#24A 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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#25In 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?
‘private’ methods forced to be NOT indented.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#26Earlier 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…
> 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…
> 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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#27Earlier 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 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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#28Earlier quoted context omitted.
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.
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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#29Earlier quoted context omitted.
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 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.
Re: RuboCop 0.80: Ruby static code analyzer and code formatter
#30Earlier quoted context omitted.
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.
It's my default.
On the left buffer I've got the implementation, on the right buffer I've got the spec/test.