Good Tooling educates: Credo 0.1.0 released

TL;DR Credo is finally out. Get it via Hex and on GitHub.

Last week I wrote a blog post asserting that one of Elixir’s strength is tooling which teaches people rather than blame them. Like this:

#Elixir-lang error messages ftw. Politely points out my error and suggests the correct fix #MyElixirStatus pic.twitter.com/2H4VF5Emej — Jonathan Mundy (@JonathanMundy) November 15, 2015

I want to emphasize why teaching is such an important part of Elixir’s future. Clark described the point we’re at best in his recent post “Elixir is not Ruby”:

Elixir’s recent rise from “totally unknown” to “still definitely unknown but mentioned in hushed tones” […]

It’s not obvious most of the time, but we are still an extremely young community and as such we are still capable to shape how we interact with each other and what the overarching motives should be. It is easy to be an Alchemist and say “This is so much better than what I used in <my-current-primary-language> …” What we should not resort to is saying “Let’s all hope those &%#!? - sorry - I mean code ninjas from the <language-i-don’t-like> community stay away from Elixir”.

I felt the urge to think this way once or twice in my short Elixir career. But that is not the path our rainbow-blessing overlords have foreseen for us. They teach us love and understanding in the form of the five hearts.

Admittedly, there’s always the option to treat coders with mislead egos and inferior qualification as second grade programmers. But how about we teach them how to write better code instead of just spouting “YOU’RE WRONG”?

Maybe "you are wrong" is enough for talented singers and developers. It is really far from enough for the majority of us. We need guiding. — José Valim (@josevalim) November 2, 2015

This is why I developed Credo, the first teaching code linter for Elixir.

Credo analyses your code and makes suggestions how to improve it. It also explains the issues it finds in plain English, showing examples of good and bad coding practices.

The idea here is to treat the programmer in front of the screen as a human being. Instead of a dogmatic approach, Credo expects to find issues and is aware that not all issues are created equal:

It provides context by putting them into semantic categories (Consistency, Code Readability, Software Design, Refactoring Opportunities, and Warnings).

(Consistency, Code Readability, Software Design, Refactoring Opportunities, and Warnings). and also assigns dynamic priorities to each issue it finds. By default, it only displays the important ones (but you can of course (a) customize the priorities and (b) display all issues if you like).

To make this clear: Credo finds issues in all of my code including Credo itself. And I won’t fix all of them just for the sake of some tool telling me “you did good”. But I will use Credo as an intelligent tool to help me make informed decisions, because that is its purpose.

And this is where the explain feature becomes important:

It helps me reason about whether or not I should change my code because it shows me ways in which I might benefit from doing so and also lists reasons why I might want to ignore it.

This announcement got a bit wordy, so let me finish by stating the obvious: