Just saw #7655 and its comment mentioning a linting tool. I remembered that we had this conversation at least once somewhere, but didn’t find the corresponding issue.
Let’s discuss the possibility, pros and cons of built-in linting tool for Crystal.
Thesis: I’d stand for unified code-style in all Crystal programs.
We’ve got used to the fact that languages have many code styles. Apart from community-supported standards (often very different) like AirBnB vs Standard in Javascript, linting tools allow to define your own code style, suitable for your or your team needs.
What’s the result? Instead of starting working on some project code immediately, we have to firstly learn its style conventions. We have to follow these “foreign” conventions even if we’ve got used to our own.
Projects exist which purpose is to solely enforce certain code style, effectively saying “despite of the fact that you’ve already have spent your time on some code, we won’t accept it unless you change its style to what we want”.
Different code styles sometimes involve things more complex than semicolons. I’m speaking about functions definition, maximum arguments length, maximum function size etc; it could require massive changes in otherwise good code just to conform with someone else’s point of view on “perfect code style”.
I don’t say code style rules are bad. I’m saying that too much freedom in defining what’s a good style on per-project basis is bad. I’d love to see a first-class linting tool integrated into the language itself.
We already have crystal format which enforces code “visuals” and raises on obvious syntax errors, and that’s awesome. I’d love to see it’s being smarter and incorporate some features from Ameba.
crystal tool format covers some formal aspects of a code style. This is an easy task, because we managed to agree on a set of rules, the formatter can unequivocally detect them and automatically apply these rules without changing semantics.
An advanced structural analysis of Crystal code is way more complex and has a lot more pitfalls. It’s already difficult enough to reliably detect actual code issues. The intention of code is sometimes hard to understand, which leads to false positives and true negatives. Even if detection was good, application of rules is a whole other story. Let alone agreeing on a set of rules.
Having a unified code style guide would certainly be nice, but I don’t think it’s feasible to implement. Even if we wanted to. And I think it’s perfectly fine to have a separate tool like ameba. But ameba already shows that it’s impossible to standardize on a rule set. Every repo can configure which rules should apply. And that’s already for a small subset of Crystal users who agree that ameba is a great tool to use.
I like code linters that give suggestions not rules.
I understand the need to have some consistency but as the end user of a language it is there to serve my needs not be ideologically pure. If there is a linter that shows hints but can be easily ignored and smart enough to not continually bother me I would like that.
It is similar to having Apple reach into my OS and change something for me. I know where they want things to go and most the time I put them where Apple would like and sometimes I totally ignore their wishes because it is my machine and I have reasons.
Basically a linter should be default give the user complete autonomy.