RuboCop – A Ruby static code analyzer | Hacker News Reader

RuboCop – A Ruby static code analyzer

batsov.com

125 pointsmatugm38 comments

Rubocop is an absolute pleasure to work with, but it also helps that the ruby community seems to have a more widely-agreed upon style guide than other communities (Javascript comes to mind). There are similar tools for Javascript, and I imagine many of them are configurable as well to cover most use cases. But with the diversity of Javascript style guides and the lack of cohesiveness in the js community, it seems unlikely that many of these would be as useful as rubocop 'out-of-the-box'.

It would be amazing if a similar static code analysis tool existed with settings to conform to the most popular javascript style guides: npm, idiomatic, jQuery, etc. But even within these style guides there is a lot of 'undefined behavior', or situations that aren't explicitly described in the guides.

This is starting to pick up steam in the node community, and represents the coding style of a vast percentage of core and popular npm modules: https://github.com/feross/standard

It's not configurable, is a drop-in executable tool and supports a --format option which will attempt to reformat your code. To me it seems to be inspired by gofmt.

Looks pretty cool, but it supports a very limited set of styles. It's not really comparable to rubocop, nor is it able to enforce conformance to any of the popular style guides in full. In fact, at a glance it appears to make decisions about your code that fly in the face of many of the popular style guides (double spaces for indentation and no freaking semicolons [seriously?]).

The auto-formatting option does not clarify which of these it enforces, and one of these isn't even a style rule (always handle the err parameter in node.js).

To really rub it in, it also makes it very clear that there is no configuration! Deal with it in a way that strikes me as uncomfortably smug.

I appreciate you sharing, and I could see this being useful for running over a codebase. I might use it to convert all tabs to double spaces (since that's my preference anyway) and check to make sure there are no unused declared variables, but that might be the extent of it. But to be honest, reading the documentation here has made me really want to see a community-developed tool inspired by Rubocop.

That there is no configuration is kind of the point. Close the door on the bike shed and attempt to popularize a conventional style.

If you want more control, use ESlint or jslint or jshint and define your own rules.

The problem is this is incompatible with the current state of the JS ecosystem. NPM packages need to follow the npm style guide (though standard appears at a glance to be closer to this than anything else). jQuery modules need to follow the jQuery style guide. Many projects may already use another style guide. A large chunk of open-source javascript follows a style guide that standard is incompatible with, and new projects often have to adhere to the style guide of the platform they target as well. It would be much more useful to have a code analysis and correction tool that could enforce the rules of a target style guide.

Looks cool except for the no semi colons thing. The first time I spend fifteen minutes searching for why this weird bug was happening only to realize it was because of ASI, that shit is going in the trash.

The style is best suited to server-side code where source minification is not an issue and you can enjoy the full language.

Apparently it will catch the edge cases for you.

https://github.com/feross/standard/issues/5#issuecomment-716...

Is not it a standard yet? That's a well known tool used by thousands of projects..

Working link to the real thing http://batsov.com/rubocop/

Thanks. URL changed from http://www.blackbytes.info/2015/03/rubocop-guide/.

Submitters: HN prefers original sources. https://news.ycombinator.com/newsguidelines.html

I'm a casual ruby programmer (I only use it to write "powerful bash scripts") and have been using rubocop with vim/syntastic.

The attention to detail is incredible, which I'm not sure if I like or not, since it usually feels like I have someone nitpicking about the style of my quick scripts.

I've been learning a lot about ruby standards though.

Is "static code analyzer" the new spelling for lint(1)?

https://www.freebsd.org/cgi/man.cgi?query=lint&sektion=1

I've always been a big fan of code linters. They may not be perfect, but any bug you can catch at compile-time (or earlier) could be saving you hours of trying to track down runtime problems. In languages with a managed runtime such as ruby where you don't really have the same kind of compile-time checking, a good linter is even more important.

It was a pretty crazy day when I first found RuboCop. I immediately used it on the large amount of ruby I've written over the last ~decade.

Is there a way to have RuboCop automatically clean up things it detects? Obviously I would run this one file at a time, and git diff it before committing it.

The -a flag will do this for some of the offenses.

https://github.com/bbatsov/rubocop/wiki/Automatic-Correction...

Rubocop organizes violations into a set of distinct 'cops', each of which is responsible for checking for a single type of style violation - about half of them can be autocorrected (--auto-correct argument from the command line).

Rather than running it one file at a time, I found that I got an easier to inspect diff by running it one cop at a time. Rubocop simplifies this approach by allowing you to auto-generate a '.rubocop_todo.yml' file that specifies settings for every 'cop' that would allow your project to produce no warnings. Then you just remove one section of config at a time, autocorrect or manually correct all the errors that pop up, and make a commit describing what style change it introduced across the project. In the process, you also gain a full understanding of really what is required by the cops - there are a couple that I have tuned to be more relaxed than the default, because the defaults seem silly (like cyclomatic complexity, and method length).

I found it was cleaner to run it with -a (autocorrect) enabling one cop at a time between commits. Less giant patch storm of everything, and more coherent changesets.

At GitLab we recently implemented this in our tests. After this all the reminders and comments about style are no longer needed. You just need to have green tests as you always should. We think having it in CI is a much better experience than a HoundCI that makes line comments in the merge request, that gets quite noisy for people following the MR.

Do you have some code to make it a spec by chance? I've been thinking about doing that.

A link to the settings we use is here https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.rubocop... it is pretty loose since we recently implemented it and didn't want to have to fix 1600 files :)

For more than just Ruby, as well: https://houndci.com/

For Ruby Hound is using RuboCop under the hood, but still it is interesting the way it automatically integrates with GitHub to check pull requests.

One thing to note when using HoundCI, the defaults have been configured to ThoughtBot's style, slightly straying away from the 'defaults' that RuboCop has.

I highly recommend it's use with pronto. We run Rubocop, Rails Best Practice and Brakeman against every commit by calling pronto from CircleCI.

https://github.com/mmozuras/pronto

Absolutely amazing tool, always part of my CI build for Ruby projects.

Even though in a lot of cases I don't care as much about the style used per se, it's a treat to have a consistent coding style in projects with multiple team members.

Integrate with GitHub review comment not only RuboCop but also eslint, jscs, and any lint. https://github.com/packsaddle/ruby-saddler

RuboCop is amazing. I use it in Sublime via https://github.com/pderichs/sublime_rubocop

I love how it integrates with text editors (textmate, atom) so well. There's no need to wait for your CI to tell you you're doing something wrong.

Was not aware of this. Many thanks!

We are big fans. Use it on our projects in conjunction with Rspec, Capybara, and Jasmine to test CircleCI-based deploys.

So what is it, a static code analyzer or a style checker?

AFAIR it's more of a linter ("unreachable code after an end" or "assignment in condition") than a static analyzer a-la findbugs ("X might be null here" or "access to a field before initialization").

Yeah, that's right. Unfortunately different people put different meaning into "static analyzer". Obviously linting is also done via static analysis of the code.

A great tool to create a healthy debate about nothing, while the world changes unnoticed beneath you.

RuboCop's author here. If I knew someone would ever link to the homepage I would have put some useful info in it. :-)

Thanks for the kind words!

P.S. There's a lot more info here https://github.com/bbatsov/rubocop

bozhidar also is the maintainer of CIDER [1] for Emacs + Clojure. It's the most popular way to use Clojure.

[1] https://github.com/clojure-emacs/cider

Guilty as charged. :-)

Reply on news.ycombinator.com