Hacker News Reader

Comment by ris | Hacker News Reader

Code quality metrics are, quite universally, garbage.

At best they take a bunch of subjective preferences (come up with by some random person), assert them as gospel and teach people that they are "best practise". At worst, they will cause a team to waste time making meaningless changes and junking up their git history.

Generally if I see a project that scores an A+++ on one of these metrics, it gives me the impression that they've got their priorities rather mixed up.

It's the classic thing of "identifying real problems automatically is really extremely hard, so what we'll do is double down on the really simplistic factors (which are unfortunately meaningless)".

View on HN

This isn't about "code quality metrics". This is about reporting stuff like "you have unused class", or "here variable can be null but you are dereferencing it", actual problems in your code

I find that they're almost garbage.

So as long as everyone is OK with massive muting and disabling of 98% of the issues. There is the 2% which actually helps to find bugs and improves code readability.

The problem is with making sure management don't take those things as "gospel" as you said. Sometimes they don't have a choice, I worked on projects where the client contract actually included a requirement for zero style and quality warnings (DoD).

But something like gofmt is valuable. If you're removing unused imports and similar with every time you write source to disk, you gain a ton of benefits (especially in VCS history).

Otherwise, totally, coding standards and so forth are just bike shedding.

> coding standards

Coding standards for NASA certainly isn’t bike shedding, especially if they focus on reliability or security

NASA effectively enforces a DSL, not coding standards.

Code formatting, quality metrics, and style guide/standards are all different things.

Except gofmt and many others make the single most boneheaded formatting mistake - aligned indents. Aligned indents will cause a single-line change to balloon into a many-line diff, solely to re-align with the new content's length. This causes all sorts of unnecessary merge/rebase conflicts.

In my years of working with Go in multiple teams that was never really a problem and I haven't even thought about that once so far.

I wonder to what extent you've had to maintain stable branches then.

Still, if people are going to enforce something as meaningless as formatting, why not at least get it right? Otherwise it's unarguably just about stroking the obsessive compulsive tendencies of the team members who are more that way inclined.

Reply on news.ycombinator.com