GitHub has been a revolution for developers. You could consider SourceForge a predecessor, in the sense that it also let people share code. But GitHub it’s not simply a place where you can download programs, it’s mainly a platform for developers. One thing that GitHub has brought is integrations, of which there are many. The most famous is probably Travis and, of course, there are many other services for continuous integration. There are also other integrations, such as the ones with messagging apps, which are useful, but less obvious. Though today we talk about a code-related one, but less known: Code Climate, a service for static analysis.

Static analysis as a service

CodeClimate integration in GitHub

We have mentioned static analysis when we talked about Roslyn, but this service deliver it. Although it doesn’t cover C#, which should probably be a crime. Following the lead of GitHub, it’s also free for open-source, but it costs for businesses. This is a successful model that is also followed by Travis and AppVeyor, which have become synonymous with CI on Linux and Windows, and, among other things, Walkmod, another tool that can modify your code to your liking.

You can hook the service to your pull requests, but there is also a local version, that use a docker image of the CodeClimate CLI. Which is great if you don’t want to wait for pushes to check your code. You can easily integrate the JSON output can be with other tools you use. On the other hand, if you find a use for such a service you don’t really want to manage it yourself. And you really want to check the code of everybody, and not just yours. After all, they created it for GitHub, where developers works together.

It seems to hate Javascript developers

Code Climate explanation
An example of a problem found by the Code Climate analysis

The service itself seems to relay on libraries developed by other people. There is nothing wrong per se in that, of course, there is tremendous value in offering a service. And leveraging the works of everybody allows them to check for everything from bugs, security risk, excessive complexity, style, linter, etc. and basically everything you can image, they can also check Chef cookbooks and bash scripts. People that have a not-developed-here attitude can’t do that. Though the drawback is that there is a lack of uniformity in analysis and judgement between different languages. If you look at their Open Source Section, it seems that every Javascript project is judged harshly: Bootstrap, jQuery, node, etc. Of course I haven’t checked everything, but the only one that seems to be good is D3. While if you look at Ruby instead, and at Jekyll or Rails

It may be that Javascript developers are all terrible, but that seems unlikely, more probably there are differences in the tools that focus on Javascript and other kinds of languages. There might be legitimate concerns, maybe because Javascript is used in a different way. Rules exists to help you create good software, but if the best programmer ignored them, are actually good rules? Are rules that can be followed without killing productivity ? While this is a great way to humble everybody, the risk is that many warnings will soon become ignored warnings, after all if everything sucks, why bother ? We all know the story of The Boy Who Cried Wolf. So you have to careful and take your time to configure it in a way that works for your project.


If you are searching for a tool to verify the quality of your code you might want to use CodeClimate, especially if you are working on open source software with many other people. Although if you use Javascript be aware that it might tell you that everything you do is wrong.