7 ms·

Qodana: Code Quality Monitoring Platform

57 points by SerCe 5y ago

jka 5y ago
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?
- Aeolun 5y ago
  Not sure what systems you are trying to hone?
  - jka 5y ago
    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.
- cat199 5y ago
  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.
ris 5y ago
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)".
- zamalek 5y ago
  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.
  - nomoreplease 5y ago
    > coding standards Coding standards for NASA certainly isn’t bike shedding, especially if they focus on reliability or security
    - zamalek 5y ago
      NASA effectively enforces a DSL, not coding standards.
  - joshribakoff 5y ago
    Code formatting, quality metrics, and style guide/standards are all different things.
  - ris 5y ago
    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.
    - dewey 5y ago
      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.
      - ris 5y ago
        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.
wanderingmind 5y ago
Say if I develop in python, Why should I use this instead of pylint which is open source and vetted by the community?
- klohto 5y ago
  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).
pabs3 5y ago
Anyone know which open source linters this runs? Or is it just running their own proprietary linters?

57 points by SerCe 5y ago

jka 5y ago

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?

Aeolun 5y ago
Not sure what systems you are trying to hone?
- jka 5y ago
  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.
cat199 5y ago
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.

ris 5y ago

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

zamalek 5y ago
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.
- nomoreplease 5y ago
  > coding standards Coding standards for NASA certainly isn’t bike shedding, especially if they focus on reliability or security
  - zamalek 5y ago
    NASA effectively enforces a DSL, not coding standards.
- joshribakoff 5y ago
  Code formatting, quality metrics, and style guide/standards are all different things.
- ris 5y ago
  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.
  - dewey 5y ago
    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.
    - ris 5y ago
      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.

wanderingmind 5y ago

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

klohto 5y ago
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).

pabs3 5y ago

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