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.