Recently I joined a new project in and I immediately saw some improvements could be done.
It so happens that many of these improvements are part of credo which I am a big fan of.
So naturally I suggested its use on our project.
Denied!
My request was denied and so we entered a constructive discussion. I pointed out all the warning types Credo checks (missing docs, refactors, software design issues, complexity, etc) and mentioned the community usually sees value in such a tool.
As a counter argument, some members of my team mentioned that none of the big Elixir project’s use it: Plug, Ecto, Phoenix. So, perhaps this tool doesn’t bring as much value as I think it does and so we should not use it.
Questions
This is IMO, a really good counter argument. Why don’t any of the big Elixir projects use Credo?
Do you use Credo? If not why?
Do notice that if you don’t like a specific rule or don’t agree with a specific recommendation you can ask Credo to not check them. So for me at least, not agreeing with 3% of the rules Credo suggests is not really an argument to not use it.
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.
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.
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.
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.
Had no problems myself, but if people on the team resisted using credo I’d try to explain them why I think project/company-wide styleguide is important, and if I succeed in that, then credo pretty much becomes a logical consequence, b/c it makes sense to enforce as much of the rules as possible automatically.
I’ve found credo good for enforcing in CI what I may be slacking off on or forgetting to check for.
The only thing I’ve considered turning off is the TODO. But I’m keeping that for now as well.
I could see making a project where I don’t want it just because it can feel a bit like homework and the things it enforces do not matter in all cases (quick things, throwaways, proof-of-concept). I can see entire classes of personalities that don’t like that sort of tooling and I would probably have resisted it a bunch of years back from a combination of not-invented-here, don’t tell me what to do and ugh-process-that-I-must-conform-to. So in any project, team members can have any sort of base viewpoint and I believe its more important to find a sympathetic way to work together rather than having a specific tool in use.
I’ve changed my approach over time. I’m less precious about the specific lines of code I type, I try to automate a base level of quality as far as I find reasonable and focus on more important parts of the craft, thinking, modelling the problem, writing the right tests (so I don’t break the damn thing).
I actually am pretty lax with the TODO checking on personal products, but for work products I think TODO checking is fantastic, because it reminds me to add items to milestones for github issue tracking (and sprints for JIRA tracking, which I don’t use anymore). That way you know you there won’t be code with TODOs that other people don’t have eyes on in some persistent list.
I use Credo for all my projects. I like that removes bike shedding. In code bases lots of small things need decisions. The decision doesn’t really matter but it needs to be made to have consistency.
Hello, I’m starting with elixir…
And I love to learn about tools not really described in beginners resources but which are used by elixir gurus…
So, besides credo, what else do you use for dev or in prod?
Dialyxir, to get dialyzer warnings in Elixir. It gives you warnings if something is wrong with your types and such. It can be a bit annoying to understand but it should never lie
Elixir LS Fork for Visual Studio Code, which can give you Dialyzer warnings in your editor. The Fork seems to have resolved some issues I’ve had with the main ElixirLS extension.
Recently got started with “mix xref callers” which is good when figuring out the impact of reworking things.
ExDoc and doctests I really like too and I didn’t get knto them before I tried to set up a library for release but they are useful way before that.
To add to the list previously given by @lawik I would also add excoveralls, if you like TDD.
My company does not have a style guide. It pretty much varies depending on each team and project. I guess I could start there. Perhaps a team style guide would be a good starting point.
