In the previous part of this series, I focused on the tools that in my opinion are required to be used in every project as a vital component of the continuous integration process. In this article, I will present a few tools that can improve code located in assets and views directories.

When you do a lot of changes in your codebase, you may sometimes forget about redundant variables, shorter syntax equivalents or things that might be simply stripped without harming your code. This is what linters for are.

Polishing JavaScript

If your project contains Vanilla JavaScript, you should consider using JSLint. However, when you are using modern JS features (ES6/ES2015) ESLint is the right tool for the job.

On some projects, you can still find some CoffeeScript code. Of course, the community have covered this case as well — just use the appropriate gem — CoffeeLint.

Sample usage

The usage of all linters is pretty straightforward (CoffeeLint example):

$ bundle exec rake coffeelint

If you like to have it in your CI:

before_script: - bundle exec rake coffeelint

You can always find more details in the repository of each linter.

Help my with my stylesheets

The World is not perfect and sometimes you have to deal with styles in your application (even if you love to call yourself just a backend developer). So if you have to write some styles, why not do it as well as possible?

Polishing code by example

The approach to solving the issue depends on your stylesheets “stack” — you follow a similar scenario as with Javascript linters. Writing plain CSS seems to be deprecated so I would recommend some other popular use cases. The first one: SCSS Lint, and the second SASS Lint.

Lint view files

Similar solutions are available for view files. In case of HAML views, you can use HAML Lint. If you prefer to use slim, you can pick Slim Lint. A similar solution is available for “classic” *.erb files: ERB Lint.

Conclusion

Linters provide suggestions on how to code better. This type of tools is especially valuable for less experienced developers, who can learn some good practices without a lot of the QA developer involvement. The time that you save using the tools can be spent on learning more sophisticated things. However, it does not mean that you should always follow every single suggestion from linters. Those tools are very customizable and should always be adjusted to fit in with the team preferences.