3 ms·

I have found an overwhelming amount of "static analysis" (really linting) serves only to pile more stupid busy work onto developers and soak up CI cycles. Who a

by mdoms 5y ago

I have found an overwhelming amount of "static analysis" (really linting) serves only to pile more stupid busy work onto developers and soak up CI cycles. Who actually (and I mean ACTUALLY) cares if my imports are not in alphabetical order? Who cares (I mean REALLY) if I have ( spaces ) between my brackets and their contents (or not). Stop wasting my time with this nonsense.

spockz 5y ago
This is why your project should be set up so these kind of checks can be performed easily and quickly locally. We auto format on compile for example. Enforcing code style is not nonsense when automated. It ensures consistency and it helps preventing things like changes in white space without any semantic change. Manual checking of the above is silly indeed. Review comments should be about the code and intent. Not the syntax.
- patrick451 5y ago
  The biggest reason to use an auto formatter is take all those nits off the table for gripes during code review. I think the consistency claim is overrated. Seeing ){ vs ) { doesn't help me read a codebase better, not does see un-alphabetized imports. The biggest culprit of whitespace only changes is somebody running an auto-formatter on a file where that isn't enforced by CI.
jordwest 5y ago
While I think there’s value in tooling that tidies these things up automatically, I agree that enforcing CI rules around these is a waste of time. I think so many engineers have been burned by bad code that we now instinctively latch onto anything that appears to quantitatively improve the code, but then get so focused on those metrics that the real fundamental problems are ignored. So we end up running around in circles pleasing CI instead of spending that time thinking more about the architecture and patterns that make code bad. Code quality theatre.
anonydsfsfs 5y ago
> Who actually (and I mean ACTUALLY) cares if my imports are not in alphabetical order? Who cares (I mean REALLY) if I have ( spaces ) between my brackets and their contents (or not). These are the kind of things that are best solved with an automatic code formatter like Prettier or gofmt instead of a linter. This is one of things that Go got right: gofmt eliminates squabbling over code quality issues and is fast enough that you can run it every time you save a file and not notice the overhead.
- mdoms 5y ago
  Or just not solved at all because they're not problems.
IshKebab 5y ago
You can have these checks run before CI.
superjan 5y ago
Yeah tools like linters (or strict compiler warning rules) can cause a lot of distraction. Sometimes the rules are dictated, with no possibility for appeal. Sometimes people don’t dare to to be that guy who suggests to dial down on quality. It can be counterproductive if an important bug is hidden in a tsunami of warnings. Best to turn on warnings one by one, and check if the effect is as intended.
patrick451 5y ago
Completely agree. Ctrl-f works whether your imports are sorted or not. I'm of the opinion that unless a codebase supports using an auto-formatter (as in, if I run the autoformatter on save to any file I touch, it's guaranteed to only adjust my changes), these kind of rules have no business being part of a the code style rules.

by mdoms 5y ago

spockz 5y ago

This is why your project should be set up so these kind of checks can be performed easily and quickly locally. We auto format on compile for example. Enforcing code style is not nonsense when automated. It ensures consistency and it helps preventing things like changes in white space without any semantic change. Manual checking of the above is silly indeed. Review comments should be about the code and intent. Not the syntax.

patrick451 5y ago
The biggest reason to use an auto formatter is take all those nits off the table for gripes during code review. I think the consistency claim is overrated. Seeing ){ vs ) { doesn't help me read a codebase better, not does see un-alphabetized imports. The biggest culprit of whitespace only changes is somebody running an auto-formatter on a file where that isn't enforced by CI.

jordwest 5y ago

While I think there’s value in tooling that tidies these things up automatically, I agree that enforcing CI rules around these is a waste of time. I think so many engineers have been burned by bad code that we now instinctively latch onto anything that appears to quantitatively improve the code, but then get so focused on those metrics that the real fundamental problems are ignored. So we end up running around in circles pleasing CI instead of spending that time thinking more about the architecture and patterns that make code bad. Code quality theatre.

anonydsfsfs 5y ago

> Who actually (and I mean ACTUALLY) cares if my imports are not in alphabetical order? Who cares (I mean REALLY) if I have ( spaces ) between my brackets and their contents (or not). These are the kind of things that are best solved with an automatic code formatter like Prettier or gofmt instead of a linter. This is one of things that Go got right: gofmt eliminates squabbling over code quality issues and is fast enough that you can run it every time you save a file and not notice the overhead.

mdoms 5y ago
Or just not solved at all because they're not problems.

IshKebab 5y ago

You can have these checks run before CI.

superjan 5y ago

Yeah tools like linters (or strict compiler warning rules) can cause a lot of distraction. Sometimes the rules are dictated, with no possibility for appeal. Sometimes people don’t dare to to be that guy who suggests to dial down on quality. It can be counterproductive if an important bug is hidden in a tsunami of warnings. Best to turn on warnings one by one, and check if the effect is as intended.

patrick451 5y ago

Completely agree. Ctrl-f works whether your imports are sorted or not. I'm of the opinion that unless a codebase supports using an auto-formatter (as in, if I run the autoformatter on save to any file I touch, it's guaranteed to only adjust my changes), these kind of rules have no business being part of a the code style rules.