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

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.

I’m not sure running it in a pre-commit hook is optimal. Credo isn’t very slow, but IMO it’s not that fast to do it on every commit. Moreover, I wouldn’t even want credo to prevent me from committing some intermediate WIP commits.

I run credo during CI check, and that’s good enough for me. Usually I remember to check credo locally before pushing the code, but even if I don’t, it’s not a big deal. I’ll get a CI error, and fix it.