←back to thread

873 points belter | 8 comments | | HN request time: 0.959s | source | bottom
1. v3ss0n ◴[] No.42947713[source]
>People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.

This sticks out like sore thumb to me and I think you are coding solo for 10 years. If you manage to lead a team of developers or work with them you are screwed without linting rules and standardized code style. Even if they are applied it takes months to get to a get a team working in harmony - without them it will be a disaster.

- merge conflict hells because code style diferences - bad for code reviewers - bad to ready everyone's different code sytles.

replies(1): >>42947883 #
2. pjc50 ◴[] No.42947883[source]
He's not saying you shouldn't do it, he's saying you shouldn't stress over it. The "run the language's standard formatter before commit and then get on with your life" approach.
replies(2): >>42948208 #>>42949337 #
3. v3ss0n ◴[] No.42948208[source]
Everyone on the team need to agree to the linting rules before using linters. Else they will keep wirting their code according to their habits , and then they start to modify the rule that dosen't fit their bad habits when linters hints to fix the code.

> run the language's standard formatter

Even with very smart linters like `ruff` it cannot fix all of the linting errors. You have to hand fix many of them.

What linter do you use that can just run and forget?

replies(1): >>42949299 #
4. pjc50 ◴[] No.42949299{3}[source]
Dotnet-format for formatting. Can auto fix.

Sonarqube for linting. It's more annoying and not auto fixing, but it achieves the goal of avoiding arguments and does catch some bugs.

replies(1): >>42957769 #
5. botanical76 ◴[] No.42949337[source]
I do think there's value in manual formatting some code sections. For example, very large arrays, or alignment of semantic parts of a group of mathematical expressions. Ultimately, I think the only thing that matters is that the code is readable, consistent and you don't spend much time on how it looks.

That said, if you have team members who somehow can't or won't copy the surrounding code style, then automatic linting sounds necessary.

replies(1): >>42961570 #
6. v3ss0n ◴[] No.42957769{4}[source]
In python and js sonarcube sucks. Ruff and Biome are perfect but still need manual fixes
7. notTooFarGone ◴[] No.42961570{3}[source]
See it like this - in 10 years when here is no original dev working on this, will this project still have the same code style?

With a nice .editorconfig the probability is very high that it's mostly consistent. I can guarantee you any manual rules will be long forgotten and the IDE style will reign supreme - only your old "manual" formatting will stick out like a sore thumb.

replies(1): >>42963076 #
8. v3ss0n ◴[] No.42963076{4}[source]
here are the rules we enforce inside `pyproject.toml` https://gist.github.com/v3ss0n/3b0a8ac808f6930ea04e4ada62d90...