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 actions that we recognize in commits, as of April 2018:
Addition: Each added line of code counts for up to 10 points. Along with "deletions," this is the basic unit of code change
Deletion: Each deleted line of code can count for up to 10 points
Move: Moved code is assigned no Line Impact
Update: When a line changes in part, we consider this an "update." Updates can count for up to 10 points.
Revision: A "revision" is an update that's also "churned" code. Read more about "churn" in the "Context-"
Find & replace: 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.
No-ops. 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.
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.