Line Impact is the foundation of how GitClear assesses and visualizes developer output. Factors fall into four categories: lines, files, commits, and branches.
This isn't a one-size-fits-all assessment of lines of code. Our commit processor has been painstakingly built to provide you with the most precise measurement of your team's output. Line Impact is transparent and customizable, so you and your engineers know what's being measured and why.
There are 7 different operations that we recognize in commits. Each operation below is accompanied by a screenshot of how the operation looks in the GitClear diff viewer.
Each added line of code counts for up to 10 points.
Each deleted line of code can count for up to 25 points. Our experience is that deleted code means less code, which is more impactful for the long-term benefit of the codebase, and such changes are weighed more heavily.
Moved code (about 30% of all changed lines) is assigned no Line Impact.
When a line changes in part, we consider this an "update." Updates can count for up to 10 points.
When a developer applies the same change to several lines en masse, this is detected as "Find & replace." Such lines are worth up to 3 points.
When a developer repeatedly adds ("pastes") the same line in multiple locations, across one or more commits. Copy/pasted code is assigned no Line Impact.
One of the most common types of code change is the "no-op." This encompasses all changes to white space, blank lines added, and lines whose only change was their line number.
Assuming you're using one of the 40 programming languages we have built a custom parser for, Line Impact will additionally recognize a few other concepts.
About 5-10% of all lines of code are language keywords. Regardless of whether they're added, deleted, or moved, they're transparent to Line Impact.
Because it's trivial to add or delete large swaths of comments, and because much boilerplate comes in the form of comments, they are afforded negligible Line Impact.
As a matter of taste, some projects and committers prefer to spread declarations across multiple lines. From the standpoint of Line Impact, the entire declaration is treated as a single line, since it could have been represented as such.
Some languages make heavy use of include statements to avail functionality within modules. These statements do not unto themselves contribute value, and so are afforded negligible Line Impact.
The "action detected" is combined with our assessment of the line's context to yield our final estimate of cognitive load. Here are a few types of context recognized by GitClear:
Proximal changes. A line that is changed alongside 10 other lines generally requires less cognitive load than a standalone line that is changed. The former situation describes most new features implemented, whereas the latter implies a targeted bug fix that probably took some research to pinpoint.
Churn. Has the line been changed previously within the last couple days? If so, its Line Impact is spread across all the commits that changed the line.
File type. It's generally easier to write a line of CSS than a line of Python. We estimate scalars for each file type based on the level of redundancy we detect in that file within your project. Admins can modify these scalars on a per-project basis to account for their own sense of the relative difficulty of contributing a line to various types of files.
Keywords and syntactic lines. We detect usage of known keywords in file types, and allow the admin of a GitClear project to define additional patterns born of language or project convention. Such lines are assigned little to no Line Impact.
Comments. Similar to "keywords and syntactic lines," we detect lines of code that are comments and adjust Line Impact for such lines (by default, comments are considered to require less cognitive load than code)
While the above list is not exhaustive, it reflects the philosophical approach to assigning Line Impact to a commit. The cornerstone of calculating Line Impact is to 1) detect the action that occurred 2) scale this value relative to the context of the changed line. Wherever possible, we expose the context scalars used, so they can be modified based on the judgment of project admins.