The new Qodana release is live with major enhancements to help you ensure your code is of the highest quality. Version 2023.1 brings much more flexibility to the static analysis step of your CI pipeline. We’ve introduced a smart way to configure checks for scanning your projects, and we’ve implemented perhaps the easiest way to add plugins to your Qodana static analysis engine. 

Read on to see the full list of major updates or jump straight to linter-specific enhancements. 

Try Qodana for free

Major updates 

Flexible profile configuration with the new YAML format

Inspection profiles are a key part of your Qodana configuration. They define a set of inspections that Qodana will apply to your code while running its analysis.

Starting from version 2023.1, Qodana provides flexible profile configuration capabilities in the human-readable YAML format, making it even easier to customize your inspection profile and adjust it as your project progresses. Here are the options for fine-tuning your analysis:

• [NEW] Group inspections and manage such groups. 
• [NEW] Include existing and compose new profiles. 
• Enable and disable inspections.
• Set up inspection parameters. 
• Configure the inspection scope. 

For example, you can exclude the PhpDeprecationInspection inspection from the Qodana for PHP linter while inspecting your code using the PHP/General inspection category.

name: "PHP/General without PhpDeprecationInspection"
inspections:
  - group: "category:PHP/General"
    enabled: true # Enable the 'PHP/General' category
  - inspection: PhpDeprecationInspection
    enabled: false # Disable the PhpDeprecationInspection inspection

See the documentation to learn more about custom profiles. 

Major refactoring of default profiles

Qodana offers two types of default profiles – qodana.starter, which is used for vital checks only and is ideal for the initial scan of the project, and qodana.recommended, which enables a preselected set of inspections that are broadly suitable for most projects.

We’ve rewritten both profiles, bringing them into alignment with the Default profile provided in our IDEs. This change provides more transparency and allows you to ensure that the inspections run by Qodana and your IDE are mostly the same, facilitating a more consistent approach to code quality. 

The updated qodana.recommended profile can be found on GitHub. This profile matches the Default IDE profile with a few exceptions:

• For more lightweight analysis, all global inspections are disabled, as they can be very time consuming.  
• Some project directories, like build directories and test sources, are excluded from the analysis by default.

The updated qodana.starter profile can also be found on GitHub. This profile is derived from the qodana.recommended profile and performs only vital checks. Here are the major changes we’ve made:

• Inspections with codestyle and code conventions semantics are disabled. 
• Inspections are disabled for non-executable parts of the codebase (for example, Javadocs).

Easy way to add plugins to Qodana

If you want to extend Qodana and use inspection plugins from JetBrains Marketplace, you just need to add their IDs to your qodana.yaml file. 

Thanks to recent Marketplace updates, you can now copy a plugin’s ID directly from its page. 

There are 2 ways to install third-party software required for your plugins:

• Use the bootstrap option.
• Develop a custom Dockerfile that starts with FROM jetbrains/qodana... You can use Qodana Dockerfile examples available on GitHub.

Here are some noteworthy and popular plugins you might want to check out:

• Grazie Professional, which offers advanced natural-language writing assistance, featuring spell-check, grammar correction, natural language completion, and other helpful tools for writing and editing text. 
• CheckStyle, which provides both real-time and on-demand scanning of Java files with CheckStyle from within IntelliJ IDEA.
• Zero Width Characters Locator, which adds an inspection that prevents some hard to find bugs related to invisible zero width characters in source code and resources. 

You can find more plugins with this search on JetBrains Marketplace. 

Qodana currently does not support paid plugins, and there may still be plugins that are not compatible with the current version. We are working on introducing proper compatibility checks for Qodana plugins on JetBrains Marketplace this year.

Linter-specific updates

New JVM inspections in Qodana 

Inspections for the Kotlin / JS IR compiler

The Kotlin team has introduced a new IR compiler that supports the migration of your Kotlin source code to JavaScript. To facilitate the migration process and spot potential errors, Qodana now supports the following inspections:

NonExternalClassifierExtendingStateOrProps

Using Kotlin interfaces and classes (including data classes) that derive from pure JS classes, such as React’s State and Props, can cause ClassCastExceptions. Such exceptions occur because the compiler attempts to work with instances of these classes as if they were Kotlin objects, despite actually coming from JS.

The solution is to convert all classes and interfaces that derive from pure JS classes to external interfaces. Qodana will report non-external classifier-extending uses of State or Props. 

NonVarPropertyInExternalInterface

Properties of external interfaces in Kotlin / JS code can’t be read-only (val) properties because their values can be assigned only after the objects are created with js() or jso(). The solution is to convert all properties of external interfaces to var.

Qodana will highlight all of the properties that are not var so you can convert them.

SpringTransactionalMethodCallsInspection

The Spring framework allows you to manage application transactions using code annotations. Only external calls of a method marked with `@Transaction` are run under the transaction, which means that self-invocation doesn’t start a new transaction. With this new inspection, Qodana highlights such cases, as they can lead to errors in transaction management.

JUnitMixedFramework

Having multiple versions of JUnit in a project can lead to errors due to developers mistakenly mixing different versions in one test case. For example, consider the following code:

The test is run with JUnit4, so JUnit5’s BeforeEach annotation won’t be processed, and the test will fail with NullPointerException. 

By default, Qodana doesn’t check test sources, so to include this inspection, you need to add the following configuration to qodana.yaml:

include:
  - name: JUnitMixedFramework
    paths:
    - <path-to-tests-directory>

MathRoundingWithIntArgument

This inspection reports calls to round(), ceil(), floor(), and rint() methods for Math and StrictMath. Calling these methods on an integer is redundant and indicates that a mistake was made, like accidental integer division.

Try Qodana for JVM

Third-party license audit for Go

If you rely on open-source components, outsource development, or reuse code from services like GitHub, you need to make sure that you use the appropriate licenses. You may accidentally import a library with a restrictive license into a software codebase or forget to update an expired license. If you do, your organization may be a subject to reputational and legal risks. 

To minimize these risks, we introduced License audit functionality for Java, Kotlin, PHP, and JavaScript last year. In this release, we’ve added support for Go. Qodana will list dependency licenses in an analyzed repository and warn you about any problems concerning their compatibility with project licenses, as in the example below:

Here’s what the dependency license list looks like:

Try Qodana for Go

Updates for .NET

The inspection profile now respects repository settings

Previously, the inspection severity settings in the inspection profile for the .NET linter were based on the default values obtained from ReSharper. However, this approach led to settings being duplicated when a project was already using solution and project configuration layers of ReShaper and Rider along with .editorconfig files stored in the repository. This meant that if you made changes to any of these layers, you had to make the same change in the Qodana YAML profile. 

The inspection profile now automatically inherits settings from ReSharper and the .editorconfig file if they are provided in the repository. No manual work needed anymore! 

The Qodana YAML configuration settings section has been renamed

The qodana.yaml configuration file previously contained a dot-net section, which allowed you to specify the solutions or projects to be opened, as well as configuration and platform options. This section has been renamed to dotnet and the dot-net notation will be deprecated starting from the 2023.2 version of Qodana.

Try Qodana for .NET

How to upgrade to Qodana 2023.1

If you run Qodana with the latest Docker tag, no changes need to be made. If not, update to version 2023.1 in the CI workflow you use Qodana for. You can learn more about the existing CI integrations in our documentation.   

Not all inspections are automatically enabled. To exclude or include certain inspections in your analysis, you may need to customize your inspection profile. 

That wraps up the highlights for Qodana 2023.1! For more details, check the release notes. We hope you enjoy this new release. If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Happy developing and keep your code clean!

Your Qodana team

Deliver code that makes you proud

It only takes one user to exploit a vulnerability in your project and breach your system. To defend programs against malicious inputs from external users (known as “taints”), development teams add taint checking to their static analysis routines. 

In this year’s first release, the Qodana team has delivered taint analysis for PHP in the EAP. The feature is available only in Qodana for PHP 2023.1 (jetbrains/qodana-php:2023.1-eap). Qodana for PHP was the first linter we released, so we decided to let PHP developers be the first to test our new security functionality, too. We plan on adding more languages in the future, after we’ve collected enough feedback.

Read on to learn more about what taint analysis is and how it works in Qodana. 

GET STARTED WITH QODANA

What is taint analysis?

A taint is any value that can pose a security risk when modified by an external user. If you have a taint in your code and unverified external data can be distributed across your program, hackers can execute these code fragments to cause SQL injection, arithmetic overflow, cross-site scripting, path traversal, and more. Usually they exploit these vulnerabilities to destroy the system, hijack credentials and other data, and change the system’s behavior.

As an extra layer of defense against malicious inputs, development teams execute taint analysis when they run a security audit on the program’s attack surface. 

Taint analysis is the process of assessing the flow of untrusted user input throughout the body of a function or method. Its core goal is to determine if unanticipated input can affect program execution in malicious ways. 

Taint sources are locations where a program gets access to potentially tainted data. Key points in a program that are susceptible to allowing tainted input are called taint sinks. This data can be propagated to the sinks via function calls or assignments.

If you run taint analysis manually, you should spot all of the places where you accept data from external users and follow each piece of data through the system – the tainted data can be used in dozens of nodes. Then, to prevent taint propagation, you should take one of the two approaches described below:

1. Sanitize the data, i.e. transform data to a safe state. In the example below, we removed tags to resolve the taint. 

2. Validate the data, i.e. check that the added data conforms to a required pattern. In the example below, we enable validation for the `$email` variable. 

In other words, the taint analysis inspection traces user-tainted data from its source to your sinks, and raises the alarm when you work with that data without sanitizing or validating it. 

How taint analysis works in Qodana

Taint analysis is performed by Qodana for PHP starting from version 2023.1 EAP. This functionality includes an inspection that scans the code and highlights the taint and potential vulnerability, the ability to open the problem in PhpStorm to address it on the spot, and a dataflow graph visualizing the taint flow. 

Example #1. SQL injection 

Let’s take a look at an example of SQL injection and how Qodana detects it:

Here, Qodana shows us the following taints in the system_admin() function:

Markers 1-2: Data from user form input is retrieved from the $_POST global array with no sanitization or validation and is assigned to the variable $edit. This is a taint.

Marker 3: The tainted variable $edit is passed to the system_save_settings function as an argument without any proper sanitization.

Marker 4: Data from the $edit variable is now located in the $edit parameter.

Marker 5: The $edit variable is passed to foreach with the $filename key and $status value. Both variables contain the tainted data from the $edit variable concatenated with the string. The $filename key is concatenated with a tainted SQL string, and then it will propagate tainted data into an argument passed to the db_query.

Marker 6: The $ filename key contains the tainted data from the $edit variable concatenated with the string.

Marker 7: The $ filename key is concatenated with a tainted SQL string.

Marker 8: Tainted SQL string will propagate tainted data into an argument passed to the `db_query`

Let’s now look at the db_query:

Marker 9: The tainted string will be located in the $query parameter.

Marker 10: This parameter is going to be an argument of the _db_query function.

Let’s move on to the _db_query function:

Marker 11: Tainted data located in the first parameter $ query of the _db_query function.

Marker 12: Data of the parameter is passed to the mysql_query function, which is a sink.

The whole data flow above illustrates how data moves from $_POST[“edit”] to the mysql_query($query) without any sanitization or validation. This allows the attacker to manipulate the SQL query which was concatenated with a key of $_POST[“edit”] and trigger SQL injection. 

Qodana will spot these risks in your codebase along with all nodes where tainted data is used, so you can sanitize all tainted data in a timely manner. 

Example #2. XSS problem

In the Qodana UI, you can see a graph that visualizes the entire taint flow. Here’s how Qodana will visualize the XSS vulnerability, which contains 2 sources that would be merged on marker 5.

Source 1

Markers 1-2: Data from the searchUpdate.pos file will be read and tainted data will be assigned to the $start variable.

Source 2

Markers 3-4: Data from files whose path is located in $posFile will be read and tainted data will be assigned to the $start variable.

Marker 5: A merged tainted state from all conditional branches in the $start variable will be passed as an argument to the doUpdateSearchIndex method.

Let’s look inside the doUpdateSearchIndex() method:

Markers 6-8: The $ start parameter will contain tainted data on this dataflow slice and then it will be passed within a concatenated string as an argument to the `output` method.

Let’s look inside the output method:

Marker 9: Tainted data contained inside the transmitted string will be located in the $out parameter.

Marker 10: Data from the $out parameter will be transferred to the `print` function without any sanitization. This function is a sink and causes XSS vulnerability, which can be exploited.

To exploit the vulnerability, an attacker can, for example, upload a shell script instead of the expected files in markers 1 and 2, and will be able to put any information onto the web page as a result of an unsanitized print function.

Qodana will alert you to this vulnerability and give it a high priority so that you can resolve it as soon as possible and prevent the hack.  

Conclusion

Taint analysis helps eliminate exploitable attack surfaces, so it’s an effective method to reduce risk to your software. To learn about taint analysis and Qodana in detail, explore Qodana documentation.

GET STARTED WITH QODANA

Happy developing and keep your code healthy!

Qodana is ideal for development teams that want to increase cohesion and make sure that all their members apply the same rules to code quality checks. Qodana is also valuable for maintaining the quality of open-source projects and will remain free for the open-source community.

However you use Qodana, we believe it will prove invaluable for making your code more reliable, secure, and cleaner than ever before.

How to see Qodana results in PyCharm

As PyCharm now bundles the Qodana IDE plugin, you can interact with Qodana results right in your IDE. The core plugin’s feature is loading the analysis results produced by the Qodana linter to the IDE and showing the detected issues in your project. After the results have been loaded, click on the Qodana tab in the Problems tool window to see an overview of the issues, and then navigate to the source code to fix them.

How to get Qodana results loaded in PyCharm

Before you can load Qodana results in the IDE, you should first get started with the platform and analyze your first project in one of the following ways:

• [Recommended] Trigger an analysis in Qodana Cloud by adding a token to your project in the CI platform.

• Spin up the Qodana linter for Python as Docker.

Next, make sure that the analyzed project has also been opened in PyCharm to achieve a successful sync.

Once Qodana has scanned your first project, there are multiple ways to get Qodana results report loaded in your IDE:

Load the analysis results from Qodana Cloud. In the IDE, navigate to Tools | Qodana | Log in to Qodana. Then, link your IDE project with Qodana Cloud and get the Qodana report loaded in PyCharm.

Manually open a local SARIF file in the IDE. In the IDE, go to Tools | Qodana | Open Qodana Analysis report and select the qodana.sarif.json report file you would like to open.

Use the “Open in IDE” button from the Qodana UI. If you want to see a specific issue spotted by Qodana, simply click the “Open in IDE” button. The Toolbox App will open the IDE instance, and the IDE will spot the corresponding project and show you the problem.

In addition to scanning your code, you can use Qodana to set up quality gates, enforce project- and company-wide coding guidelines, better plan your refactoring projects, and perform holistic license audits. Get started with Qodana now!

Try Qodana

This advice applies to programmers’ resolutions too. If you plan a large project that involves code refactoring, you may want to see the full picture of the required changes and plan accordingly. This is exactly what the IntelliJ team did when they needed to localize the IDE’s entire UI into Chinese, Japanese, and Korean.

Using Qodana, the code quality platform from JetBrains, as a single source of truth for their localization process, the IntelliJ team managed to finish the project much faster than expected. This positive outcome was a result of wise planning, accountability, and oversight. Here’s how they did it.

TRY QODANA FOR FREE

The challenge: isolate 13,000 hard-coded strings and monitor progress effectively

To streamline the localization of their UI into 3 different languages, the IntelliJ team needed to strip out all localizable items from the source code and put them into separate properties files to be handed over for translation.

With over 13,000 strings, it was easy for some localizable ones to be overlooked, meaning that they remained in the code. When localizing the UI, hard-coded strings can be the most difficult parts to deal with. They are hard to find because they do not show up until the software has been localized. As a result, if a user installed the Japanese language pack, for example, some parts of the UI would still be in English.

The team was therefore left with much tedious and repetitive work. As a result the head of the localization project was looking for a solution that would allow them to:

1. Automate a huge chunk of the work by continuously inspecting the code base for hard-coded string literals.
2. Assign issues to the developers who would be responsible for fixing them.
3. Oversee the extraction of localizable strings.

The solution: automated code inspection for hard-coded string literals

The localization project lead chose Qodana to streamline the code inspection process, resulting in a project with the following steps:

#1. Connect Qodana to TeamCity

The IntelliJ team connected Qodana to their TeamCity pipeline and enabled the Internationalization code inspection to highlight hard-coded string literals that were not extracted into properties files as required.

#2. Configure the inspection profile

In the inspection profile, the team configured the scope of the inspection to make sure that the platform skipped parts like legacy code, literals without alphabetic characters, and strings consisting of only whitespace.

The team also made sure that TeamCity would produce a test report for each line inspected by Qodana and fail it if the string wasn’t extracted.

#3. Decide on the frequency of scans

Once fully configured, Qodana was set to inspect the code every 4 hours. It was especially important that the scan was running independently on the server, as opposed to on someone’s local machine. This ultimately saved the team valuable time.

The first Qodana run resulted in 10,000 failed tests in TeamCity.

#4. Assign tasks

For each of the test failures, the project lead assigned a developer to investigate and extract the hard-coded string to the properties file.

#5. Monitor the results

After each Qodana inspection, TeamCity compared the previous results to the current report. If the developer responsible for an issue extracted the string, TeamCity marked the test as fixed. This allowed the project lead to monitor the progress without having to manually mark tests as fixed.

Additionally, the team was able to monitor progress in the Qodana Cloud dashboard, which updated information on the remaining code issues in real time and compared results between different Qodana runs.

Qodana also allowed adding selected issues to the baseline, otherwise known as the technical debt section. This way, the entire team could see the same list of issues and monitor progress right in the platform. Below is an example of how this works.

The key outcomes

In only a few months, the number of failed tests dropped from 10,000 to zero, an average of about 175 fixed tests per day. The team successfully removed all hard-coded string literals from the source code and the whole UI was localized seamlessly, with no unexpected elements in English.

With Qodana, the IntelliJ team required fewer manual steps in the localization process, thereby reducing the number of human errors and increasing confidence in the localized builds. Additionally, with checks running every 4 hours, they were able to detect issues sooner and prevent small problems from turning into big ones later on.

Finally, Qodana became the single source of truth for the team lead, making it easy to ensure that developers fixed the problems they were assigned.

Thanks to these results, the IntelliJ team will keep using Qodana as a code quality and resource planning platform when they deliver new functionalities or improve IntelliJ IDEA’s performance. More on that in our upcoming posts.

GET STARTED WITH QODANA

Happy developing and keep your code clean!

Qodana Cloud is still in development, and to iron out some wrinkles we are calling for the support of the community. If you want to become an early adopter of our new features, read on to learn how to get started with Qodana Cloud.

TRY QODANA CLOUD

How Qodana Cloud can complement your projects

Do you want to run static analysis in multiple projects or repositories? Is your codebase distributed across several servers and virtual private networks? Do your teams work independently, and are they not always on the same page when it comes to code quality? In any of these scenarios, if you wanted to ensure that your code is clean and secure, you previously would need to switch between different linters or Qodana instances to see the results for different projects. 

The need to switch between linters can make the code review process convoluted and inefficient, and we’ve developed Qodana Cloud to address precisely this problem. Qodana Cloud collects all the data from different Qodana linters in a single place and allows you to drill down into particular issues with interactive dashboards. 

Here is how you can benefit from Qodana Cloud:

Get deeper insights into your projects’ trends

With the ability to aggregate reports from different sources in one view, you can discover trends and patterns in your code across all projects and get a better understanding of how your project or the whole team is performing. This way, developers will no longer code in silos, instead seeing the same list of issues. This also makes it easier for managers to track progress for the whole organization.

You can create separate organizations, teams, and projects in Qodana Cloud and assign a single team to several projects for convenient navigation. In addition, you achieve more transparency thanks to widgets updating in real time.

In each project, you can also see a history of previous results and compare the results of quality checks between commits. You can examine the absolute number of problems detected or compare the number of problems against a baseline – a snapshot of the codebase problems taken during a specific Qodana run.

Open problems detected by Qodana in your favorite IDE

If you are already a Qodana user, you might know that you can open issues spotted by Qodana right in your IDE. And now this feature works for Qodana Cloud, too! This means you can fix server-side errors in the editor the same way you work with other suggestions given by the IDE. 

Here’s how it works:

What’s especially important about Qodana being bundled with JetBrains IDEs is that you run resource-intensive checks outside of your development environment without hurting your IDE’s performance. In the example above, Qodana spotted a chance that a variable could be null and cause a runtime exception. This is a severe issue, but users tend to switch off such inspections for the sake of saving resources.

In fact, that’s one of the reasons why we at JetBrains created Qodana, to ensure that you no longer have to choose between code quality and IDE performance! 

Plan your work better

Split big projects into small steps! Switching to a newer version of a language or framework, or getting rid of a certain utility or pattern, can be a cumbersome task – especially if you are working on a big project involving many developers and QA engineers. 

In Qodana Cloud, you can build a report to evaluate all pieces of code requiring modification and select issues to add to the baseline – otherwise known as the technical debt section. This way, the whole team can see the same list of issues and monitor progress with an interactive Qodana dashboard.

Choose the dark or the light side

In the design world, dark mode is the new black. Who are we to ignore that? To ensure you have a good experience with Qodana Cloud, we’ve provided the option to manually choose the dark or the light theme or have the UI sync automatically with your system preferences.

What’s coming next?

In future releases, we will add role-based access control so that you can grant different permissions based on a user’s responsibilities. For example, perhaps your legal team only needs the ability to view reports about licenses used in a product, or your security team needs to see a list of vulnerabilities in the codebase. You will be able to create custom roles for them with permissions that are specific to their tasks. We are also working on implementing more security controls and allowing quick-fixes for certain types of issues.

Follow us on Twitter or subscribe to the blog for updates.

How to get started with Qodana Cloud

To get started, go to qodana.cloud and log in with your JetBrains Account. Alternatively, as a non-registered user, you can explore demo projects that were already analyzed by Qodana Cloud to see it in action.

To pull your inspection reports from other Qodana instances into the cloud, Qodana Cloud will generate a token for you to set into your project in your CI tool. For detailed instructions, see our documentation.  

Project setup

Setting up a project in Qodana Cloud takes five simple steps: 

1. Trigger the first run. First, Qodana analyzes your project using vital checks only. It will identify the number of files and folders containing problems, the languages used, and other important info about your project. 
2. Customize your analysis. Next, Qodana offers you the option to enable extra inspections that might be critical for your analysis. 
3. Narrow the analysis down. You can then exclude certain files and folders from the analysis.
4. Create technical debt. Our favorite part is the ability to add detected problems to the baseline, allowing you to get back to them when you have time.
5. Apply the inspections throughout the project. To apply the selected settings to your project, download qodana.yaml and qodana.sarif.json, put them in the root folder, and restart Qodana.

That’s all for now! If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Happy developing, and keep your code clean!

Read on to learn more and become an early adopter of some exciting new features!

GET STARTED WITH QODANA

Our brand new linters bring all of the smarts from Rider and GoLand to enable you to spot anomalous code and potential bugs, eliminate dead code, improve the overall code structure, and introduce coding best practices across all of your .NET and Go projects!

Qodana for .NET

Qodana supports almost all .NET inspections provided by Rider. Since there’s a long list of them, check out the Rider documentation to learn more about all of the inspections. Meanwhile, a few examples of the .NET inspections that Qodana can run are below.

Inconsistent lock ordering

One of the main issues when using locks to achieve thread safety is avoiding deadlocks, i.e. when threads simultaneously block each other from continuing execution, so no progress is made. With this new inspection, Qodana will highlight cycles leading to possible deadlocks at runtime.

Access to modified captured variable

Qodana for .NET detects access to the captured variable from an anonymous method when the variable is modified externally.

Avoid using ‘async’ lambda when delegate type returns ‘void’

This inspection spots the usage of ‘async’ lambda expressions: any exceptions unhandled by the lambda will never affect the caller thread and will not be caught with the catch clause.

Type check and casts can be merged

The type-testing is operator in its classical form (Expression is Type) returns true only when the runtime type of Expression is compatible with Type and the result of Expression is not null.

When we use is to check the compatibility before casting, like in the example below, we encounter at least two problems:

• We perform the type check twice for no reason, which can affect performance if we do it inside a loop.
• The fact that the program execution will not get into the if statement if obj is null is not immediately clear to those who read this code.

Qodana will spot this issue and suggest you fix it right in Rider.

Lambda expression/anonymous method should not have captures of the containing context

The lambda expression/anonymous method passed to a parameter annotated by the ‘[RequireStaticDelegate]’ attribute must not have captures of the containing context (local variables, local functions, ‘this’ reference) to avoid heap allocations.

To configure the linter for .NET and run analysis, please refer to the Qodana documentation.

Qodana for Go

Qodana 2022.3 is designed to support all inspections provided by GoLand. To see the exhaustive list, please refer to the GoLand documentation. Below are examples of some of the Go inspections that Qodana now supports.

Placeholder argument ‘d.DeletedCount’ has the wrong type ‘int64’ (%s)

This inspection reports incorrect usages of fmt.Printf, fmt.Println, and similar formatting and printing functions.

In their format strings, formatting functions use formatting verbs, like %s, %d, %v, and others.

If formatting verbs are used incorrectly, the result of a formatting function will contain an error.

Unhandled error

This inspection reports calls to functions and methods that do not handle the call result of the error type.

An API of such functions implies that their execution might finish unsuccessfully and they would return an error. Calls that do not handle the error result could be an indication of misuse of the API.

Unused dependency

This inspection reports unused dependencies on your project. It’s good practice to scan for unused dependencies on a regular basis, as it reduces the library size of your project and improves maintainability.

To see Qodana in action and play around with these new inspections, feel free to jump into our documentation and see how to configure linters for Go.

New inspections

Besides adding new linters for .NET and Go, Qodana 2022.3 also brings you over 100 new inspections for the existing linters. Let’s take a look at the most prominent examples of inspections for Java, Kotlin, and Python.

Java and Kotlin inspections

We’ve added over 40 new inspections to Qodana for JVM Community and Qodana for JVM.

DataFlowIssue

This inspection reports code constructs that always violate nullability contracts, may throw exceptions, or are redundant, based on data flow analysis.

EscapedSpace

Java 15 introduced the string escape sequence \s to make trailing whitespace in text-blocks visible. In most other contexts, especially in regular expressions, this escape sequence can easily be confused with the \s of a regular expression meaning whitespace. In Java string literals it has to be written as "\\s" instead.

MismatchedJavadocCode

This inspection reports cases in which the Javadoc of a method obviously contradicts the method signature, such as the comment saying “returns true” when the method returns a string.

Destructure

This inspection reports declarations in Kotlin that can be destructured.

UnresolvedRestParam

Now Qodana can detect inconsistent method declarations in REST services (such as @PathParam parameters that don’t match a placeholder from the @Get annotation), as these would throw exceptions at runtime. 

ReactiveStreamsThrowInOperator

This new inspection spots throw statements in Reactor/RxJava operator code instead of returning designated error values, which prevents the errors from being processed further. For example, it ignores them or replaces them with a fallback value.

Please, note that this version of Qodana also brings all of the new inspections for Android from IntelliJ IDEA 2022.3 and Android Studio – Electric Eel | 2022.1.1.

Python inspections

We’ve also added some inspections for the Google App Engine to Qodana for Python that will highlight issues before they cause failures in production environments. For example, now you can spot:

• GQL queries that  do not comply with restrictions for queries allowed on the Google App Engine server.
• GQL queries without indexes.
• Usages of Python features that are restricted by the Google App Engine sandbox.
• Сases when threadsafe is not enabled with the CGI handler.

To exclude certain inspections from your analysis, you can customize your default inspection profile or create a brand new one. You may also want to ​​enforce inspections that are important to your coding guidelines. Check out our Qodana documentation for more information.

That’s everything about Qodana 2022.3 EAP! We hope you enjoy this new release. If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Happy developing and keep your code clean!

Your Qodana team

GET STARTED WITH QODANA

More CIs to run Qodana with

Qodana already has plugins for Azure Pipelines, GitHub Actions, and TeamCity. Starting from 2022.2, we’ve prepared a CircleCI Qodana orb that allows you to set up code inspections quickly and easily with your CircleCI projects.  

Also, it’s easy to set up Qodana in GitLab, Jenkins, or any other CI that supports running Docker images.

New inspections

Regular expressions

Regular expressions are widely known for their complexity, intricate syntax, and sometimes verbosity. To make life easier, we’ve added new inspections in this area. Previously these inspections were available only for Java, but we’ve now made them available for all languages. 

Simplified regular expressions

A regular expression like [\wa-z\d] can be simplified to just \w since \w already includes a-z as well as the digits.  It helps improve the code’s overall readability.

Suspicious backreferences 

A regular expression like \1(abc) cannot match anything. This is because the \1 refers to the abc that is not yet defined when evaluating the \1. This inspection prevents simple typos in regular expressions and speeds up the editing experience. 

Redundant \d, [:digit:], or \D class elements

The regular expression [\w+\d] can be written as [\w+], as the \w already includes the \d. It helps improve the code’s overall readability.

Markdown support

Incorrectly numbered list items

Ordered list items like 1. 2. 4. are marked as being inconsistently numbered. In the rendered Markdown, the list is still displayed as 1. 2. 3., but the inconsistency makes editing the source code harder.

Java, Kotlin, and Android inspections

We’ve added and reorganized inspections in the categories: Javadoc, DevKit, Markdown, Kotlin language, style, architectural patterns, performance, and JUnit support. Here are a couple of examples from the JUnit set.

JUnit: Malformed Declaration

Reports the JUnit test member declarations that are malformed and are likely not to be recognized by the JUnit test framework. Declarations like these could result in unexecuted tests or lifecycle methods.

JUnit: Unconstructable TestCase

Reports JUnit test cases that can’t be constructed because they have an invalid constructor. Test cases like these will not be picked up by the JUnit test runner and will therefore not execute.

Those examples you can see live on our public TeamCity instance. Please use the Guest login to enter. Other inspections are described in our documentation.

PHP inspections

We added inspections in Probable bugs, Documentation, Style, Testing, and Laravel categories, for example:

Probable bug: Number ranges mismatch

In a function that is declared with returns int<0,10>, marks return statements that return a number outside this range. Similarly for fields, field constructors and function calls. 

Documentation: Type tag without variable name

The PHPDoc snippet @param string is redundant as it doesn’t say what is a string. It should be either removed or replaced with @param string $argument, saying that argument is a string. 

Blade: Parse error due to unpaired parentheses in string literals

Early detection of unpaired parentheses in string literals that are later parsed by Blade, a template engine.

To include or exclude certain inspections from your analysis, you can customize your default inspection profile or create a brand new one. You may also want to ​​enforce inspections that are important to your coding guidelines or best practices. Check out our Qodana documentation for more information. 

If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Your Qodana team

License audit has been an extra linter that had to be configured separately from the main linters. It now comes with Qodana out of the box. We also added a bunch of new and useful inspections for PHP and JVM linters. Read on to learn more!

GET STARTED WITH QODANA

License audit

Legal and compliance penalties for invalid or inappropriately used licenses in your code can be extremely costly. With Qodana, you can scan dependencies in your code repository to find their licenses and see whether there are any potential issues.

With this release, we’ve made it easy to bring license auditing into your project and make it a part of your CI/CD pipeline. The new License audit feature is available for all linters, including Python, Java, Kotlin, PHP, and JavaScript.
To enable License audit, add the following lines to the qodana.yaml file in your project root:

include:
  - name: CheckDependencyLicenses

If you need to ignore a specific dependency in your project, add the following lines:

dependencyIgnores:
- name: "dependency/name"

Read our documentation for more information about custom configurations for License audit and check out this blog post to see how it can streamline working routines for developers, managers, and legal teams.

PHP inspections

This version of Qodana brings all of the new inspections from PhpStorm 2022.1 and adds them to your pipeline with our PHP linters. PhpStorm comes bundled with Qodana, so when Qodana notifies you about an issue in your code, you can open it right in your IDE for further investigation.

Duplicate array key

The behavior of array_merge() and merging with the + operator are different from each other in PHP. The latter will not override the value if the key is duplicated. This can lead to confusion and bugs, so Qodana for PHP now highlights such cases.

Usage of count($array) as array index

When appending an item to an array, there is no need to explicitly specify the index. Qodana for PHP can warn you about the redundant count() call.

Replace pow() call with **

PHP has had an ** exponentiation operator available since version 5.6. Qodana for PHP will suggest a quick-fix right in PhpStorm (Alt+Enter) to replace the old pow() calls with the ** operator.

Read-only properties

Private properties with read-only access inside a class can be declared with the readonly flag. Qodana for PHP will suggest updating the property declaration.

Final class constants

Starting with PHP 8.1, it is possible to declare constants as final. This is why Qodana for PHP will warn you about constants that are not inherited and suggest adding a final modifier to them. With the PhpStorm integration, you can quickly jump to the IDE to fix the issue.

rand function arguments in reverse order

This inspection highlights function calls from the rand family where the max argument can be less than the min. For example, calling rand(10, 1) is the same as calling rand(1, 10), but mt_rand() is strict about the order of its arguments.

Invalid mock target with PHPUnit

Qodana for PHP will warn you when you try to access a private or final method on a mock object.

Redundant modifier

This new inspection will report modifiers that are used in regular expression patterns but do not affect the match:

• /i (case insensitivity) in patterns that contain no letters.
• /D (PCRE_DOLLAR_ENDONLY) in patterns that do not contain a dollar sign or that contain the \m (PCRE_MULTILINE) modifier.
• /s (dot matches line breaks) in patterns that contain no dots.

Unsupported modifier

This inspection will report usages of the /e modifier, which is deprecated in PHP versions 7.0 and later.

Java and Kotlin inspections

This release also adds new inspections from IntelliJ IDEA 2022.1 to Qodana for JVM. With our IntelliJ IDEA integration, if any issues are found, the erroneous code can be opened right in the IDE for a quick fix.

Let’s take a look at the most notable inspections.

Suspicious back reference

Qodana for JVM will find references that will not be resolvable at runtime.This means that the back reference can never match anything. A back reference will not be resolvable when the group is defined after the back reference, or if the group is defined in a different branch of an alternation.

‘InputStream’ and ‘OutputStream’ can be constructed using ‘Files’ methods

This inspection reports FileInputStream and FileOutputStream constructors when they can be replaced with Files.newInputStream() and Files.newOutputStream(), respectively. Streams created using Files methods are usually more efficient than those created by stream constructors.

Bulk ‘Files.readAttributes’ calls can be used instead of multiple file attribute calls

This inspection finds places where multiple java.io.File attribute checks, such as isDirectory, isFile, lastModified, or length, are used in a row. These calls can be replaced with a bulk Files.readAttributes call. The bulk method is usually more performant than multiple attribute checks.     

Loop can be replaced with ‘List.replaceAll()’

This inspection reports loops that can be collapsed into a single List.replaceAll() call.

Number of placeholders does not match the number of arguments in logging call

Qodana for JVM will report SLF4J or Log4j 2 logging calls, such as logger.info(\"{}: {}\", key), where the number of {} placeholders in the logger message doesn’t match the number of other arguments in the logging call.

Regular expressions can be simplified

This inspection detects regular expressions that can be simplified.   

To exclude certain inspections from your analysis, you can customize your default inspection profile or create a brand new one. You may also want to ​​enforce inspections that are important to your coding guidelines or best practices. Check out our Qodana documentation for more information.

That’s all that is new in Qodana 2022.1! We hope you’ll find our release blog posts useful. If you have any suggestions for future blog topics or if you want to learn more about how Qodana can help you and your business, post a comment here, tag us on Twitter, or contact us at qodana-support@jetbrains.com.

Your Qodana team

License compliance is a must

The GNU General Public License (GNU GPL or simply GPL) is a series of widely-used, free software licenses that guarantee end users the freedom to do four things with their software: run, study, share, and modify it. With the GPL gaining more popularity and being actively used in legal cases, keeping track of licenses is becoming a must for organizations of different sizes and verticals.

Inappropriate use of the GPL can potentially land businesses in legal trouble if they use code in the wrong way, deliberately or otherwise. For example, CoKinetic Systems Corporation, one of the major global players in the in-flight entertainment market, filed a suit against Panasonic Avionics Corporation in a New York federal court, seeking damages of over $100 million. CoKinetic claims that Panasonic willfully violated GPL open source licensing requirements. There are many other cases like Welte vs. Fantec or Linksys vs Free Software Foundation where a company or organization neglected license auditing and had to suffer the consequences.

Regardless of whether you do all your own software development or outsource parts of it, if a piece of unlicensed code ends up in your product, you cannot afford to miss it. So how confident are you that your projects have no licensing issues?

Manual license detection

Working with countless licenses means that it’s nearly impossible for developers, legal departments, or security teams to track them all. Organizations can try forcing each and every developer to run a dependency analysis on their projects manually. But how do you ensure no one misses anything? This is especially relevant when teams are under time pressure to release new features and improvements.

When manual license detection is used, you can’t rule out the possibility of accidentally importing a restrictive-licensed library into a software codebase or forgetting to update an expired license. If you don’t spot and mitigate such issues in a timely manner, it can lead to major lawsuits, financial losses, reputational damage, and loss of client trust.

Automate license auditing with Qodana

To automate the process of detecting incompatible third-party licenses and mitigating legal, financial and reputational risks, we announced the EAP for License audit in Qodana, the code quality platform from JetBrains. Until now, License audit has been an extra linter that had to be configured separately from the main linters. With this release, License audit becomes one of the essential Qodana linters. Now you can take advantage of License audit by getting Qodana for your programming language of choice: Qodana for Java, Qodana for Kotlin, Qodana for PHP, and Qodana for JavaScript.

Get Started With Qodana

For developers

Qodana lists dependency licenses in an analyzed repository and warns you about any problems concerning their compatibility with the project licenses. Whenever a new library is added to your project or an existing one unexpectedly changes its license, Qodana will alert you to this so you don’t miss any important license adjustments.

With the IntelliJ IDEA integration, all issues detected by Qodana can be opened right in the IDE, meaning you can fix them right away. Qodana is also bundled with PhpStorm and can be easily integrated with any other JetBrains IDE.

For legal and compliance teams

Qodana’s License audit provides a report of permitted and prohibited licenses. The report is always up-to-date so you can quickly share it with the compliance and legal departments or have employees access it directly. Qodana will also notify you about license updates. This slashes time and effort in preparing for audit checks and proving GPL compliance.

For managers

Qodana integrates with GitHub, GitLab, TeamCity, Jenkins and other CI/CD pipelines, so you can make license auditing an essential part of your release process and mitigate compliance risks before your code goes to production.

See License audit in action

We’ve created a playground that allows you to see Qodana in action. To open it, select the Login as guest option and check our License Audit Examples project.

To learn more about Qodana’s License audit, check out our documentation.

If you have any questions or suggestions regarding Qodana, post a comment here, tag us on Twitter or contact us at qodana-support@jetbrains.com.

Your Qodana team

Running tests automatically

Automated tests haven’t been run locally in what feels like ages. These days, CI/CD pipelines run tests automatically as one of their main functions.

Pipeline configuration can be assigned to DevOps. But then we will be a long way from making use of CI/CD’s second function: quality control, or more precisely, “quality gates”.

Quality control using quality gates

But what are quality gates? Let’s say the product code is like a castle. Every day, developers write new code – which could weaken the foundations of our castle or even poke holes in it, if we are really unlucky. The purpose of a QA engineer is to test each feature and reduce the likelihood of bugs finding their way into product code. Lack of automation in the QA process could cause QA engineers to lose sleep, since there is nobody to watch over all the various metrics – especially at dangerous times, like Friday evenings when everyone wants to leave work and is hurrying to get everything finished. An ill-fated merge at that moment can cause a lot of problems down the road.

This problem can be solved by building in quality checks.

Each check deals with a different important metric. If the code doesn’t pass a check, the gates close and the feature is not allowed to enter. A feature will only be merged into the product when it passes all the checks and potential bugs have been prevented.

What quality checks can be included in CI/CD?

We need to put together a list of checks to ensure that the process is as automated as possible. They can be sequenced in “fail first” order. A feature needs to pass all the checks to get through the pipeline successfully. The initial checks are the ones that make sure the app is capable of working: build, code style check, and static analysis. 

“Build” speaks for itself: if the app cannot be built, the feature does not progress. It is important to incorporate a code style check into your CI/CD pipeline to ensure the code meets unified requirements, as doing so allows you to avoid wasting time on this kind of bug during code reviews.

Static analysis is an extremely important tool for judging code quality. It can point out a huge number of critical errors that lead to bugs.

We then continue with stage-two checks: unit tests with coverage analysis and coverage quality control, as well as integration and systems tests. Next, we review detailed reports of the results to make sure nothing was missed. At this stage we may also perform a range of non-functional tests to check performance, convenience, and security, as well as screenshot tests. 

When developing a pipeline, we need to pay attention to two competing requirements: 

• The pipeline must guarantee the best possible feature quality in light of your needs.
• Time spent running the pipeline should not slow down your workflow. It should generally take no more than 20 minutes.

Examples of tools to incorporate in quality checks

Code style highlighting

A code style is a set of rules that should be followed in every line of code in a project, from alignment rules to rules like “never use global variables”.

You might be wondering what style has to do with testers. The answer is a lot, actually. A style check provides several benefits for QA experts, not to mention the rest of the team:

• A unified style helps developers work with the code and gives them more time to implement new features and fix bugs.
• A unified style allows you to dispense with manual code checks and use a CI/CD tool to run the checks instead. 

Large companies usually have their own style guides that can be used as examples. For instance, Airbnb has a JavaScript style guide and Google has a number of guides. You can even write your own.

The choice of tools for code checking depends on the language. You can find a suitable tool on GitHub or find out which tools other teams are using. Linters use bodies of rules and highlight code that fails to abide by them. Some examples include ktlint for Kotlin, checkstyle for Java, eslint for JavaScript.

Static code analysis

Static code analysis is a method of debugging by examining source code without executing a program. There are many different static code analyzers on the market. We’ll take a look now at a platform we’re developing ourselves – Qodana. The major advantage of this code analyzer is that it includes a number of inspections that are available to us in JetBrains development environments when we’re writing code.

Many of you probably use an IDE-driven approach, where the IDE helps you write code and points out various bugs such as suboptimal code usage, NullPointerExceptions, duplicates, and so on.

But unfortunately, you can never be sure all the critical problems found by the IDE were fixed before the commit. One way you can guarantee that all the problems will be addressed is by incorporating Qodana into your CI/CD pipeline. If you can’t fix everything at once, you can select critical problems, add them to the baseline, and gradually work your way through the technical debt. This allows you to avoid slowing down the development process while keeping the problems that have been found under control.

Test coverage

Code coverage is a metric that helps you understand how well your code has been covered by your tests (generally unit tests).

Here you need to define the minimum coverage percentage that you want to support. The code won’t be able to go live until it has been covered sufficiently by the tests. The minimum percentage is established empirically, but you should remember that even 100% coverage may not completely save your code from bugs. According to this article from Atlassian, 80% is a good figure to aim for.

Different coverage analyzers are available for different languages, such as Jacoco for Java, Istanbul for JavaScript, or Coverage.py for Python. You can build all these analyzers into your CI/CD pipeline and track the metrics with ease.

Shaping the release process

In addition to automatically running tests and ensuring particular code quality requirements are satisfied, CI/CD lets testers organize the release process.

The release process can be complex and can depend on a lot of different manual actions. It is often a completely manual process: the artifact is created by a developer, then passed to the testers for checks, and finally comes to the person who knows how to roll it out for the go-live. Once again, there are a lot of potential choke points here. For instance, one of those people could fall ill or go on vacation. 

An effective release process will look different for each team, but it will generally include the following steps: 

1. Each change in the Git branch triggers a build of the app.
2. The build undergoes quality checks and does not become part of the main branch until it passes all the checks successfully.
3. A release candidate is taken from the release branch or the main branch: this fixes the version and guarantees that nothing will go live unless it has been tested and has not been changed afterwards. This helps with tracking releases and all the changes they include. In addition, by storing artifacts of the stable version, you make it possible to revert to them quickly in the event of an unsuccessful release.
4. The release candidate is tested and undergoes final checks.
5. The release candidate goes live. This may be either a manual pipeline launch or an automated launch, if the release candidate passed all the checks at the preceding stage. The choice between an automatic release process and a manual one will depend on how frequent and how important the releases are, as well as the preferences among team members and the convenience of the rollout.

Any CI/CD system allows you to set up this kind of process. The process should be convenient for the whole team, including the testing team.

Given the factors outlined above, we believe following these basic rules will help ensure an easy and efficient release process:

• Artifacts must be ready for download and testing, ideally all in one place.
• As many checks and tests as possible must be automated. They should take place without human intervention.
• All complex operations with builds should be as automated as possible.
• All builds that will go live should be recorded and remain available for a certain period after release. This will help if you need to investigate errors in the production version, reproduce bugs, or just track the history.

We would also like to remind you that if quality metrics are not controlled automatically and do not affect anything, they are useless, as there’s no way to guarantee that these metrics will be adhered to. 

Implement pipelines, automate processes, and use static code analysis!

Your Qodana team

Try for free

Qodana linters are now integrated into your Azure DevOps repositories to allow you to make code analysis a part of your build pipeline and ensure the maintainability and reliability of your projects. You can integrate Qodana with Azure Pipelines in just 2 steps:

• Install Qodana for Azure Pipelines
• Configure Qodana to analyze your code

Now let’s dive into the details.

Install Qodana for Azure Pipelines

From Visual Studio Marketplace, install the Qodana for Azure Pipelines extension by clicking the Get it free button, and Proceed to organization once the installation has finished.

If you do not have the required permissions to install an extension from the marketplace, a request will be sent to the account administrator to ask them to approve the installation.

Configure Qodana to analyze your code

Set up a pipeline that integrates with Qodana

Before analyzing your code, you will first need to set up a new build pipeline that integrates with Qodana. On the Azure DevOps panel, go to Pipelines and click Create Pipeline. If any pipelines have already been created, select New pipeline.

You can configure the pipeline with either the YAML editor or the classic editor. When using the classic editor, you can take advantage of the predefined templates. The YAML editor requires you to use a YAML file. Let’s choose the latter for this example.

The YAML editor will open with the template YAML file. In order to configure it correctly you will need to configure the Qodana Scan task by editing your azure-pipelines.yml file:

# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - task: Cache@2  # Not required, but Qodana will open projects with cache faster.
    inputs:
      key: '"$(Build.Repository.Name)" | "$(Build.SourceBranchName)" | "$(Build.SourceVersion)"'
      path: '$(Agent.TempDirectory)/qodana/cache'
      restoreKeys: |
        "$(Build.Repository.Name)" | "$(Build.SourceBranchName)"
        "$(Build.Repository.Name)"
  - task: QodanaScan@1

You can also find the Qodana Scan task in the list of tasks on the Show assistant panel.

​​Run your pipeline

When you are done making the changes to the file, click Save and Run.

See the results

To display the Qodana report summary in Azure DevOps, install Microsoft DevLabs’ SARIF SAST Scans Tab extension. Once installation is done, go to the Pipelines tab, select the pipeline being run and analyzed, and look at the Scans tab for more information about the quality of your code.

With the Qodana for Azure Pipelines extension, you will be able to easily integrate Qodana into your Azure DevOps pipeline and start seeing the analytics the first time your code is checked.

If you have any questions or suggestions about Qodana, post a comment here, tag us on Twitter or contact us at qodana-support@jetbrains.com.

Your Qodana team

• Automate code reviews
• Stay confident with external contributions
• Slash time spent on project planning
• Static analysis with Qodana in your project lifecycle

Automate code reviews

According to the Active State Developer Survey 2019, 61.5% of developers spend four hours or less a day writing code. One of the tasks contributing to the non-coding time is code reviews. The main goal of this process is a direct discovery of quality problems. In many projects, quality means:

1) flawless business logic implementation;

2) elements related to the maintainability of the code: design pattern, naming strategies, code style, etc.

If the process is purely manual, the reviewer should care about both aspects. It can be error-prone and time-consuming. For example, try to spot a deficiency in the code related to the regular expression:

It couldn’t be easy for you, but it’s a trivial task for a static analysis tool. It’s just one example. You can automate many checks for unused imports, dead code, duplicates, spelling problems, formatting issues, and many more – any rules of your choice. For example, if you use TODO’s in the comment, you can automatically check that each of them contains a reference to the issue tracker, as some teams in JetBrains do.

Those checks configured in the editor guide developers, but this guidance becomes a mandatory rule with the server-side static analysis. The server-side quality gate will ensure the code meets specific standards before it moves onto the next phase, like manual code review or deployment to production. The author and the reviewer will spend less time in the feedback loop. Also, you will have a track record for proofs and further analysis.

Stay confident with external contributions

Code reviewing is good practice, even if all team members are equally skilled, accurate, and have a shared understanding of the code quality. Even professional climbers need belays, don’t they? And a belay becomes vital if you don’t know the actual skill level of the contributor. Accepting an external contribution to your project is precisely the case when you need an additional guarantee that the contributor follows your guidelines. It can be a pull request to the open-source project or tasks you delegate to the subcontractor – the automatic code review will perform routine checks so you can focus on business value.

Slash time spent on project planning

With server-side static analysis, you can review the created code and plan your code evolution steps. Imagine you want to switch to a newer version of the language or framework. If you’re lucky, you update your dependencies, and your project is up and running. In a less fortunate scenario, you update your dependency, and the IDE highlights tons of places you need to update. 

For big projects, the number of changes could be so large that you will need several people to succeed. How will you split the work between them? Static analysis platforms can build a report to split the work between people and estimate the outcome. This goes for any refactoring you need for your code. For example, with checks based on structural searches, you can evaluate all places that require your attention. Technically, this analysis can be done on the developer’s machine, but there will be no option to share the list of issues and track the progress with others.

Static analysis with Qodana in your project lifecycle 

Qodana, the code quality platform from JetBrains, empowers you and your team to leverage the benefits of a static analysis tool while integrating with your favorite CI/CD pipelines – TeamCity, GitLab, GitHub, and others. The picture below illustrates a typical software build process employed during the software development life cycle and how Qodana can be integrated with this process.

To get started with Qodana, check our previous blog post for detailed instructions, or download the version of the components that are suitable for your technology stack:

• Qodana for JVM
• Qodana for JS (EAP)
• Qodana for PHP (EAP)
• Qodana for Python (EAP)

Visit jetbrains.com/qodana for more information. We would be grateful for any feedback you might have, and all ideas are welcome! Contact us at qodana-support@jetbrains.com or via our issue tracker.

Your Qodana team