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.


linkOperations recognized by Line Impact 

There are 7 different operations that we recognize in commits as of August 2020. Each operation below is accompanied by a screenshot of how the operation looks in the GitClear diff viewer.


linkAddition


Each added line of code counts for up to 10 points.


linkDeletion


Each deleted line of code can count for up to 25 points.


linkMove


Moved code (about 30% of all changed lines) is assigned no Line Impact.


linkUpdate


When a line changes in part, we consider this an "update." Updates can count for up to 10 points.


linkFind & 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.


linkCopy/paste


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.


linkNo-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. 


linkLanguage-specific idioms recognized by Line Impact

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.


linkKeywords


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.


linkComments


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.


linkMultiline statements


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.


linkInclude statements


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.


linkContext considered by 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.

 

The content above is from a note published by an Amplenote subscriber. As updates to the note are made, they are reflected here in real time.   Learn how to embed notes anywhere keyboard_arrow_right