Do you use Credo?

Since the introduction of the formatter I’ve not used any linters. I don’t necessarily disagree with their checks but I no longer find them useful.

I use Credo on all my projects. You get hints for free so what’s there not to like? Credo is great in the sense that it starts with the most burning issues and leaves the less important ones for later. And you can add it as an optional check - it doesn’t have to block your pull request/CI. So I see no reason not to include it in a bigger codebase - Credo’s defaults are really reasonable.

Is your team willing to address the issues found by Credo (even if you would point to them without the tool)? I think you need to first figure out the answer to that question.

@lpil Don’t you think that missing docs, refactors and complexity checks have value?
I would like to know more about your opinion on the matter. Do you find it cumbersome to have to obey to strict rules? Or perhaps you have other reasons?

@stefanchrobot They usually like to do things their own way, I found it difficult to convince them of some of the checks even when reading the docs.
I believe I am missing a more comprehensive list on the “Whys” and the reasoning behind the checks but I couldn’t find it.

I don’t find they offer anything I can’t determine by looking at the code.

If I were to inherit an old and unloved codebase that needed changing I might use it to gain some insight into the system before refactoring.

We use credo. It’s helpful but not something we absolutely need. I don’t know if I would necessarily decide on what libraries to use based on what the larger projects like Ecto, Plug, etc. use.

I think credo is a great tool if you want to have a project-wide or company-wide styleguide and enforce as much of it as possible automatically.

I believe that having a styleguide together with consistent layout (which is handled by the formatter) makes it easier to keep the code understandable. To be clear, neither styleguide nor consistent layout are enough. It’s still possible to have a code which is nicely formatted and follows the styleguide, but is at the same time a convoluted mess and hard to understand. That said, I think that consistent styleguide and layout, especially if enforced automatically, can help the team focus on higher level issues, such as separation of concerns, building cohesive abstractions, reducing coupling, …

When I started working for my current client, introducing credo was one of the first thing I did (together with enforced formatting and treating warnings as errors on CI). We use the strict mode, enabling some of the additional checks, and disabling a few of them we don’t want to follow (e.g. TagTODO), and even writing a few of our own checks. Some of the things we enforce with credo:

• consistent module layout (e.g. public funs are written before behaviour callbacks, are written before private funs)
• proper file naming (module Foo.Bar.Baz should reside in lib/foo/bar/baz.ex)
• mandatory typespecs for public functions
• forbidding alias Foo, as: Bar

So I personally find credo very useful. Being very unopinionated, I think of it as a styleguide toolkit. It ships with a bunch of interesting and useful checks, such as detecting leftover IO.inspect, or redundant try, double negations, etc. It provides some sane defaults out of the box, which can be changed both globally (per project) and locally (on a case-by-case basis).

This isn’t an argument at all. But it is a good question “Why do the big ones don’t use credo”.

I use credo because:

credo can show you refactoring opportunities in your code, complex code fragments, warn you about common mistakes, show inconsistencies in your naming scheme and - if needed - help you enforce a desired coding style.

This is what I am trying to do in my company as well.

Did any of you guys find resistance when trying to add credo to your current projects/jobs?
How did you convinced people?

Also, does anyone know why none of the big projects use it?

I’ve used Credo on most of the projects I’ve ever been on. In fact, I just wrote a bunch of custom checks for my current job. There was no resistance there, but the argument I make in every case (when needed) is that things like Credo are good for teams. When a computer (or computer program) tells you to change your formatting or whatever, you just do it. When a teammate does it in PR review you get angry at them for making you change your code, which is “perfectly fine, by the way.” It’s way better to hate Credo for being picky than to hate your coworker for the same thing.

Plus, it’s nice to just remove things like that entirely from the code review process. When I review code, the only thing I need to look at are the contents of the code and not the formatting/style. If it passes the formatter and Credo checks, then it is 100% “correct” style & formatting.

Most of the big OSS projects actually pre-date Credo, and also most of them try and keep their dependencies as minimal as possible (which is a good thing). They’re actually doing their users a solid by not using Credo, since it makes dependency resolution easier. For example, if they were using Credo 1.0 and you were using Credo 0.9 or something, there would be a dependency conflict you’d need to manage.

There shouldn’t if they properly declared their dependency on :credo as only: … where … is a list not including :prod.

I dropped credo quite a while ago, as it was annoyingly slow when running against the project, while not doing the important checks (the consitency ones) when ran against a single file.

So it works only for me when I run it against the full project, as the consistency checks where actually those I was interested in back then. Today those are covered by the formatter (most of them).

But since it was that slow it slowed me too much when in the pre-commit-hooks.

And I hate to have additional commits that are solely to keep the linter(s) happy, thats why I hate to have them to run outside of the hooks.

I might try again with more recent versions, I’ve heard it got quicker.