[FishEye Knowledge Base]
This page contains information about the Lines of Code metric and how it is processed and represented by FishEye.
On this page:
Lines of Code or LOC (also known as Source Lines of Code - SLOC) is a quantitative measurement in computer programming for files that contains code from a computer programming language, in text form. The number of lines indicates the size of a given file and gives some indication of the work involved.
LOC is literally the count of the number of lines of text in a file or directory. In FishEye, blank lines and comment lines are counted toward the total lines of code.
LOC for a file/directory is the total number of lines in the relevant files, while LOC for an author is the number of lines blamed on that author. Neither of these should ever be less than zero. However, the change in LOC over a period of time can be negative if there was a net reduction in the LOC over the period.
While it can be useful, LOC has some well documented disadvantages. Keep these disadvantages and limitations in mind when using LOC in your work environment.
In addition, the nature of branching in SCM applications means that calculating a LOC value for a whole project is not possible. A naive summation of the LOC of all the branches will give a meaningless number that jumps every time a branch is copied to create a new branch. Thus, in FishEye we usually look at the LOC of the trunk, unless we can infer from the context that another branch is more appropriate.
FishEye calculates the LOC for the trunk only. For SVN repositories it can calculate LOC for a branch if it is "tricked" to see the branch as part of the trunk. FishEye also calculates the LOC for each user, unless that facility is turned off in the repository (see Store Diff Info). The LOC count will include all files except those identified by the SCM as binary.
FishEye presents LOC data as charts of the change in LOC over time, and as informational statistics in various places:
The evolution of user-specific LOC over subsequent commits can appear at first glance to be counter-intuitive. It is important to keep in mind that the LOC for a given user is the number of lines in the repository that were last changed by them (as calculated by Fisheye).
A couple of simple examples:
A user can have LOC on a branch that they have never committed on, if something that has been blamed on them is copied. For example, a developer may have never committed to a particular branch, but FishEye may still report a lot of LOC for them in that area.
One current limitation of FishEye's user-specific LOC calculation is the handling of merging. For example, if a file has been changed on both trunk and branch, and the changes made on the branch are merged to trunk, the changes made on branch will generally be blamed on the person who did the merge; not the person who made the change.