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.
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.
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.
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.
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.
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.
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.
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.
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.