Qodana: Code Quality Monitoring Platform | Hacker News Reader

Qodana: Code Quality Monitoring Platform

lp.jetbrains.com

57 pointsSerCe17 comments

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)".

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.

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.

> 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.

In the same way that it can be difficult to justify spending a week to reduce technical debt within a fast-moving engineering team, I think there's a parallel challenge for industry to make the work of maintenance be seen -- and be rewarded -- equally alongside feature development.

Perhaps we already have (or at least nearly have) enough code, systems and services to achieve the tasks that 97.5% of us need, but they're all broken and non-interoperable in frustrating ways.

Can we spend a while honing and refining those before building incompatible replacements? Or, failing that, at least identify the core issues before repeating the same mistakes?

this highlights the fact that we often try to solve wetware problems with software, because software is "easier".

so long as people don't want to look at their own 'stuff', this mis-attribution in requirements will always be an issue.

Not sure what systems you are trying to hone?

Desktop environments, operating systems, communication and collaboration tools, web browsers, widely-used shared libraries, for example.. there are a large number of software systems that people rely on where stability, performance, bugfixes and compatibility improvements are worthy goals.

Say if I develop in python, Why should I use this instead of pylint which is open source and vetted by the community?

Qodana isn’t just a linter though, that’s the sell. It will eventually include popular Python linters (right now only Java, Kotlin and PHP are supported).

Anyone know which open source linters this runs? Or is it just running their own proprietary linters?

Reply on news.ycombinator.com