Line Impact is designed to approximate the cognitive load required to write a line of code, but not all languages are created equal when it comes to the effort required to write a line of code. This is why Static Object offers a settings page to customize the Code File Types in your repos. There are three options on this page that Managers will typically make use of.
To customize your settings on a per-file type basis, you can visit the "Settings" area of either your entity, organization, or repo, then click "File types."
The first option available is whether a certain type of file (e.g., .css, .rb, .py, .cpp, etc) should be processed by Static Object.
There are two consequences of turning off processing for a file type:
- Commits involving the file type in question will not contribute to Line Impact
- You will no longer see files of this type presented when reviewing commits.
Turning off processing for a file type is typically invoked upon auto-generated files, binary files, or other types of files that are irrelevant to understanding the activity in your repo.
The toggle to "Score files?" is similar to the toggle to "Process files?", except the files that are marked "Yes" for processing and "No" for scoring will still show up in the diff viewer, they just won't have any Line Impact assigned to them.
Turning off file scoring (while leaving processing on) is often desirable for config files, asset manifests, migration data, or other file types where the end product doesn't correspond to productivity, but you still want to see the files when you view a commit's diff.
Static Object also lets you adjust weighting with a real-time preview of the impact on Line Impact by changing an LI multiplier.
For example, in the screenshot above, the default LI multiplier for *.c files was set to 1.0, however, by adjusting it upwards to 1.35, I am able to see the effect that this changed multiplier would have on the Line Impact of the top three committers from my entity/organization, or repo.
By default, Static Object will periodically recalculate the LI multiplier per file type, using stats that we gather on the redundancy of words, and length of lines, within the file type. If you hover on the tooltip next to the LI multiplier, you can get the full details on what metrics were used to calculate the optimal LI multiplier.
We encourage Lead Developers to experiment with changing LI multipliers as they see fit. We would be happy to chat with you to recommend personalized multipliers, but as a general rule, you should consider setting the LI multiplier lower than 1.0 for files that are trivial to write code in (e.g., HTML, CSS, template files) and consider setting it at 1.0 or higher for files that do the heavy lifting within your project (e.g., Python, Java, Ruby files).
You can change your LI multipliers at any time and we'll recalculate the values assigned to past commits, usually within 15-30 minutes.