Code Quality Q&A With the JetBrains Qodana Team

The code quality platform for teams

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.

“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

“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

“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

“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

“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

“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(<INSPECTION ID>) and // NOLINTNEXTLINE(<INSPECTION ID>)“. – Anna Zhukova

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.

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.

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

The public sector handles sensitive citizen data, which is why software projects built with secure coding are imperative to deliver high trust levels. Code compliance with data protection laws, financial governance standards, and various regulations and policies is an obligation. It should be consis…

Modern software development teams face a difficult balancing act. Applications are growing more complex, release cycles are accelerating, and security expectations continue to rise. This is especially true in a time where much more code is generated daily, which needs to be checked. Teams need…

A developer in DevOps pushes a Kubernetes deployment with no resource limits, a pod running as root explicitly, and a GitHub Actions workflow runs with mutable tags - and it goes straight to production, unnoticed. No quality gate. No IDE warning. No CI failure…

20 Years, 1 MissionMeet Qodana Lead Alex Gopachenko https://www.youtube.com/watch?v=OwX_Qs_k0AQ Twenty years is a lifetime in software engineering. Languages rise and fall. Frameworks become obsolete. Entire categories of developer tools appear, dominate the industry, and quietly disappear a…