Remove ktlint linting workflow?

[westnordost]

The ktlint linter has long been a thorn in my side. In my opinion, it just creates so much noise, also in the git log and thus when using git blame. (I.e. it becomes harder in some cases to find why a change was made, due to all those lint commits.) But also, on merges. Since lint commits tend to be added on stuff that was just made, i.e. that might still be worked on, several times in the last weeks I had to go through merge conflicts with some lint commits. And I am like, sigh, what am I even doing here?

(I know that linting (automatically) on (squash merge of) PRs would be more effective, but I didn't want that.)

On the other hand, its utility I find really questionable. The code is for humans to read. So, I think we are pretty capable of deciding what is readable and consistent and what is not. At least those things that it finds, is stuff where I usually think "meh, okay 🤷", like import statements that are not alphabetically arranged, or some space too much or too little. Not to mention the many times where ktlint actually was invasive and needed to be domesticated.

Which brings me to my next point: It is a time sink. Like a tamagotchi that constantly needs care by its master, it seems to me that the little time most of all @FloEdelmann can expend for this project is absorbed by taking care of the linter.

So, what do you think, @FloEdelmann ?

[HolgerJeromin]

As a separate step stylistic lint rules are a real pain.
With the Javascript/Typescript world the stylistic rules were removed from the eslint core.
Most users use a code formatter (on save/compile) like prettier.io nowadays.

Having a uniform code base has the benefit for having better search result inside the code.
But with an unpaid contributing community this can be really frustrating if everybody need to setup the formatter properly (not possible with github code editor as often used here in this project).

[RubenKelevra]

I'm used to ruff under Python, which is quite useful IMHO. I very rarely find it's suggestions "annoying" it feels more like best practices forced upon you, you did not remember.

That's why I suggested detekt, which sounded a bit similar to me from reading the description. So maybe worth a try?

Ususally a project needs a while to adapt the rules to the liking of the maintainer, but then it's usually pretty non-invasive - or should be and instead contributors from outside are reminded that there are some styling rules to follow and can do succesive commits to fix the little mistakes maybe made in their contributions.

[peternewman]

As a more general thing, you definitely want to offer a style "setup" as otherwise you risk people using different IDEs essentially fighting over things like tabs/spaces, especially if the IDE is just auto-formatting it, the linter just helps to enforce that/nudge people in the right direction.

[HolgerJeromin]

This should be done with the existing ".editorconfig" file.

[matkoniecz]

AFAIK it is done already

[matkoniecz]

Personally I use linter in some of my projects, but I run it (often with heavy exclusion of rules), accept most of proposed changes and ignore remaining ones. This is I thing useful, especially in Python.

Here I get notification after every push and merge that linter hates some code unrelated to one I changed.

I would like this linter if it would be closer to tool that I run and it edits in place code and I commit some of it or it points out problems.
Not as a nagging notification generator. Posted this as I got it again after I merged a PR.

[riQQ]

One solution to this problem could be to keep a minimal set of rules that can be automatically fixed by the linter and then have a workflow that runs on every push to main that automatically fixes everything it finds and pushes a fix to main.