Credo and Dogma: A Comparison of Elixir Code Linters26 Nov 2015
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
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:
|Supported Elixir versions||1.1.x||1.0.x, 1.1.x|
|Customizable check configuration via parameters||✔||✔|
|Help for check parameters in CLI||✔||-|
|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||✔||-|