Smarter duplication detection!

Our duplication analysis is great for finding accidental copy-paste or slightly modified pieces of code in your project. However, sometimes it would report common pieces of boilerplate when those are perfectly legitimate uses of the language. One example is large numbers of module requires in JavaScript,
such as:

const ModuleA = require("module_a"),
  ModuleB = require("module_b"),
  ModuleC = require("module_c"),
  ModuleD = require("module_d"),
  ModuleE = require("module_e");

Another example is import statements:

import React, { Component, PropTypes } from 'react'
import { Table, TableBody, TableHeader, TableHeaderColumn, TableRow } from 'material-ui/Table'
import values from 'lodash/values'
import { v4 } from 'uuid

We’ve recently made our duplication analysis smarter so that common patterns like these in Java, JavaScript, and PHP will no longer be reported as duplication on Code Climate, so you can be more confident in the duplication results you do see from Code Climate.

Read more at the source

Our 10-point technical debt assessment

In the six years since we first introduced radically simple metrics for code
quality, we’ve found that clear, actionable metrics leads to better code and
more productive teams. To further that, we recently revamped the way we measure
and track quality to provide a new, clearer way to understand your projects.

Our new rating system is built on two pillars: maintainability (the opposite of
technical debt) and test coverage. For test coverage, the calculations are
simple. We take the covered lines of code compared to the total “coverable”
lines of code as a percentage, and map it to a letter grade from A to F.

Technical debt, on the other hand, can be a challenge to measure. Static
analysis can examine a codebase for potential structural issues, but different
tools tend to focus on different (and often overlapping) problems. There has
never been a single standard, and so we set out to create one.

Our goals for a standardized technical debt assessment were:

  • Cross-language applicability – A good standard should not feel strained when
    applied to a variety of languages, from Java to Python to JavaScript. Polyglot
    systems are the new normal and engineers and organizations today tend to work in
    an increasing number of programming languages. While most languages are based on
    primitive concepts like sequence, selection, and iteration, different paradigms
    for organizing code like functional programming and OOP are common. Fortunately,
    most programming languages break down into similar primitives (e.g. files,
    functions, conditionals).

  • Easy to understand – Ultimately the goal of assessing technical debt with
    static analysis is to empower engineers to make better decisions. Therefore, the
    value of an assessment is proportional to the ease with which an engineer can
    make use of the data. While sophisticated algorithms may provide a seemingly
    appealing “precision”, we’ve found in our years of helping teams improve their
    code quality that simple, actionable metrics have a higher impact.

  • Customizable – Naturally, different engineers and teams have differing
    preferences for how they structure and organize their code. A good technical
    debt assessment should allow them to tune the algorithms to support those
    preferences, without having to start from scratch. The algorithms remain the
    same but the thresholds can be adjusted.

  • DRY (Don’t Repeat Yourself) – Certain static analysis checks produce highly
    correlated results. For example, the cyclomatic complexity of a function is
    heavily influenced by nested conditional logic. We sought to avoid a system of
    checks where a violation of one check was likely to be regularly accompanied by
    the violation of another. A single issue is all that’s needed to encourage the
    developer to take another look.

  • Balanced (or opposing) – Tracking metrics that encourage only one behavior
    can create an undesirable overcorrection (sometimes thought of as “gaming the
    metric”). If all we looked for was the presence of copy and pasted code, it
    could encourage engineers to create unwanted complexity in the form of clever
    tricks to avoid repeating even simple structures. By pairing an opposing metric
    (like a check for complexity), the challenge increases to creating an elegant
    solution that meets standard for both DRYness and simplicity.

Ten technical debt checks

With these goals in mind, we ended up with ten technical debt checks to assess
the maintainability of a file (or, when aggregated, an entire codebase):

  1. Argument count – Methods or functions defined with a high number of arguments

  2. Complex boolean logic – Boolean logic that may be hard to understand

  3. File length – Excessive lines of code within a single file

  4. Identical blocks of code – Duplicate code which is syntactically identical
    (but may be formatted differently)

  5. Method count – Classes defined with a high number of functions or methods

  6. Method length – Excessive lines of code within a single function or method

  7. Nested control flow – Deeply nested control structures like if or case

  8. Return statements – Functions or methods with a high number of return statements

  9. Similar blocks of code – Duplicate code which is not identical but shares the
    same structure (e.g. variable names may differ)

  10. Method complexity – Functions or methods that may be hard to understand

Check types

The ten checks break down into four main categories. Let’s take a look at each of them.


Four of the checks simply look for the size or count of a unit within the
codebase: method length, file length, argument count and method count.
Method length and file length are simple enough. While these are the most basic
form of static analysis (not even requiring parsing the code into an abstract
syntax tree), most programmers will identify a number of times dealing with the
sheer size of a unit of code has presented challenges. Refactoring a method that
won’t fit all on one screen is a herculean task.

The argument count check is a bit different in that it tends to pick up data
and primitive obsession. Often the solution is to introduce a new
abstraction in the system to group together bits of data that tend to be flowing
through the system together, imbuing the code with additional semantic meaning.

Control flow

The return statements and nested control flow checks are intended to help
catch pieces of code that may be reasonably sized but are hard to follow. A
compiler is able to handle these situations with ease, but when a human tasked
with maintaining a piece of code is trying to evaluate control flow paths in
their head, they are not so lucky.


The complex boolean logic check looks for conditionals laced together with
many operators, creating an exploding set of permutations that must be
considered. The method complexity check is a bit of a hybrid. It applies the
cognitive complexity algorithm which combines information about the size,
control flow and complexity of a functional unit to attempt to estimate how
difficult a unit of code would be to a human engineer to fully understand.

Copy/paste detection

Finally, the similar and identical blocks of code checks look for the
especially nefarious case of copy and pasted code. This can be difficult to spot
during code review, because the copied code will not show up in the diff, only
the pasted portion. Fortunately, this is just the kind of analysis that
computers are good at performing. Our copy/paste detection algorithms look for
similarities between syntax tree structures and can even catch when a block of
code was copied and then a variable was renamed within it.

Rating system

Once we’ve identified all of the violations (or issues) of technical debt within
a block of code, we do a little more work to make the results as easy to
understand as possible.

File ratings

First, for each issue, we estimate the amount of time it may take an engineer to
resolve the problem. We call this remediation time, and while it’s not very
precise, it allows us to compare issues to one another and aggregate them

Once we have the total remediation time for a source code file, we simply map it
onto a letter grade scale. Low remediation time is preferable and receives a
higher rating. As the total remediation time of a file increases, it becomes a
more daunting task to refactor and the rating declines accordingly.

Repository ratings

Last, we created a system for grading the technical debt of an entire project.
In doing so, we’re cognizant of the fact that older, larger codebases naturally
will contain a higher amount of technical debt in absolute terms compared to
their smaller counterparts. Therefore, we estimate the total implementation time
(in person-months) of a codebase, based on total lines of code (LOC) in the
project, and compute a technical debt ratio: the total technical debt time
divided by the total implementation time. This can be expressed as a percentage,
with lower values being better.

We finally map the technical debt ratio onto an A to F rating system, and
presto, we can now compare the technical debt of projects against one another,
giving us an early warning system when a project starts to go off course.

Get a free technical debt assessment for your own codebase

If you’re interested in trying out our 10-point technical debt assessments on
your codebase, give Code Climate a try. It’s always
free for open source, and we have a 14-day free trial for use with private
projects. In about five minutes, you’ll be able to see just how your codebase
stacks up. We support JavaScript, Ruby, PHP, Python and Java.

If you’re already a Code Climate customer, you can expect a rollout of the new
maintainability and test coverage ratings over the next few weeks – but if
you’d like them sooner, feel free to drop us a
, we’re always happy to help!

Read more at the source

Fresh pots! Code Climate for Java is here ☕️

We’re delighted to finally announce first class support for Java within Code Climate!

This includes understanding and tracking Java technical debt using our 10-point maintainability inspections, full support for tracking test coverage of Java applications, as well as plugins for open source static analysis tools you may already know and love, like Checkstyle and PMD.

Java becomes the fifth programming language to be supported on Code Climate after JavaScript, PHP, Python, and Ruby. To celebrate, we’re offering new customers 50% off their first 6 months. Find us on Product Hunt to learn more.

We’re really looking forward to seeing how this helps teams level up the quality of their Java server-side applications as well as desktop and Android apps.

Give it a try today – we’d love to hear what you think!

Read more at the source

Introducing new ratings for your files and repos

We’re extremely excited to introduce new top-level ratings for your files and repositories!

  • Maintainability: An estimate of technical debt in the repo based on a standardized 10-point assessment of duplication, complexity and structural issues.
  • Test Coverage: The percentage of covered lines compared to the total number of lines of code. (We ingest test coverage information from your continuous integration server using our new universal test reporter.)
  • It’s been six years since we introduced radically simple metrics for code quality. Our new maintainability and test coverage ratings build on that to deliver a new, clearer way to understand your code’s quality.

    For more information about how these ratings are calculated, please see our docs. And to learn more about the other great features we’re shipping today, check out the blog!

    Read more at the source

    Better quality alerts

    Our pass/fail pull request statuses are great for ensuring that every change merged into your codebase meets your quality standards. However, every once in a while something may slip through the cracks. For those situations, we’ve got new and improved quality alerts for Slack and email. Alerts are sent when any letter rating changes, or any new files are created with a rating of “C” or lower.

    Here’s what it looks like in Slack:

    And here’s an email reporting some test coverage changes:

    We think this new functionality is an excellent complement to our recently-launched customizable issue alerts.

    Read more at the source

    A new, clearer way to understand code quality

    It’s been six years since Code Climate introduced radically simple metrics for code quality: a grade
    point average (GPA) from 0 to 4.0 for repositories, and a letter rating for every file. Today, we’re
    going further by completely revamping the way we measure and track quality, and shipping a bunch of
    new features to go along with it.

    Every repository and file will now receive two top-level ratings:

    Maintainability: An estimate of technical debt in the repo based on our standardized 10-point
    assessment which looks at duplication, complexity and structural issues.

    Test Coverage: The percentage of covered lines compared to the total number of lines of code.
    (We ingest test coverage information from your continuous integration server using our new
    universal test reporter.)

    Here’s how it all comes together on your new repository Overview page:

    On top of this foundation, we’re launching five major, new features:

    Unified Code tab with maintainability and test coverage side-by-side

    Gone is the isolated Test Coverage tab, which was an additional place to get a full view of your
    overall quality. We’ve fully integrated test coverage information into the Code tab, and everywhere

    Drilling down, you can access per-file quality statistics on the new Stats sub-tab:

    In-app configuration of code quality analysis

    It’s now possible to control the way we analyze your code quality using simple, in-app
    configuration. Easily select which checks to run and exclude files that are not relevant.

    You can also easily browse and enable open source static analysis plugins, taking advantage of the
    30+ tools that are compatible with our open, extensible platform.

    For those who prefer finer-grained control, or wish to keep their configuration in version control,
    file-based configuration using .codeclimate.yml remains available. If checked in, the
    .codeclimate.yml takes precedence over the in-app configuration.

    Reorganized and expanded Trends area

    With all this new data available, we thought it was a great time to add some organization to the
    Trends tab. The left sidebar now makes it easy to get right to what you’re looking for.

    We’ve also added a new chart allowing you to see the total amount of technical debt in the project,
    and the overall project maintainability, all in one place.

    Improved quality alerts via Slack and email

    Our pass/fail pull request statuses are great for ensuring that every change merged into your
    codebase meets your quality standards. However, every once in awhile something may slip through the
    cracks. For these situations, we’ve revamped the quality alerts we send via both Slack and email.
    Here’s what it looks like in Slack:

    And an email reporting some test coverage changes:

    Alerts are sent when any letter rating changes, or any new files are created with “C” or lower
    ratings. We think this new functionality is an excellent complement to our recently-launched
    customizable issue alerts.

    All of the above and more available via a REST API

    OK, so this one isn’t completely new, but it’s gotten much better and we couldn’t resist including
    it. Over the past year we’ve been developing Code Climate with an API-first methodology. As a
    result, the data that powers all of the above features is available over a
    robust REST API for you to take advantage of as you see fit.
    Here’s a few examples:

    Get the current ratings for an individual file

    $ curl \ \
      -H "Accept: application/vnd.api+json" \
      -H "Authorization: Token token=<token>" |
      jq '.data | .[] | select(.attributes.path == "path/to/file.rb")'
      "id": "59c41d36d0c53d0001000001",
      "type": "ratings",
      "attributes": {
        "path": "path/to/file.rb",
        "letter": "A",
        "measure": {
          "value": 220,
          "unit": "minute"
        "pillar": "Maintainability"
      "id": "59c41d36d0c53d0001000002",
      "type": "ratings",
      "attributes": {
        "path": "path/to/file.rb",
        "letter": "A",
        "measure": {
          "value": 92.40506329113924,
          "unit": "percent"
        "pillar": "Test Coverage"

    Get a time-series of test coverage information

    $ curl \ \
      -X GET \
      -H "Authorization: Token token=<token> \
      -H "Accept: application/vnd.api+json" \
      --data-urlencode "filter[from]=2017-08-01" \
      --data-urlencode "filter[to]=2017-09-01" |
      "data": {
        "id": "59c41d36d0c53d0001000001",
        "type": "metrics",
        "attributes": {
          "name": "test_coverage",
          "points": [
              "timestamp": 1501459200,
              "value": 98.57142857142858
              "timestamp": 1502064000,
              "value": 98.50960160504442
              "timestamp": 1502668800,
              "value": 98.53490376328641
              "timestamp": 1503273600,
              "value": 98.53314527503527
              "timestamp": 1503878400,
              "value": 98.5405557114791

    Just head over to your API access page of your user settings
    area to generate a personal access token and get started.

    These features will be rolled out to all repositories on starting today.

    Wrapping Up

    We hope you’ll agree that these changes represent a dramatic leap forward for Code Climate. As we’ve
    been testing this functionality internally and with a small group of customers, we’ve found it
    really changes the way we interact with code quality information day-to-day.

    There may be a few rough edges as we refine and polish some areas. As always, if you have any
    questions about anything, please don’t hesitate to get in touch.
    Our fantastic support team is always here to help.

    Read more at the source

    New test coverage statuses for your pull requests

    We’re excited to introduce two new pull request statuses to help you meet your goals for test coverage:

    • Diff Coverage, enforces a minimum percentage of test coverage on new and changed lines of code, to help you make sure that every commit improves your overall coverage.
    • Total Coverage, helps you maintain your current level of coverage. If merging the PR will reduce your total coverage, this status line will fail.
    • These statuses will be rolled out gradually over the next few weeks. If you’re already using our test coverage integration you’ll automatically get these pass/fail statuses on your pull requests, with diff coverage threshold set at a default of 80%.

      If you’re currently using our older codeclimate/coverage as a required status on your pull requests, we recommend first removing it via your GitHub Repo Settings before enabling either of the new statuses. The codeclimate/coverage status is deprecated, and will no longer update correctly within your pull request.

      Head to our docs to learn more about configuring these new statuses, and setting up test coverage.

    Read more at the source