Forem: Gustavo Silva

Code coverage best practices (Part I)

Gustavo Silva — Wed, 26 May 2021 11:49:33 +0000

Hey all 👋, here's a two-part series about code coverage best practices. We hope you like it.

It’s not easy being a software engineer — even though we’re trying to do our best, chances are we mess up from time to time. Let’s minimize those mess-ups!

In this first post, we’re going to take a closer look at the concept of code coverage itself — what it is, why is it important, and how can it be used to optimize your code.

The basics of code coverage

As a programmer, we can’t just write code and and hope every line is flawless — we’re bound to make mistakes, and that’s why testing is such a critical part of the development workflow.

In the most basic sense, code coverage is a way of using analytics to get an idea of how well an application has been tested. Our tests might return positive results across the board, but if they only cover 30 percent of the code it’s hard to be confident about the end product.

That’s where code coverage comes in — the higher the value, the better, as a more thoroughly tested application generally has less show-stopping bugs or other flaws.

Calculating code coverage

There are a couple of ways to determine how well the code is covered by the tests we run. These various metrics offer a different perspective on our code quality, and it’s useful to know the basics of each of them — that’s why we’ll run them down for you.

Statement coverage

At the heart of code coverage there’s statement coverage, which checks how many statements in your program have been executed. This is the most widely used form of code coverage as it is found in most of the relevant code coverage tools.

Function coverage

Another fairly basic example of code coverage. Especially important in applications that rely on a large number of functions, this coverage metric focuses on how many of the declared functions have been called during testing.

Branch coverage

As a higher-level way of checking our code, the main reason to use branch coverage is to see how many branches of every control structure have been properly executed. If a program is able to jump, it should jump to all possible destinations — if there’s an ‘if’ statement, it checks if both the ‘true’ and ‘false’ branches have been executed.

If the tests achieve full branch coverage, our app is protected against errors in all branches, which means that 100 percent branch coverage also indicates 100 percent statement coverage.

Condition coverage

This metric looks at the various boolean sub-expressions in our code and if they were tested for both ‘true’ and ‘false’. Because expressions can get complicated, it’s hard to achieve 100 percent condition coverage — that’s why there are multiple ways of reporting this metric, all of which focus on covering the most important combinations.

Other kinds of coverage

While these are the most important metrics, there are others to keep in mind when thinking about code coverage for our testing. One of these is decision coverage, which is a combination of function coverage and branch coverage that checks if all entry and exit points, and all decisions and outcomes have been invoked at least once. Another metric is multiple condition coverage, which requires all combinations of conditions inside decisions to be tested, effectively looking for full decision and condition coverage.

Then there’s a host of less-important coverage metrics like linear code sequence and jump coverage, path coverage, entry/exit coverage, loop coverage and stage coverage. Because this article is meant to only offer a look at the basics of code coverage, we won’t dive into these — but it’s still good to know they exist.

How to apply code coverage

All in all, code coverage is an important way to see if our tests are comprehensively covering our code. In a large company the above metrics would be used by a team of Quality Assurance employees, but for startups and solo developers we should be looking out ourselves.

It’s vital, however, that we stay critical of our code even when we achieve 100 percent coverage on the various metrics — while it can be a great way to indirectly check its quality, it relies on knowing what to test in the first place.

In the next article of this two-part series we’ll take a look at how to set up code coverage in Codacy, and how it offers a smart way to analyze our code.

PostgreSQL: How to update large tables

Gustavo Silva — Tue, 11 May 2021 10:24:16 +0000

Updating a large table in PostgreSQL, an advanced open-source database management system, is not straightforward. If you have a table with hundreds of millions of rows you will find those simple operations, such as adding a column or changing a column type, are hard to do in a timely manner.

Doing these kinds of operations without downtime is an even harder challenge. In this blog post, we'll try to outline guidelines and strategies to minimize the impact on table availability while managing large data sets.

General Guidelines For PostgreSQL Table Updates

When you update a value in a column, Postgres writes a whole new row in the disk, deprecates the old row, and then proceeds to update all indexes. This process is equivalent to an INSERT plus a DELETE for each row which takes a considerable amount of resources.

Besides this, here is a list of things that you should know when you need to update large tables:

It is faster to create a new table from scratch than to update every single row. Sequential writes are faster than sparse updates. You also don’t get dead rows at the end.
Table constraints and indexes heavily delay every write. If possible, you should drop all the indexes, triggers, and foreign keys while the update runs and recreate them at the end.
Adding a nullable column without a default value is a cheap operation. Writing the actual data of the column is the expensive part.
Data stored in TOAST is not rewritten when the row is updated
Converting between some data types does not require a full table rewrite since Postgres 9.2. Ex: conversion from VARCHAR(32) to VARCHAR(64).

Strategies To Update Tables In PostgresSQL

With this in mind, let’s look at a few strategies that you can use to effectively update a large number of rows in your table in PostgreSQL:

1. Incremental updates

If you can segment your data using, for example, sequential IDs, you can update rows incrementally in batches. This maximizes your table availability since you only need to keep locks for a short period of time. When adding a new column, you can temporarily set it as nullable then gradually fill it with new values.

The main problem with this approach is the performance. It is a very slow process because in-place updates are costly. It may also require more complex application logic during the migration.

2. Create a new table

The fastest way to update a large table is to create a new one.

If you can safely drop the existing table and if there is enough disk space. Then, the easiest way to perform the update is to insert the data into a new table and rename it afterward. Here is a script with the base structure for this operation:

CREATE TABLE new_tbl
(
  field1 int,
  field2 int,
  ...
);
INSERT INTO new_tbl(field1, field2, ...)
(
  SELECT FROM ... -- use your new logic here to insert the updated data
)
CREATE INDEX -- add your constraints and indexes to new_tbl
DROP TABLE tbl;
ALTER TABLE tbl_new RENAME TO tbl;

3. Recreate the existing table

Even with the aforementioned optimizations, recreating your table in PostgreSQL is a slow operation. If you are running the queries in a live database you may need to handle concurrent write requests.

The easiest way to do this is to force a SHARE LOCK on the table during the transaction:

LOCK TABLE tbl IN SHARE MODE;

All the write requests will wait until the lock is released or timeout if it takes too long. The requests that did not timeout will be executed once the transaction ends if the original parent table was not dropped. Note that, even if you create a new table with the same name the requests will still fail because they use the table OID.

Depending on the nature of your write requests you can also create custom rules to store changes made. For example, you can set a rule to record the deleted rows before you start the data migration:

CREATE RULE deleted_rule AS ON DELETE
TO tbl
DO INSERT INTO tbl_deletes VALUES
(
  OLD.id
);

When the migration ends, you just have to read the IDs from tbl_deletes and delete them on the new table. A similar method can be used to handle other types of requests.

Conclusion

Once you reach a certain size, operations that were once instantaneous can take several hours to prepare and execute. At Codacy we receive thousands of write requests every minute and we manage hundreds of gigabytes of data. Developing new features and improving the database performance without hurting availability is a challenge that we try to solve every day. This article contains some of the things we learned while dealing with these problems.

The Postgresql documentation and some stack exchange answers have more in-depth information about some topics mentioned here and are worth checking if you need more details on PostgreSQL.

Feel free to ask questions and make suggestions in the comment section, we love to learn new and better ways of doing things while working at scale.

List of tools for code review engineers

Gustavo Silva — Wed, 05 May 2021 09:28:40 +0000

List of tools for code review engineers

If you perform code reviews at your company we hope that this list of tools adds value to your GitHub workflow.
We created this list on GitHub recently and we'll periodically keep adding more tools.
Feel free to contribute your suggestions.

Tool	Description
Gitpod	Gitpod is an open-source Kubernetes application for automated and ready-to-code development environments that blends in your existing workflow. It enables you to describe your dev environment as code and start instant and fresh development environments for each new task directly from your browser.
Pull Reminders (from Pull Panda)	Review and merge pull requests faster with Slack reminders and notifications.
Pull Assigner (from Pull Panda)	Pull Assigner assigns code reviews to make your process more balanced and efficient: 1) Organize reviewers into groups using GitHub Teams 2) Assign pull requests to teams or automate it with CODEOWNERS 3) Pull Assigner auto-assigns one or more members of the team as reviewers.
Gitify	Gitify is all about making your life easier. Sitting on your menu bar, it informs you of any GitHub notifications without being annoying and of course without adverts. It just gets the job done. Works with GitHub and GitHub Enterprise. You can even connect multiple accounts.
Quests	Quests is similar to Gitify but with one important difference: Quest also supports GitLab.
DevHub	Create columns for the repositories and people that matter to you; Receive Desktop Push Notifications; Manage Notifications, Issues, Pull Requests & Activities; Bookmark things for later.
Bolt	Designed to close the gap between code development and security, Bolt helps GitHub developers create more secure products. It detects and alerts you of vulnerable open source components in your repository.
Imgbot	Imgbot is a friendly robot that optimizes your images and saves you time by leveraging the power of pull requests.

PHP Static Analysis Tools Review

Gustavo Silva — Wed, 28 Apr 2021 10:50:14 +0000

Photo by Ben on Unsplash thank you 👌

Performing PHP static analysis will help maintain your code quality over time, particularly as it becomes even harder in large projects developed by many programmers. Each person has different code styles and different ways to approach problems. Over time, this may result in confusing and unmaintainable code.

Static analysis tools can help developers solve this problem, they enforce coding standards, detect common errors, and clean up code blocks.

In this blog post, we'll take a look at the common code standards and tools used in PHP static analysis and show you how they can improve code quality and maintainability when integrated into the development process.

These are all tools you can start using today for free.
Make sure to check them for your PHP development.

Which PHP Static Analysis tool should you choose?

1: Code Sniffer

Code Sniffer is arguably the most popular tool to enforce a strict style guide in your PHP code. It ships with support for popular coding standards such as PSR2,Zend, PEAR among others. The PSR standard family is used by most people nowadays because it was created by the FIG group so if you are looking for a standard to adopt, PSR2 is a good option. Code Sniffer also allows you to create your own coding standard. In most cases this won’t be necessary, but if you are feeling adventurous you can take a look at the documentation.

Here is an example of the output generated by Code Sniffer

$ phpcs tests.php --report-full --standard=PSR2
FILE: tests.php
--------------------------------------------------------------------------
FOUND 7 ERRORS AND 2 WARNINGS AFFECTING 6 LINES
--------------------------------------------------------------------------
  2 | WARNING | [ ] Line exceeds 120 characters; contains 128 characters
  3 | WARNING | [ ] Line exceeds 120 characters; contains 139 characters
  8 | ERROR   | [ ] Each class must be in a namespace of at least one leve
  8 | ERROR   | [ ] Class name "foo_foo" is not in camel caps format
 16 | ERROR   | [ ] Method name "foo_foo::bar_bar" is not in camel caps
 23 | ERROR   | [ ] Each class must be in a file by itself
 23 | ERROR   | [ ] Each class must be in a namespace of at least one leve
 33 | ERROR   | [x] Expected 1 newline at end of file; 0 found
 33 | ERROR   | [x] A closing tag is not permitted at the end of a file
-------------------------------------------------------------------------------
PHPCBF CAN FIX THE 2 MARKED SNIFF VIOLATIONS AUTOMATICALLY
-------------------------------------------------------------------------------

As you can see, Code Sniffer shows you a detailed summary of the detected code violations. There are several output formats, so if you want a less human-readable report for parsing purposes you can output XML or CSV data. Recently they even introduced an option to output a blame report showing the percentage of errors introduced by each developer.

Although Code Sniffer can also prevent some common semantic errors, its main focus is enforcing code standards. There are other tools out there with better support for semantic error detection, but none can beat Code Sniffer when it comes to strictly follow a coding standard.

2: PHPMD

PHP Mess Detector is a multi-faceted static analysis PHP Tool based on PHP Depend. The kind of problems detected by PHPMD are divided into 5 main categories:

Code SizeAnalyses code complexity and warns you if your project is starting to become unmanageable. You can define thresholds for maximum class length, method length, cyclomatic complexity, etc.
DesignDetects software design-related issues, such as the use of eval, goto, exit, excessive coupling, etc.
NamingEnsures that your variables, class names, and method names are appropriate (not too long, nor too short). Using good names is crucial for the person reading your code, so you should not underestimate this analysis.
ControversialA few rules about naming conventions and other best practices that do not apply to every project
UnusedDetects blocks of unused code that should be cleaned

Here is an example of PHPMD’s output:

$ phpmd tests.php text ruleset
tests.php:8 The class foo_foo is not named in CamelCase.
tests.php:8 The property $my_property is not named in camelCase.
tests.php:16    Avoid unused parameters such as '$arg1'.
tests.php:16    Avoid unused parameters such as '$arg2'.
tests.php:16    bar_bar accesses the super-global variable $_POST.
tests.php:16    The method bar_bar is not named in camelCase.
tests.php:19    Avoid unused local variables such as '$some_name'.
tests.php:27    The method barBar has 11 parameters. Consider to reduce parameter number under 10.
tests.php:29    Avoid unused local variables such as '$someName'.

ruleset is a XML file which contains a list of inspections that you want to enable. You can include any of the 5 main categories and even specify which rules should be used within these categories. For more information about how to create this file you can check the documentation.

Overall, PHPMD is a highly customizable static analyzer. Although it does not enforce a specific code standard, you can use it to clean your code, detect possible bugs and manage the complexity of your project.

3: PHP Copy/Paste Detector

PHPCPD is a small tool created by Sebastian Bergmann to detect clones in your project. Here is a short example:

$phpcpd .
phpcpd 2.0.1 by Sebastian Bergmann.
Found 1 exact clones with 19 duplicated lines in 2 files:
- foo.php:9-28
    bar.php:18-37
1.32% duplicated lines out of 1439 total lines of code.

Time: 21 ms, Memory: 2.50Mb You can control the verbosity of the output and the minimum number of lines/tokens that are considered a clone.

Repeated code hides repeated bugs, therefore you should keep the percentage of duplicated lines as low as possible by refactoring the clones into a single method or class.

4: Automatic code fix

Some tools go beyond error detection and try to automatically patch the code for you.

PHP Coding Standards Fixer suggests fixes according to the coding standard you specified. The following example lists the problems found in two files:

$ php-cs-fixer fix --dry-run . --level=psr2
    1) foo.php (php_closing_tag, eof_ending)
    2) bar.php (braces, function_declaration, eof_ending)

PHPCBF is a script that can also fix some errors automatically for you. It ships with the latest version of Code Sniffer and you can run it simply like this:

$ phpcbf –standard=PSR2 tests.php Patched 2 files

Other tools

There are other tools worth checking that I would like to mention. The first one is PHPDepend, which generates an impressive set of metrics from your project code: package dependencies, cyclomatic complexity, coupling, etc. You can easily detect parts of your application that need to be refactored with this.

PHPLOC also shows interesting statistics about your project. It is not as powerful as PHPDepend, but you can also get an interesting overview of your code size, complexity, number of classes, etc.

Finally, there is Security Advisory Checker. This tool from Sensio Labs checks for security vulnerabilities in Composer dependencies. It matches your composer.lock file against a database with known security vulnerabilities and alerts you if an issue is found.

Which one should I choose?

Ultimately, this is a personal choice depending on the needs of the project you are working on. You probably want to combine more than one tool to cover a wide range of possible errors and to ensure that your code remains clean and consistent. For example, you can configure Code Sniffer with your style guide and use it along with PHP Mess Detector. This will enforce consistency and, at the same time, it will detect hot spots on your project: unusually complex code, unused code sections, short variable names, etc. On top of that, you can always add other tools to complement the analysis, such as copy-paste detector for example.

Workflow

To take the most out of static analysis you need to integrate it into your development cycle. If you use the tools independently you will forget about them after some time. There are several ways to do this.

Directly into the IDESome editors, such as PHP Storm or Sublime Text, already have plugins that support static analysis tools. After you install and configure everything you will receive warnings and suggestions as you type. This will avoid later bug fixes because it will make you write better code from the start.
Pre-commit hookIf your IDE does not support your preferred tools, of if you want stricter rules regarding commits that do not adhere to your specification, you can write a pre-commit hook in git. With this solution you can automatically abort the commit process if errors are found during the analysis.
Online analysisFinally, if you want a simple way to analyze your code without having to manually configure everything locally, you can use an online code review service such as Codacy (shameless plug here). We already integrate some of the mentioned detection tools in this article and we are working every day to improve the service. The other main benefit of using automated code review tools is to allow you to monitor issues through time and to detect new and fixed issues one commit at a time.

Conclusion

PHP has an impressive set of good tools to statically analyze your code and guide you through development. You can enforce strict standards, manage complexity and detect semantic problems, which is undeniably a great help to tackle the maintainability issue of large software projects. If your team is developing in PHP without any of this, you should give it a try. Let me know how it goes in the comments.

Local Analysis: are you getting the value you deserve from it?

Gustavo Silva — Wed, 21 Apr 2021 12:13:27 +0000

This live session is today!

Allow me to share here our first ever webinar 🎉

We'll provide an overview of static code analysis, and detail how you can set up the CLI to run code analysis on your build server.

You'll also get a better sense of the benefits and what you can achieve with a single command, as our experts, André Meira and Hélio Rocha will be showcasing the CLI tool performing analysis on the code before committing it.

What you can achieve with a single command, and how to make the most out of it; you'll get better insights on how to execute code analysis locally and its advantages.

Join us at 12 pm ET (9 am PT, 5 pm Lisbon).
Register here

An In-Depth Explanation of Code Complexity

Gustavo Silva — Wed, 21 Apr 2021 09:38:02 +0000

It’s no secret code is a complicated thing to write, debug, and maintain which is necessary for high software quality. Moreover, high code complexity brings with it a higher level of code defects, making the code costlier to maintain.

So, by reducing code complexity, we can reduce the number of bugs and defects, along with its lifetime cost. What exactly is complex code? How can we objectively assess how complex a piece of code is, whether that’s an entire codebase or one small function?

In this article, I’m going to walk through three complexity metrics for assessing code complexity. These are:

Cyclomatic complexity
Switch statement and logic condition complexity
Developer skill

I’ll also go through some of the benefits of assessing and understanding code complexity.

Cyclomatic Complexity

In 1976, Thomas McCabe Snr proposed a metric for calculating code complexity, called Cyclomatic Complexity. It’s defined as:

A Quantitative Measure Of The Number Of Linearly Independent Paths Through A Program’s Source Code…Computed Using The Control Flow Graph Of The Program.

If you’re not familiar with a Control Flow Graph:

It Is A Representation, Using Graph Notation, Of All Paths That Might Be Traversed Through A Program During Its Execution.

Said more straightforwardly, the fewer the paths through a piece of code, and the less complex those paths are, the lower the Cyclomatic Complexity. As a result, the code is less complicated. To demonstrate the metric, let’s use three, somewhat arbitrary, Go code examples.

Example One

func main() {
    fmt.Println("1 + 1 =", 1+1)
}

As there’s only one path through the function, it has a Cyclomatic Complexity score of 1, which we can find by running gocyclo on it.

Example Two

func main() {
    year, month, day := time.Now().Date()
    if month == time.November && day == 10 && year == 2018 {
        fmt.Println("Happy Go day!")
    } else {
        fmt.Println("The current month is", month)
    }
}

In this example, we’re retrieving the current year, month, and day. With this information, we then check if the current date is the 10th of November 2018 with an if/else condition.

If it is, then the code prints “Happy Go day!” to the console. If it isn’t, then it prints “The current month is” and the name of the current month. The code example is made more complicated as the if the condition is composed of three sub-conditions. Given that, it has a higher complexity score of 4.

Example Three

func main() {
    _, month, _ := time.Now().Date()

    switch month {
    case time.January:
        fmt.Println("The current month is January.")
    case time.February:
        fmt.Println("The current month is February.")
    case time.March:
        fmt.Println("The current month is March.")
    case time.April:
        fmt.Println("The current month is April.")
    case time.May:
        fmt.Println("The current month is May.")
    default:
        fmt.Println("The current month is unknown.")
    }
}

In this example, we’re printing out the current month, based on the value of month, retrieved from the call to time.Now().Date(). There are seven paths through the function, one for each of the case statements and one for the default.

As a result, its Cyclomatic Complexity is 7. If we’d accounted for all the months of the year, along with a default, however, its score would be fourteen. That happens because Gocyclo uses the following calculation rules:

1 is the base complexity of a function
+1 for each ‘if’, ‘for’, ‘case’, ‘&&’ or ‘||’

Using these three examples, we can see that by having a standard metric for calculating code complexity, we can quickly assess how complex a piece of code is.

We can also see how different complex sections of code are in comparison with each other. However, Cyclomatic Complexity is not enough on its own.

Switch Statement and Logic Condition Complexity

The next assessor of code complexity is the switch statement and logic condition complexity. In the code example below, I’ve taken the second Go example and split the compound if condition into three nested conditions; one for each of the original conditions.

func main() {
    year, month, day := time.Now().Date()
    output := fmt.Sprintf("The current month is %s", month)

    if month == time.November {
        if day == 13 {
            if year == 2018 {
                output = fmt.Sprintf("Happy Go day!")
            }
        }
    }

    fmt.Println(output)
}

Which is easier to understand (or less complicated), the original one, or this one? Now let’s build on this, by considering the following three questions.

What if we had, as we do above, multiple if conditions and each one was quite complex?
What if we had multiple if conditions and the code in the body of each one were quite complex?
Would the code be easier or harder to understand?

It is fair to say that the greater the number of nested conditions and the higher the level of complexity within those conditions, the higher the complexity of the code.

Software Developer Skill Level

What about the skill level of the developer? Have a look at the C version of the second Go example below.

#include <stdio.h>
#include <time.h>
#include <string.h>

int main()
{
  time_t t = time(NULL);
  struct tm tm = *localtime(&t);
  const char * months[12] = {"January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"};

  if (tm.tm_year == 2018 &&
      strncmp(months[tm.tm_mon], "November", strlen(months[tm.tm_mon])) == 0
      && tm.tm_mday == 10)
  {
    printf("Happy C Day!.\n");
  } else {
    printf("The current month is %s.\n", months[tm.tm_mon]);
  }
}

Technically, it does what the other examples do. However, it requires more code to achieve the same outcome. To be fair, if I had a greater familiarity with C, the code might be no longer than the Go example.

However, let’s say this is the minimum required to achieve the same outcome. If you compare the two, given the more verbose nature of C’s syntax when compared to Go, it’s harder to understand.

What’s more, if you had no prior experience with C, despite a comparatively similar Cyclomatic Complexity score, what would your perception be?

Would you consider the code to be less or more complicated? So this is another essential factor in understanding code complexity.

The Benefits of Measuring Software Complexity

There are four core benefits of measuring code complexity, plus one extra.

Better Tests

By knowing how many independent paths there are through a piece of code, we know how many paths there are to test.

I’m not advocating for 100% code coverage by the way—that’s often a meaningless software metric. However, I always advocate for as high a level of code coverage as is both practical and possible.

So, by knowing how many code paths there are, we can know how many paths we have to test. As a result, you have a measure of how many tests are required, at a minimum, to ensure that the code’s covered.

Reduced Risk

As the old saying goes:

It’s Harder To Read Code Than To Write It.

What’s more:

Code is read far more than it is written
A good software developer should never be assessed by the lines of code they’ve written (or changed), but by the quality of the code they’ve maintained.

Given that, by reducing code complexity, you reduce the risk of introducing defects; whether they’re small or large, slightly embarrassing or bankruptcy-inducing.

Lower Costs

When the risk of potential defects is reduced, there are fewer defects to find—and remove. As a result, the maintenance cost also reduces.

We’ve all seen and are familiar with the costs associated with finding defects at the various stages in a software’s life, as exemplified in the chart below.

So it makes sense that, if we understand the complexity of our code, and which sections are more complicated than others, then we are in a far better position to reduce said complexity.

So by reducing that complexity, we reduce the likelihood of introducing defects. That flows into all stages of a software’s life.

Greater Predictability

By reducing software complexity, we can develop with greater predictability. What I mean by that is we’re better able to say—with confidence—how long a section of code takes to complete. By knowing this, we’re better able to predict how long a release takes to ship.

Based on this knowledge the business or organization is better able to set its goals and expectations, especially ones that are directly dependent on said software. When this happens, it’s easier to set realistic budgets, forecasts, and so on.

Helps Developers Learn

Helping developers learn and grow is the final benefit of understanding why their code is considered complex. The tools I’ve used to assess complexity up until this point don’t do that.

What they do is provide an overall or granular complexity score. However, a comprehensive code complexity tool, such as Codacy, does.

In the screenshot above, we can see that, of the six files listed, one has a complexity of 30, a score usually considered quite high.

Cyclomatic complexity is a great indicator to understand if code quality deteriorating for any given change. Cyclomatic complexity can be harder to reason when looking at it or comparing whole modules given its infinite scale and not being related to the module size. However, something that you might find useful is looking at Codacy’s File list sorted by priority, which will help you understand which files are candidates of poor code quality, and then by consequence their modules.

That’s a Wrap

Also, this has been an in-depth discussion about what code complexity is, how it’s assessed, as well as the significant benefits of reducing it. While there is more to understanding code complexity than I’ve covered here, we’ve gone a long way to understanding it.

If this is your first time hearing about the term or learning about any of the tools, I encourage you to explore the linked articles and tools, so that you learn more. If you don’t code in Go or C, then google “code complexity tool” plus your software language(s). You’re sure to find many tools available.

Finally, if you want a comprehensive tool for assessing code quality, and one that helps your developers learn and grow, type on Google automated code reviews and you'll find a few tools worth testing, among them is Codacy.

7 drawbacks of linting tools

Gustavo Silva — Wed, 14 Apr 2021 14:27:06 +0000

Linting tools (also known as linters or static analyzers) help automate the code review process. They perform basic static code analysis by flagging programming errors, bugs, style issues, and security vulnerabilities before code is compiled and actually runs. The overall aim is to improve software quality and reduce costs.

While integrating these tools into your workflow is largely beneficial, some drawbacks exist which may not make them the best choice for long-term or more sophisticated software development.

1. Code Checks Limited To One Programming Language

Many free, open-source linters perform code checks on only one coding language. This includes popular linters (per coding language) below:

Python: Pylint, Pyflakes, Flake8 (read more)
Java: Checkstyle, PMD, FindBugs (read more)
Ruby: Brakemen, rust-clippy, Rubocop
Scala: ScalaStyle, wart remover
JavaScript: ESLint, JSLint

These thirteen linters exemplify choices for less than 1% of coding languages that exist (sources like Wikipedia count more than 700). While difficult to pinpoint the exact number of linting tools, we know that there are hundreds since just the top 189(!) have been identified by AwesomeOpenSource.com.

Given such variety, technology stacks with multiple coding languages may need multiple tools integrated into the development workflow. This may produce negative effects which we describe in more detail below.

2. Variable Functionality For A Narrow View Of Code Quality

Similarly, the variety of functions among tools makes standardization difficult. Some focus on just one aspect of code quality like security, syntax, code coverage, or code style. For instance, among Python static analysis tools, Pyflakes analyzes code syntax whereas Flake8, another tool, is used for stylistic checks.

With multiple tools performing a variety of functions, it is difficult to obtain an integrated, holistic view of code quality. Also, it is bothersome to have the same code errors flagged by multiple tools.

3. Difficulty Handling Complex Rules

Linters analyze code for stylistic and programming errors against the rules they already know. While great for identifying errors using standard rules, this may pose problems for more unconventional code practices.

Although you may be able to avoid errors by overriding defaults and adjusting or disabling rules for particular files, this could cost developers’ time.

4. False Positives

A common critique of linters is that they produce many false positives. In other words, they flag issues that are not true issues in source code. While most developers find false positives annoying some use them as a sign to adjust rules for particular files.

However, adjusting rules becomes complicated when configuring multiple linters. Each linter has a different configuration file (with different syntaxes and semantics) that also needs to be adjusted. Therefore, in order to disable a rule considered false positive, developers should read the documentation of each linter before tweaking the file.

5. Reporting On Only Basic Metrics

While linting tools are good for basic metrics, they may not be the best choice to report on more complex indicators of software quality. This includes cyclomatic complexity which gauges the complexity of a program. Also, it is key to integrate linting tools early in the development workflow so that reporting and incorporating code quality metrics occurs before production.

6. Limited Learnings

While they identify best practices, linters do not ensure the teachings of best practices. Developers can use linting tools to improve code, but they might not be able to replicate the best practices.

7. Hidden Costs

While open-source tools seem “free”, hidden costs related to many of their mentioned shortcomings exist. For instance, integrating multiple tools in the development workflow requires maintenance and monitoring of each tool. When new updates occur, changes will need to be implemented.

This additional workload may fall on the plate of development or DevOps teams who could otherwise spend their time building new features.

Code Review Suites

Fortunately, advanced static analysis tools exist which mitigate most drawbacks of using individual linters. Code review suites integrate some of the most well-known linting tools on one platform. This ensures the detection of problems across languages.

There are many great code review tools out there and if you Google it you'll find Codacy on the top of your search results.

At Codacy, we integrate several linting tools plus their own rules in a continuous manner ensuring those tools are updated and new, useful tools are introduced. This helps support 40+ programming languages using one tool for code quality automation. Also, rather than needing to read documentation in order to disable a rule considered false positive, users can click on one button to disable a rule on Codacy.

While tools like Codacy may come at a monthly cost, for some use cases it may be worth it.

Overall linters are a strong tactic for automated code review and important to incorporate into your workflow. However, keep in mind the downsides before you incorporate too many of them as this may actually add costs rather than reduce them.

Go ahead and take a look at which tool adds value to your workflow and work environment. You have plenty of good choices to choose from.

Code Review vs. Testing

Gustavo Silva — Wed, 07 Apr 2021 11:27:56 +0000

Among coding best practices, code review vs. testing are often compared. Here’s what you need to know about each.

What is Code Reviewing and Testing?

Code Review

Code refers to the act of inspecting code; this can be done in the search for bugs, code style policy violations, security vulnerabilities, the extreme complexity of code, etc. The goal is towards code quality but also making sure the code does what it is supposed to do.

Testing

Testing is actually a vague description, as it might refer to several types of testing; for the purpose of this article, we’ll consider Unit Tests: tests that are implemented and can be run automatically with every build or even every commit to making sure former bugs don’t show up again (other types of testing include Regression testing, Integration testing, and Smoke Testing, to name a few, but we’ll leave these for a future post).

Does Code Review replace Testing?

Not at all.

I have seen this quite too often: strong Code Review processes in place with no deployments until everything is inspected by a senior member of the team, only to reintroduce bugs that were thought to be in the past.

As codebases grow it becomes harder and harder to keep everything in one’s mind, and sometimes it’s easy to overlook the appropriate way to use a method, the appropriate parameters to use, or the side effect of an action in very a specific circumstance.

With more than one reviewer present (unless it’s mandatory that code is reviewed by all of them) each reviewer begins accumulating blind areas of the codebase that are only known to certain members of the team.

Couple with the fact that the larger the platform the harder it is to manually test everything after each deployment, the absence of Unit Testing renders every update into a minefield packet with bombs that will only go off whenever a user named Murphy comes along.

Does Testing replace Code Review?

The following actually happened: big company, big client, big solution. There was a dedicated testing team that implemented every possible scenario they could think of, and they ran the tests every single day.

The client was a major political party about to use the platform for communication purposes on elections day.

What could possibly go wrong, right?

Sadly, when launched, the system simply didn’t work, and it being a Sunday meant that the team wasn’t readily available.

What caused the problem?

The fact that it was Sunday.

And that the tests had only run from Monday to Friday.

As it turns out, the platform had a bug that rendered it inoperable during Sundays (something to do with 0-indexed arrays).

In retrospect, Code Review could have indeed saved the day, as analyzing the code with a thorough attitude could have caught this particular flaw.

While testing is important, in this case, it didn’t really account for every possible scenario*.

That’s where a human comes in, analyzing code with a critical mindset and thinking of possibilities that may have been neglected when the tests were written.

Also, Code Review is not just about catching bugs that could’ve been caught through testing. Code Review also targets readability/maintainability, code complexity, performance, unused or duplicated code, etc.

* — For those wondering whether it would be possible to test every possible scenario: the answer is no.

While you could have tests running on weekends as well you’d still be missing all the other possibilities: nights, different machines, bugs that only manifest if the code hasn’t run for the past 3 hours, or even flaws that only become meaningful when a specific amount of users is connected to the platform (not necessarily a huge amount of users, which would be covered by Stress Testing, but rather a specific amount of users, such as 11).

Code Review Vs. Testing: Conclusions

When it comes to best practices, there’s hardly any that can replace another, and such is the case with Code Review and Testing.

At most you’ll be deciding which one is a priority regarding the other or which one should come first in your workflow, but not which one to put in place in detriment of the other.

Regarding Testing and Code Review, they don’t replace each other and they shouldn’t be mutually exclusive.

You should test, and you should review your code.

More about Code Reviews

If you want to keep reading about code reviews, take a look at the article 10 ways to perform code reviews. I hope it adds value to your day!

Top 10 ways to perform fast code reviews

Gustavo Silva — Thu, 01 Apr 2021 11:41:58 +0000

We always want to be fast at code reviews...

How frequent is it for you to be reviewing code at 3 am?
When code reviewing, do you find yourself thinking: “I mentioned this before.. We should have some sort of process”.

We keep learning a lot with our user base which currently supports more than 200 000 developers.

A big aspect is how developers waste themselves in the process of code reviewing.
Code reviews (pull requests, commit validation or approval), can be tedious and exhausting.
We’ve gathered some aspects from people who are doing it right.
These are small hints that we’ve seen from our users that highly help so you don’t have to be alone at 5 am reviewing your team’s code.

1: Review less

Smaller commits lead to smaller more manageable code reviews.
Besides other clear benefits (1, 2, 3, 4), dividing work into smaller chunks leads to more understanding of the intent of the change (hence more understanding into ways to put it better).

Problem: My team likes to have big bulky commits.

Solution: Start dividing your work into smaller commits. When your team sees the clear benefits of reviewing your code, they will most likely follow.

2: Time boxing

Code reviewing tends to be secondary in the process. Hence, it’s common to see it slipping away through the day when finally you’re all alone in the office validating work from other people.

A good way to help mitigate this is by assigning a time slot in the day to review the code.
When that is not possible, try to apply a maximum value to it (like 60,70,80 minutes).

Problem: My team ships code into production at crazy hours.

Solution: Prioritize your reviews by checking the essential when a complete review is not possible (see the review checklist below). When you see yourself not being able to properly review code, try to change the timing, deploy hours.

3: Distribute/Delegate

Make sure reviews don’t fall on the same person.
I’ve seen companies centralizing code reviews on one person.
It makes for:

Overworked people
Slower deploy times
Bad reviews (reduced attention span)

Problem: But my CTO is micromanaging the code reviews to make sure everything is alright

Problem 2: But I don’t trust my team to deploy code without my eyes on it.

Solution: Teach a man to fish. Also, make for your (or your boss's) review as an additional safeguard but not an essential blocking one.

4: Shared Code guidelines

Before enforcing a best practice, one can always make sure everyone is on board with it.
Take time to view what guidelines are important.
Always hear when developers want to add to the guidelines.
Good people always look for ways to improve their craft. Good developers always want to stay updated.

For different programming languages, you have different coding guidelines.

If you don’t yet have a coding guideline, here’s a list of them by programming language to start the conversation:

Taking community-driven standards (or at least basing your company’s code style in it) it’s a great idea since it ease’s new developer onboarding and better community help.

5: Create a checklist upon review

Having a checklist to review code greatly improves the efficiency of the process.
Sometimes in the middle of a review, we identify an issue and we remember we haven’t been really paying attention to that specific problem previously (which then leaves you with the uncertainty of an incomplete job).

Ideally, one should have every important aspect in one’s head (since for N lines of code, checking each one for N code rules is O(N2) — absurd of course but you get the point).

Also, the inverse of having coding guidelines (point 4) is enforcing them.

Problem: There are a lot of engineering issues that don’t fit into the checklist.

Solution: Definitely right. These can be addressed afterward in a team/one-to-one short meeting. Overall, this is a learning process, and is much more important to start doing some early and learn from what is missing or being left out.

Here’s a small suggestion of a code review checklist to start the conversation in your team:

Is the code style according to our own?
Is this code according to the best practices we/community defined?
Is this code problematic/inefficient/error-prone/not clear/previously proved bad/not compatible with the architecture
DRY/SRP/KISS/YAGNI/Smell

Here are other checklists you might find interesting as well: 1, 2, 3, 4, 5, 6

6: Use collaborative review tools

Doing Git (or repository-based) reviews only (by looking at logs, diffs, and commits) is time-consuming.
One should look for a tool that allows you to:

Quickly review what changed
Quickly be able to communicate with people
Decide to approve (or not) the commit

By concentrating these three aspects into one tool, you can be more efficient at the underlying actions we need to execute a code review.

If you’re choosing a tool, choose one that you can get your whole team on board.
Github, Bitbucket, and GitLab both have pull requests which represent a workflow with built-in code reviews.

7: Do a little, even if no time

Problem: It’s Thursday and you want to deploy some features into production (because you don’t deploy code on Fridays). However, it’s been a specially tough week and so you haven’t really been paying attention to how code evolved.
Before you know it you have 200 commits to review.

Solution: Prioritize your checks and don’t strain yourself. Only check for major issues. Code style can be checked later or automatically through linting afterward.

Knowing the history of the project (and the problems you’ve had), you also have a sense of the more important aspects to look for.

The important part is sharing ownership and sharing knowledge.

8: Use short-circuiting

When time is of the essence and reviewing every line written is not an option, take an incremental approach.

When you’ve found a possible buffer overflow or a function call you know it will blow up in production, it shouldn’t really matter to review code style.

In your code review checks, you can insert short-circuiting elements: if a commit has a big enough problem that needs to have further development, one can ignore smaller less important problems for a future review of that code when it is corrected.

9: Helpful commits

Concise and to the point commit messages with code that is commented really narrows the focus of the review.
The code reviewer will have a much easier job if you talk about the implemented feature and the design decisions behind it.
Helping your team members is a good way for them to see how valuable a proper commit is.
Take a look at how the Linux kernel guides their own submission: https://www.kernel.org/doc/Documentation/SubmittingPatches.

10: Add automated code review tools to your workflow

A final and great way to reduce the time it takes to review code is by reducing the number of aspects of your checklist that you need to pay attention to.

By adding automated code review tools you can automate some aspects of your code reviews such as code style, best practices, and common issues. This frees you to only check for what matters.

Automation lets you be better and save time. Combined with the aspects on top, you’re on your way to make sure you don’t spend more time than you have on code reviews.

Because you care and because you always want to be better, automation is a great way to optimize your review workflow process. Go ahead and do a quick search on Google for automated code reviews and see who better fits your workflow. You'll find Codacy on your Google search and we hope you like what we do.

Top 6 items for your code review checklist

Gustavo Silva — Thu, 25 Mar 2021 17:06:01 +0000

At Codacy we set high standards, and care about the quality of the code we produce. In order to provide optimal experiences for our users, we highly suggest having a process in place for code review. To help, below are the top 6 items for your code review checklist.

Why do code review?

First, let’s go over the top three reasons that those involved in the software development process should perform code review.

Avoid bugs: the cost of a bug increases exponentially the later you catch it.
Sharing: being subjected to a good code review is a master learning experience.
Culture: foster a positive collaborative environment toward a common goal.

Automatic code review tools

Automatic tools such as compilers, testing libraries, linters and formatters have improved the effectiveness of code review in recent years. They do an effective job reducing heavy lifting and boring parts of the code review process.

While there may be initial setup costs, integrating these tools yields immediate returns. I suggest you seize the opportunity to use these tools.

Top 6 items for better code review

Since automation alone cannot cover all aspects of a code review below are the top six bullet points to handle the other parts:

1. Review your code first

Always review your own code first – don’t rush by pressing the button to open a pull request. I suggest following a checklist to help you catch silly mistakes, typos, and other distractions in order to ultimately save time and effort. To challenge and stretch yourself it may be helpful to answer questions such as:

Is this the correct level of abstraction?
Is the approach the best one given the constraints?
How would I improve this solution?
Are there quick wins we can tackle within the scope of code change?
Can this be broken down into smaller code changes?

2. Understand the purpose

Make sure you understand the reason why the code change exists in the first place. Is it to:

Fix a bug?
Add a feature?
Change functionality?
Improve a technical aspect?

There should be only one purpose of a code change. If you confirm that multiple reasons exist stop and ask the author if the code change can be split. Splitting code change allows you to:

Focus on one reason
Avoid distractions
Review smaller chunks
Provide cleaner and better project history

3. Read all code changes

Go through the code (without skimming) imagining the code is a novel with a story to tell. In doing so, you will surely catch typos and inconsistencies. You can think twice about the names used for variables, methods and more. Ask yourself:

Are they descriptive?
Are they concise?

Though naming in software is difficult, agreeing on common rules of thumb will help make it less painful. Check that the style guide rules that your code formatter cannot catch are followed.

4. Ask (and answer) questions

As a reviewer be sure to ask all the questions that come to mind. Don’t be shy, take the opportunity to learn something new!

As an author, accept all comments in the most positive and open way. Remember, there are no personal comments. Be open to listening and considering the views of others even if you have strong opinions. Explain your choices thoroughly, exhibiting little bias.

Code reviews are an incredible opportunity to learn. Asking questions will improve the experience of everyone involved. A written discussion in a GitHub comment thread can also dramatically help when someone needs to go through an old review while tracking down a bug.

The only golden rule to bear in mind in these conversations is to stay nice and kind! This Red-Hat blog post is a great summary on conducting these conversations.

5. Air control

Look at the code change from a big picture, high-level point of view. Ask yourself is it:

Going in the right architectural direction?
Introducing dependencies that can be avoided?
Rebuilding the wheel and can be simplified by using external dependencies?
Submitted to the appropriate codebase?
Placed in the right place within the codebase?

Challenge your answers and try to think of a simpler way to tackle the problem in the first place. Think about flows in your system and verify that changes respect patterns.

6. Ground control

Zoom in to the details of the implementation:
Is the CI (continuous integration) green and is it passing tests? If not, why?
Are the tests covering all the edge cases?
Are the tests covering the error cases and not solely the happy path (main control flow) of the program?
Is the code readable, explicit and deliberate in what it does?
Is business logic properly separated from integration?
Are exceptions handled properly?
Does the code use appropriate data structures?
Do the algorithms have an excessive computational complexity?
Are heavy resources (like DB access and network calls) used carefully?
Are all the used operators/methods completely clear?

Keep in mind that code can hardly be perfect from all points of view. In most cases, for example, you might want to encourage readability over performance. It’s much easier to optimize correct code rather than fixing optimized but incorrect code. Avoid premature optimizations, but, be mindful and avoid evident de-optimizations. The code should be easy to substitute and change – engineer it right to the point and no more. Avoid introducing premature extension points as they increase code complexity. Refactor only after proven need, but do it thoroughly when needed.

Conclusions

While my top items may enhance the code review process for individual developers, teams and enterprises, there are many other actions and resources you may want to consider.

In addition to some of Codacy’s own resources, many articles exist on the internet about code reviews. The following particularly caught my attention:

How to code review in a Pull Request

Gustavo Silva — Wed, 17 Mar 2021 18:09:39 +0000

This article discusses how to code review within a pull request in order to improve your code quality. Let's start with pull requests first.

What are Pull Requests?

For those unfamiliar, pull requests are used to get peer approval before changes are merged within a version control system, like GitHub, Bitbucket or GitLab. You can find more documentation about it on GitHub, Bitbucket and GitLab.

This approval typically comes after the code is reviewed and no further changes are requested. This process is often referred to as code review.

Bear in mind adding code reviews to your development process is quite time-consuming, meaning management has to be okay with your weekly hour expenditure on code reviewing.

Today you can add automated code review tools to your workflow so you can get even faster code reviews. Go ahead and type automated code review tools on Google and select your favorite one.

Integrating code review into your development workflow

Having code reviews in your development workflow certainly constitutes a process and many dislike it.

Among the reasons I’ve seen listed by people who dislike the process: 1) they consider Pull Requests a step to validate the technical details they’re sure are correct 2) acquaints other with the code they wrote 3) hurdle getting in the way of what they love doing: coding.

I’m going to argue otherwise.

Quoting GitHub documentation: “Reviews allow for discussion of proposed changes and help ensure that the changes meet the repository’s contributing guidelines and other quality standards.“. Thus Pull Requests are a medium for discussion. The discussion implies questioning, debate, iteration back and forth for the sake of a better codebase.

The point is to both improve the code and improve all of the contributors’ understanding of it. You’re trading iterations for more polished code and increased overall knowledge.

Of course, this way of thinking also annoys any programmers who dislike communicating and/or discussing code. And though every human being differs in the topics they enjoy talking about, or the amount of interaction they are comfortable with, in the realities I came across as a professional developer, programming has always been a team sport.

Comments

There are two things to keep in mind when commenting:

There are places where the code must be changed, and there are suggestions which you believe are improvements. On the latter, it’s okay to think otherwise. You should try and be explicit in the case of each comment.
Your comments should be directed at the code, never the author. This may seem counterintuitive, but I assure you it’s of vital importance. The correct tone is the difference between a healthy discussion or making someone feel diminished.

What to look for

I’ve already talked about the where and the why, but not the how. You know you need to read the code and comment. But what should you be looking for within the code? The basis for a pull request is the difference between two commits. So, what happened between those two commits?

The intent of the changes

Stating the obvious: changes are made for a reason. If your project’s work is split into tasks, there was a task at hand. To understand the issue your colleague was tackling, you can read the task given before reading the implemented solution.

Common pitfall: do not review a PR with the author

When you don’t understand what a part of the new code does, what do you do? You ask the author. And then he or she explains this part and then the rest. Now you’re reviewing the code with the author. You will inherit the author’s biases. Everything you read is within the lens of the author’s view, making you understand things you will not understand next time you read them unless you remember the explanation. And you might even agree with things you would not to, due to context.

My general advice is to avoid reviewing code with the author. This is controversial, but I believe the benefits outweigh the disadvantages, and it’s more often than not a mistake.

Impact of the changes

Do the changes fit the application flow? Do they change the way something interacts with something else? Can something break?

When you were learning to program, you created mental models matching what code does. So, as a developer, you kind of can compile and run code in your head. You are able to reason about a flow. You can apply this mighty skill to code reviews. Run the code in your head and wonder if it goes wrong. It could be the changed code or other parts of the application.

Spot something fishy? Checkout the branch

Did you find something odd on the implementation and you’re not quite sure if it works? Checkout the branch and investigate a little bit more. Follow the flow within your editor of choice, and you will find either a mismatch in what you thought the code does or in what the code was supposed to do. So either a bug or more in-depth understanding. It’s a win-win. It is vital you understand each and every change you’re approving.

Spot bad practices

Code reviews are a great way to educate. If you spot anything you believe to be a bad practice, you can point it out. Something as simple as “One letter variables aren’t good because the name conveys no meaning” points out both the mistake and the reason why it’s a mistake. Pointing out again: PRs are a place for discussion. So prepare yourself for some amicable arguing.

Readability matters

Code is read way more often than it is written or modified. So you should, within reasonable limits, optimize for readability, because that is where you and your teammates will spend most of your time.

If you don’t think a variable name accurately represents what’s in it, suggest a better one.

Navigating big PRs

Most PRs should not be big. Big changes happen sometimes, but they are not the most common. So if someone is consistently making PRs with lots of changes, chances are they’re not separating the multiple concerns they’re tackling into separate PRs.

Here are a couple rules of thumb you can use and advise others to do so.

Keep refactors in separate PRs
Tackle one issue per PR

So, when you have a massive PR to review, here are some things you can do to help you navigate the logic and understand faster:

Look into the individual commits
Look at the new tests
Reading first the files you know have relevant changes

Reviewing Tests

Tests are also code that needs to be maintained, code in need of reviewing. A lot of people dismiss tests when they’re reviewing code, but this can reduce the quality of your tests.

Think of the corner cases

Corner cases need to be tested. So think of the corner cases you would check. See if they’re covered within the test cases written.

Do the tests look like they would fail?

When you’re writing a test, it’s important to see it fail. So in a review, it’s important to look out for the same kind of mistake. Do the tests look like they would fail if the tested code is malfunctioning?

Reject any test that was made based on an output

Sometimes people get real data to test their code, and they don’t trim the data down to the most relevant parts. So what happens is, they use that data and assume that non-empty values are correct. You can spot these in high numbers or big lists.

It gets easier over time

Reviews are especially hard when you’re not used to them or not familiar with the affected codebase. But don’t get discouraged. Like pretty much anything else in software development, it’s a learnable skill.

Review of Java Static Analysis Tools

Gustavo Silva — Tue, 09 Mar 2021 16:04:42 +0000

If you code in Java and code reviews are part of your workflow we recommend you to go through the list below. Here are some of the Java Static Analysis tools you should know about:

1. PMD Java

PMD scans Java source code and looks for potential problems.

Problems range from breaking naming conventions and unused code or variables to performance and complexity of code, not forgetting lots of possible bugs.

The PMD project also supports JavaScript, PLSQL, Apache Velocity, XML and XSL. It also ships with a CPD, a tool to detect duplicated code in several languages.

PMD integrates with several tools and editors, including Eclipse, NetBeans, IntelliJ IDEA, TextPad, Maven, Ant and Emacs.

Here’s a sample of what running PMD through some code looks like:

$ pmd pmd -R java-basic,java-unusedcode -d Deck.java
/Users/pmd/my/project/Deck.java:35: Avoid unused private fields such as 'classVar2'.
/Users/pmd/my/project/Deck.java:47: Avoid unused private fields such as 'instanceVar3'.

You can suppress warnings (in a variety of ways) and you can also write your own rules in either Java or XPath..

2. Checkstyle

As the name implies, Checkstyle checks that your code adheres to a coding standard.

The tool is configurable, which makes it able to support different code style conventions. Two examples are the Sun Code Conventions and Google Java Style (although the one from Sun hasn’t been maintained since 1999).

You can find a configuration file for Google’s Java Style on the checkstyle repository.

Speaking of configuration, this is done in an XML file where you set which modules are to be used. Here’s a (tiny) example of a configuration file:

$ checkstyle -c checkstyle.xml Deck.java
Starting audit...
/Users/checkstyle/my/project/Blah.java:0: File does not end with a newline.
/Users/checkstyle/my/project/Deck.java:23: Line has trailing spaces.
/Users/checkstyle/my/project/Deck.java:70: Line has trailing spaces.
Audit done.
Checkstyle ends with 3 errors.

3. FindBugs

FindBugs looks for bugs in Java Code, and this means over 400 different bugs.

Patterns are separated into several categories: bad practice, correctness, malicious code vulnerability, multithreaded correctness, performance, security and dodgy code (two additional categories exist, with just a couple of patterns each: experimental and internationalization).

There are several ways of running FindBugs, but here’s what the command line interface can feel like:

$ findbugs -textui .
M P UuF: Unused field: java.deck.Deck.classVar2  In Deck.java
M P UuF: Unused field: java.deck.Deck.instanceVar3  In Deck.java
M D UuF: Unused public or protected field: java.deck.Deck.instanceVar2  In Deck.java
M D UuF: Unused public or protected field: java.deck.Deck.classVar1  In Deck.java
M D UuF: Unused public or protected field: java.deck.Deck.instanceVar1  In Deck.java
Warnings generated: 5

The first letter in the output refers to the severity of the (potential) bug (low, medium, high) and the second is the category (in this case P for Performance and D for Dodgy Code).

It integrates with Eclipse, Maven, Netbeans, Jenkins, Hudson and IntelliJ.

FindBugs supports a plugin architecture that allows anyone to add new bug detectors; which brings us to…

4. Find Security Bugs

Find Security Bugs is a plugin for FindBugs which adds checks for 80 additional different vulnerability types.

You’ll find a range of patterns that relate to OWASP 10 vulnerabilities, from different types of injection and XSS protection to sensitive data exposure and unvalidated redirects.

There are also several patterns that are specific for Android.

There’s also other common things such as hashing methods and DOS vulnerabilities, not forgetting simpler things such as hard coded passwords.

Conclusion

As with similar tools in different languages, these Java Static Analysis tools complement each other, and we do recommend that you check them out if you care about Code Quality and avoiding technical debt.

Both PMD and CheckStyle are already integrated with automated code reviews such as Codacy, which means you can start using them right now.

Using an automated code review tool means you’ll get all of these analyses done for you automatically every time you do a commit, plus a list of issues that are expansible to reveal additional detail on the particular problem and how to solve it.