<story><title>My Beef with RuboCop</title><url>https://www.rubypigeon.com/posts/my-beef-with-rubocop/</url></story><parent_chain></parent_chain><comment><author>wlll</author><text>The issues raised here completely align with my problems with Rubocop.&lt;p&gt;It seems that a lot of people think that one of the main goals for code linting is consistency, when that shouldn&amp;#x27;t be a goal at all. Consistency is merely a tool, the goal should be readability&amp;#x2F;maintainability. Consistency is just one tool that is available to us in persuit of that goal.&lt;p&gt;I&amp;#x27;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&amp;#x27;t understand nuance.&lt;p&gt;Don&amp;#x27;t get me wrong, I think Rubocop is a great tool, it&amp;#x27;s just over-used, and that&amp;#x27;s in part because everything is on by default, and this seems to be encouraged by the general community. It seems that once programmers have found a solution to something they love to apply that solution to all places that it will work, regardless of the efficacy.&lt;p&gt;My preference, and I suppose suggestion, is to let Rubocop handle things it knows about with a high degree of accuracy, such as tabs&amp;#x2F;spaces for lead indentation, security issues etc. and leave anything that requires nuance or subtlety to the programmer who wrote it, and the educational opportunity of the code review.&lt;p&gt;After all, &amp;quot;Consistency is the last refuge of the unimaginative&amp;quot; :)</text></comment>
<story><title>My Beef with RuboCop</title><url>https://www.rubypigeon.com/posts/my-beef-with-rubocop/</url></story><parent_chain></parent_chain><comment><author>robotmay</author><text>We use rubocop heavily at GitLab. I&amp;#x27;m generally happy with it, and we have a largely sane set of linters. I think when your codebase gets to a certain size and you have a lot of engineers working on it, having some sane defaults is very beneficial and helps standardise the codebase a bit.&lt;p&gt;Where I think rubocop really shines is in picking up _problem_ code, like potential bugs, performance issues, or errors, in advance. We also use it heavily when deprecating older modules&amp;#x2F;classes, like replacing JSON calls with our own wrapper.&lt;p&gt;It does, however, sometimes suggest something totally bonkers: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;gitlab.com&amp;#x2F;gitlab-org&amp;#x2F;gitlab&amp;#x2F;-&amp;#x2F;issues&amp;#x2F;271570&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;gitlab.com&amp;#x2F;gitlab-org&amp;#x2F;gitlab&amp;#x2F;-&amp;#x2F;issues&amp;#x2F;271570&lt;/a&gt;, but it&amp;#x27;s fairly trivial to skip it. After all, humans should be allowed to say that the linter is wrong and either ignore it or suggest an improvement, and that&amp;#x27;s a process issue rather than a rubocop issue :)&lt;p&gt;Not everyone is going to agree with every cop you enable, but the goal is standardisation rather than appeasing everybody. If something is particularly contentious then I would suggest removing&amp;#x2F;disabling that cop.&lt;p&gt;Every few years at GitLab we do seem to get a singlequotes vs doublequotes cop argument crop up, which is why we (thankfully) still don&amp;#x27;t have any requirement around those. Team doublequotes represent!&lt;p&gt;Edit: Oh and unrelated to the content of the article, but I really like the design and colour palette of the blog.</text></comment>