5 ms·

The issues raised here completely align with my problems with Rubocop. It seems that a lot of people think that one of the main goals for code linting is consi

• drewcoo 6y ago
  The point of linters is that most of us can imagine up more interesting problems to deal with. So we welcome the consistency and focus on something we care more about.
  • wlll 6y ago
    > The point of linters is that most of us can imagine up more interesting problems to deal with. I wasn't saying that linters were a problem, I was saying that the over application of linters was a problem. In general, overly broad application of a tool is a problem, wether in programming or not. Linting is a tool, it is possible to over apply it, and I argue that this is regularly done with Rubocop. > So we welcome the consistency and focus on something we care more about. What is the goal of consistency?
    • kryogen1c 6y ago
      >What is the goal of consistency? i don't know anything about linters or rubocop, but i do think you are wrong on this narrow point. consistency is good in and of itself, it is not merely a symptom of your true goal of maintainability or readability as you mention in op. id prefer someone/something that is consistently wrong to someone/something that is more often right, but randomly wrong. consistency implies methodology that can be changed and adapted, as opposes to simple mistakes that have to be assiduously monitored for. you can train a person into a different habit and refactoring is much easier than bug hunting.
      • ryanbrunner 6y ago
        The thing is, for probably a good majority of Rubocops rules, the consistency has nothing to do with correctness, it's consistency for the sake of consistency. Whether you use ' or " for strings, or the %d shorthand or fully formed arrays in Ruby has nothing to do with the correctness of your code. When these are trivial, it's not such a big deal - perhaps a bit of friction for developers, but not in a way that slows them down significantly. Rubocop does occasionally get into style rules that can change what your code is trying to communicate though, and those can often have negative effects.
      • wlll 6y ago
        > consistency is good in and of itself It can't be, because consistency is only a concept with no intrinsic value. The value is based on the relationship between the concept and the application. You can say "consistency in code is good" or "consistency in code is bad", but then you've made an argument and you need back that up with reason. > id prefer someone/something that is consistently wrong to someone/something that is more often right, but randomly wrong. Just to be clear, we're not talking about bugs here, we're talking about style where there's, sometimes subjectively, "better" or "worse" more often than "right" or "wrong". > consistency implies methodology that can be changed and adapted, as opposes to simple mistakes that have to be assiduously monitored for. Consistency doesn't imply anything of the sort, but if you want to apply consistency to a problem with the goal of being able to change every instance of something you're not really solving a problem, unless your actual goal is consistency, which I argue isn't actually a goal at all.
  • ryanbrunner 6y ago
    I think that can be a dangerous mindset. Code readability isn't a trifling concern that you shouldn't care about in favour of more interesting things, it should be your primary concern as a developer. In almost every circumstance, I'll prefer readable code to something that's more clever, or even more performant. Rubocop and other linting tools do aid in readability somewhat, but I agree that a lot of the time they can either focus on trivial concerns that don't really make a large impact on readability (things like which quote characters to use), and in some cases actively harm readability (the examples from this article). Personally, my feeling on tools like Rubocop is that where they break down is often more important than the areas where they help (high level structure and communicating intent), and often the benefits of consistency in syntax are frankly pretty marginal, but I can get people having different opinions on this. There's certainly Rubocop rules I enable and get value from, but I do have quite a lot turned off and don't really notice much impact from it.
• simias 6y ago
  > I've hit similar issues to those mentioned in the article and it absolutely infuriates me when I have to jump through hoops (or worse, reduce the readability of my code) to push well thought out code that communicates intent, only to fall foul of a robot that doesn't understand nuance. I don't use Ruby but I faced similar issues with Rust's clippy and rustfmt. But I still think it's better than the alternative. Every time I'm tempted to override one of these links/formats because I feel like my way is better I like to remind myself that it's going to set a precedent for the other devs on the project, and it's only a matter of time before one of us does something that the others don't like and it's only a matter of time before we return to pointless arguing about coding style and inconsistent code formatting. >Consistency is merely a tool, the goal should be readability/maintainability. That's the thing though: consistency is somewhat objective (and enforceable), readability and maintainability not so much. TFA is a good example of this: they argue that explicitly returning "nil" is more readable and better communicates intent but I suspect (once again, not being a Ruby coder myself) that other experienced Rubyists could respond that everybody knows that a method finishing without an explicit value ends up returning nil, and that adding explicit code to do is is just clutter and distracts from the important things.
  • wlll 6y ago
    > I don't use Ruby but I faced similar issues with Rust's clippy and rustfmt. But I still think it's better than the alternative. I also use Go, and haven't had issues with the autoformatter there, but I believe that's mostly because there is little to no room for ambiguity around intent. You tell the compiler you want to return a Bool, and if you don't it's a compile time error. There's no "I dunno, maybe nil was an intended return value". > Every time I'm tempted to override one of these links/formats because I feel like my way is better I like to remind myself that it's going to set a precedent for the other devs on the project I think this misses the point somewhat. This isn't about changing the defaults of Rubocop, it's about not having some of those defaults in the first place for the places in Ruby where it's possible to express intent in a way that it's not possible to check with a linter. > That's the thing though: consistency is somewhat objective (and enforceable), readability and maintainability not so much. I'm still not saying that people should not use linters, just because you can lint something doesn't mean you have to lint everything. > TFA is a good example of this: they argue that explicitly returning "nil" is more readable and better communicates intent but I suspect (once again, not being a Ruby coder myself) that other experienced Rubyists could respond that everybody knows that a method finishing without an explicit value ends up returning nil, and that adding explicit code to do is is just clutter and distracts from the important things. Oh, absolutely, most Ruby programmers do know this, but it's not really about the code specifically I think, it's about the contract. Take this code: def foo @some_instance_var = 123 end It turns out that: > a = foo => 123 > a => 123 but you've not actually said that the return value is intended, or a side effect. You've not telegraphed the intent to the consumer of this tiny little API. It looks like returning a is merely something that happens to happen. this leads to uncertainty, guessing and possibly bugs. Take this addition later on: def foo @some_instance_var = 123 @some_other_instance_var = 456 end If someone was (perhapy mistakenly) relying in the return value of foo to be the result of the assignment to @some_instance_var they now likely have a bug. Hopefully tests caught it, but they might not have. We could fix this with (amongst other things): def foo return @some_instance_var = 123 end We now know two things. 1. If we are changing this method we need to respect the return 2. If we are consuming this method we know the return is deliberate This unfortunately violates Rubocop's redundant return detection and will be rejected (as will other forms).
• 3np 6y ago
  Whenever you disagree with Rubocop and want it to shut up: rubocop -a --auto-gen-config --auto-gen-only-exclude Your just added exceptions for the leftovers that didn't pass the initial lint. But obv use this only after you cleaned up anything that should be. -a by itself autofixes anything it knows how to.
  • wlll 6y ago
    Useful, thanks.
• echlebek 6y ago
  The problem is Ruby itself. Implicit return, whether you like it or not, is frankly a weird feature, and is sure to rub some people the wrong way.