Often abbreviated as LOC, this is one of the most tangible, but in most cases also the least correct way of measuring the productivity of a programmer. The fact that it involves little more than 'cat *.c|wc -l' or similar (I've heard that GUI development tools even keep count of LOC automatically!) in terms of work effort for the person doing the evaluation, it remains popular (with the evaluators, at least).

The evil inherent in this measurement of productivity is understood by any programmer (OK, so I could name a few who don't act like they do understand...): The program is just a way to achieve a goal; the goal is the important part, and if you reach that goal in three lines of code - fine, some wretched maintainer of code will soon bless you and thank you for your brevity.

LOC was also used as a way to predict the maintainability of code - functions (for this was in the age before OOP, a long, long time ago) were supposed not to exceed a number of lines, thereby making the snippet of code easier to grok. 'Not having more lines of code than rows on your terminal' was a common rule of thumb, allowing the entire function to be accessed visually without scrolling.
Fledgling programmers, careful not to break any policies regarding What Source Code Should Look Like and carefully paying attention to indentation and variable name conventions without knowing why the rules were there in the first place obediently removed comments, vertical and horizontal whitespace, sometines even contracting several statements on the same line - thereby reducing understandability by following the rules set up to increase it. The dangers of understanding a rule semantically but not pragmatically.

Nowadays, effective lines of code, or ELOC, has replaced LOC as the primary way of measuring code length. ELOC equals LOC minus the number of lines (well) spent commenting your kludge and vertical whitespace. If you want to determine the understandability (thereby getting an idea of the maintainability) of your code, you might be better off doing it like a pro, measuring cyclomatic complexity and cohesion instead.

While it is true that LOC is a terrible way to use for evaluating a program, it can be an extremely valuable tool (in the hands of an experienced programmer who follows a fairly structured PSP) for predicting the development time for a program.

As for Rollo's statement about the coders who randomly delete comments and spaces to get LOC down, I solve this problem myself by counting "logical lines of code" (which you must define before you begin counting) and by keeping a separate "lines of documentation" count.

Unfortunately, my ratio of LOC to LOD would, in some cases, cause a floating exception in a program that tried to evaluate the ratio. This is a bad thing.

Log in or register to write something here or to contact authors.