trivelop @rrrene on

Credo and Dogma: A Comparison of Elixir Code Linters

Last week I released Credo, a new static code analysis tool that acts as a code linter, but also focusses on teaching coding practices and code consistency.

The one other code linter for Elixir (that I am aware of) is Dogma. Shortly after Credo's release Louis, Dogma's maintainer, asked me to explain the differences between the two projects.

This is a double-edged sword for me, because I am one of Dogma's main contributors as well, so I am quite fond of it. On the other hand I spent every free moment in the last two months creating Credo. So it won't come as a surprise that I think Credo is the "better" tool in a couple of ways.

So here is my - slightly biased - comparison:

  • The premise of Dogma is that you must use and configure it as a dependency inside your Elixir project and run the Mix task in dev mode (there has been debate about the last part). Credo on the other hand is a static analysis tool: it does not need to be a dependency of the code it analyses and it's configuration is not tied to one of your projects (although you can configure each project individually if you want to).

  • You can use Credo as a dependency inside your Elixir project (out of convenience), but you could also build an escript and point that executable at any other Elixir project directory or file.

  • Dogma has had a variety of formatters from the start, which provides users with an output style that suites their needs. Credo is still lacking in this regard.

  • The main difference - perhaps - is that Credo tries to give the code linting in Elixir an educational spin.

  • This is made possible due to the fact that found issues are categorized and prioritized. So Credo can give you some context on why the found code is problematic. Instead of saying "You're wrong!", Credo can say "Look, you might not want to do that and here's why.".

  • Because Credo assigns a dynamic priority to each issue it finds, not all issues are created equal. Some are even not shown in the default analysis when you run mix credo.

  • This enables a workflow where you see the most relevant issues at a glance and check for less important ones via mix credo -A. Everything around these priorities is, of course, customizable.

So, that's basically it. If you like the ideas presented here, check out Credo on GitHub. Feedback is always welcome!

For a more conventional comparison, here's a table that represents the state of affairs as of this writing:

Credo Dogma
Supported Elixir versions 1.1.x 1.0.x, 1.1.x
Customizable check configuration via parameters
Help for check parameters in CLI -
Different formatters -
Semantic categories -
Dynamic priorities -
Issue severity -
Common style checks for code readability
Giving filename/line/column/call where checks fail / / / / / - / -
Software design suggestions -
Project-wide consistency analysis -
Warnings for potentially harmful code -
Explanations for violations -

Credo: First 24 hours, Roadmap coming

I am overwhelmed by the response to Credo, the first teaching code linter for Elixir. It was released approx. 24 hours ago, and I could not be happier with the reaction on Twitter, GitHub and via email.

Checkout Credo on GitHub if you haven't!

We're now at v0.1.6 and I plan to release a roadmap on Friday for how I think this should commence. I will do so in form of an issue on GitHub, so we all have a chance to see and discuss future development and prioritization thereof.

Some impressions of the kind reactions on Twitter:

Thanks a million! I feel very fortunate to be a part of this community.

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:

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"?

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).
  • 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:

All of this is fully customizable, extendable with your own checks and completely Open Source under MIT License. It is very much v0.1.0 and still a bit rough around the edges. If you like the idea, please test-drive Credo and report any findings on GitHub so it can get better over time.

:heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:

Fork me on GitHub