Code Quality Q&A With the JetBrains Qodana Team

Code quality is shaped by countless decisions, from how developers manage complexity to how quickly they detect regressions. But common concepts such as technical debt, cognitive complexity and unit testing are not always clearly understood.

In a new code quality Q&A session, we asked members of the Qodana team to answer some frequently searched questions about maintaining code quality. Here are their concise, practical explanations.

Table of Contents

What is the difference between technical debt and poor code quality?

What are the best practices for minimizing cognitive complexity in deeply nested loops?

What is the difference between cohesion and coupling, and how do they impact maintainability?

What role do unit tests play in maintaining quality standards?

How do you track if code quality is actually improving?

How do you eliminate false positives in automated vulnerability scanning pipelines?

Don’t miss the next code quality Q&A

What is the difference between technical debt and poor code quality?

“Poor code quality describes the code itself, while technical debt describes a compromise that creates future work. For example, “Let’s use hardcoded values instead of configs, just because we need to write POC ASAP” is intentional technical debt.

By contrast, “I don’t know why I need to use configs, that’s why I hardcode values” is poor code quality caused by a lack of knowledge. Technical debt may lead to poor code quality, but poor code quality is not always caused by technical debt”. – Alexandr Kugushev

What are the best practices for minimizing cognitive complexity in deeply nested loops?

“Best practice to minimize complexity in nested loops – is avoiding them: extract functions, double check conditions (maybe it’s possible to simplify them with different logic rules), explicitly name intermediate results, use iterators, generators, map, filter, reduce functions, try to flatten data before processing and so on”. – Anastasia Lavrenko

What is the difference between cohesion and coupling, and how do they impact maintainability?

“Code coverage and mutation testing serve different but related purposes. Code coverage measures how much production code is executed by unit tests. Mutation testing evaluates the quality of those tests by deliberately introducing small changes to the code and checking whether the tests detect them. If the tests still pass, the mutation survives, indicating a possible gap in the test suite.

There is no universal ideal mutation score, as results vary by project and testing strategy. However, scores of around 40–60% are generally considered a reasonable starting range. Higher scores can indicate a stronger test suite, but the goal should be meaningful test quality rather than reaching a specific number”. – Aleksander Movsesov

What role do unit tests play in maintaining quality standards?

“Unit tests provide the fastest feedback on code changes. By testing individual units of behaviour in isolation, they catch regressions close to the point where they are introduced, make refactoring safer and confirm that the code continues to behave as expected”. – Arman Ayvazyan

How do you track if code quality is actually improving?

“I think the best way to track if code quality is actually improving is to look at the trends over time. Static analysis can give you signals like how many new issues are being introduced, how severe those issues are, and whether technical debt is going up or down. But you should also be able to see the impact outside of static analysis.

If code quality is improving, you should start seeing fewer Sev 1 issues making it into production and a faster MTTR when issues do happen. That gives you a better picture of whether the changes you are making are actually improving the quality and reliability of the software”. – Alex Costa

How do you eliminate false positives in automated vulnerability scanning pipelines?

“First of all, we should draw a distinction between vulnerability scanning and static analysis. What Qodana does is not always vulnerability scanning – a lot of the issues it finds cannot be exploited by a third party. Sure, Qodana does find vulnerabilities, but it also finds regular bugs, dangerous functions, dead code, and so on.

That being said, eliminating false positives is done in a similar way regardless of the issues – by giving the tool you use more information about your repository. The most common case of a false positive is the automated tool not knowing that you intended something to be written in a particular way, for example when you disagree with established practices, or when you use an older standard of the language that doesn’t support a safer alternative, or when you are forced into an unsafe code pattern by a third-party dependency.

All of this can be addressed: for repo-wide false positives, you can exclude the inspections in qodana.yaml. For individual lines and blocks for code, you can explicitly silence inspections with comments like // NOLINT() and // NOLINTNEXTLINE()“. – Anna Zhukhova

Maintaining code quality requires more than fixing individual issues. Teams need to make technical compromises consciously, keep code understandable and create fast feedback loops that catch problems early.

Automated code analysis can support these practices by identifying quality issues continuously and helping teams apply consistent standards throughout development. With Qodana, teams can bring JetBrains inspections into their CI/CD pipelines and address problems before they become more difficult and expensive to resolve.

Don’t miss the next code quality Q&A

Need answers to your most pressing code quality and security questions? Leave a comment below for the next round or find out how Qodana can help you secure and improve your codebase.

Request a Code Quality Demo