The value of 1 line of code...

[rocketboy9000]

Sometimes I write lots of code, and it does almost nothing. Sometimes I write very little code, but the result is very useful. Which makes me question, what is the true value of 1 line of code?
As an example, I recently wrote 200 lines of Perl on a stupid script to convert one ad-hoc 3d model format into another, and turn spheres into triangle lattices, for display by a simple C++ graphics displayer. Almost nothing. However, I also wrote a 350 line Perl program to create a model of a chemical, given its name. Then, afterwards, I wrote a 100 line C++ program with allegro specifically for displaying spheres only, making the first program useless.
I find it worrying that 200 lines can be made useless by 100 lines. What's the real value in 1 line of code?

[hamsterman]

Sometimes I write lot's of code and later realize that I'll have to rewrite it in another, better way. So I suppose the value of those lines is negative! Though in those cases writing a lot of code helps me to find the flaws of my current method and work out a better one, so maybe they do have some value..

[sohguanh]

This is a very common phenomenon as you program more and more. I also face such problem. Programs I wrote a year ago when I re-visit it recently, I was wondering why are this block of code needed? Why repeat and redundant etc etc etc. In fact less lines is *better* than more lines of code if they can still achieve the same objective without sacrificing performance and maintenance.

The more lines of code exist in your program means they may or may not yet be get executed so lies "hidden bug" if any. I am an advocate of less lines of code if possible. C++ STL help me to achieve that in a way but they do sacrifice clarity when the nested angle brackets get "heavy" :P

[filipe]

While a simple LOC count can be misleading (curly brace languages usually have a lot of lines with just a curly brace, for instance) I think it's quite obvious that the less the better, as long as it doesn't overcomplicate the program. That's why programming in higher level languages is more pleasing and fun (to me, at least). Because they're so much more expressive, you can condense a lot of computations in fewer lines of code without any loss of readability.

[Kyon]

I'd say that any line is just as valuable as any other, because the loss of one line will unexceptionally lead to the loss of functionality of your program. You can of course make some sort of measure to determine the importance of a line of code (by looking at the amount of loss of functionality if the line were omitted). But the outcome is moot, since any line of code can be condensed to any amount. It just does not make sense to do this in all cases: the length of a code does not necessarily affect the performance of your code, it's not the length that matters, it's the code itself.

[rapidcoder]

I've read somewhere a research paper, where the authors claimed, that bug rates in respect to number of lines are very similar among various languages. Which means the shorter code you write, the less bugs it probably has. So if you code the same functionality in less lines, you automatically win higher quality.

[jsmith]

The value of 1 line of code. Ah yes. Zero, infinity, and everything in between. First off, define a line of code.
How many lines of code does this program have?

/* This program outputs a nice greeting */
#include <iostream>

int main()
{
    std::cout << "Hello World" << std::endl
        << "How are you today?" << std::endl;
}

Maybe 2 -- the std::cout, arranged over two text lines. Maybe 1, since you need both text lines to
form a syntactically valid program statement. Maybe 3 or 4 -- the #include, the main() declaration, and
the std::cout, whether you consider that one or two lines. Maybe 5 or 6 -- all of the previous plus the
open and close braces, though beats me how those could be buggy without being compile errors.
Or maybe 7, the number of nonc-ommentary lines of text in the file. Or maybe 8 -- the number of
lines in the file.

Take your pick.

So I think it is impossible to answer universally the question "what is the value of one line of code"
because there is no universal answer to the question "what constitutes a line of code?". But even so,
if you consider the open brace on a separate line to be a line of code, what is its value? I suppose it
is infinite, because without it, the code won't compile. What is the value of the std::cout line(s)?
I suppose also infinite since the program doesn't meet its requirements without it. But that would
imply that a line of code either has infinite value (necessary to meet program requirements) or zero
(or even less than zero, if it is not needed AND causes bugs).

[Kyon]

code the same functionality in less lines

That's the point, coding the same functionality is not the same as coding the same functionality in the same way.

If you code the same functionality in the same way with less code, it's probably more stable and bug free (however not necessarily easier to edit). If you code the same functionality with less code, it's not necessarily faster or more stable or bug free. Consider writing a recursive function (shorter) instead of a iterative function (longer, but faster and more reliable) which both give the same output for the same input.

@jsmith:
You are right about the "line of code" mix-up, but I bet the OP was talking about statements. (Since omitting includes, brackets or definitions will automatically screw up the compilation. That is, if you actually use the function / header, but I will just assume people won't write functions for nothing.)

[rapidcoder]

Consider writing a recursive function (shorter) instead of a iterative function (longer, but faster and more reliable) which both give the same output for the same input.

If you have a compiler that can guarantee TCO, and you have a way to enforce it, the recursive solution is just as fast and good. It is also easier to verify, because it highlights the invariants in the code, which are not clear in the iterative solution.

[Duthomhas]

There goes the false dichotomy between recursive and iterative solutions.

Properly formed, you can represent one form just as easily and safely (and verifiably) with the other. In terms of verifying program correctness, it is easier to validate a functional program than an imperative program, but don't confound that with the validity of resursive vs iterative code.

Bad programming leads to bad code, which exists either way.


As to the value of a line of code, I put it at: does it do what it is supposed to do without leaking?

That is, do I waste code? Or do I use it wisely?

Given, for example, this function to swap two integer values:

template <typename T>
inline
void swap( T& a, T& b )
  {
  a ^= b ^= a ^= b;
  }

This is short and cute, but it is also incorrect. There are too many things that can go wrong, besides the fact that it is undefined C and C++. Also, this code forgets to make sure that &a != &b, a necessary extra line of code for this "one liner".

A better, more correct version is this:

template <typename T>
inline
void swap( T& a, T& b )
  {
  T x = a;
  a = b;
  b = x;
  }

It turns out that the compiler is pretty good at optimizing stuff like this. It turns out that the compiler may, actually, all but eliminate that temporary (keeping it in registers). Even if it doesn't, it works better with modern CPU architectures, and is typically as fast as or faster than the XOR version.

Sure, it is "more" lines of code, but it is easier to read and understand, easier to verify and correct, and more efficient.

Each line does exactly what it should, the first leading directly to the last, without any fuzziness.


Hmm, perhaps I could have chosen a better example.
Also, I googled more reading on the XOR swap for you all: http://en.wikipedia.org/wiki/XOR_swap_algorithm

Anyway...

[chrisname]

I guess you're saying that clarity > conciseness? In which case, I agree.
In most situations I use the following:
1. Clarity
2. Conciseness
3. Portability
4. Maintainability
5. Security
6. Performance

[Browni3141]

Why do you put performance last? Is it because it doesn't usually matter on modern computers?

[chrisname]

No - I still think that it is important even on modern hardware (also, you shouldn't assume people are even using modern hardware). I rank it lowest because I believe that taking care of the first two (clarity and conciseness) generally takes care of performance. I believe that simple code will tend to be faster than complicated micro-optimized code. Obviously something that is going to be running in a loop should be optimized as much as possible, but it still comes below the others.

Edit: More importantly, I believe choosing the right algorithm is far more important than optimization. I (strongly) believe that, regardless of what optimizations you apply, a bad algorithm can never be fast.

[simeonz]

I sense implied distinction between the code that the programmer has to write on his own and the code that was provided for him by someone else.

Library code is used many times, tested many times, but is it bug-free? Not all compiler suites have the wide spread of GNU and MSVS and the bugs surface very slowly over time. A real life example - some C compiler for embedded MCUs compares signed integers erroneously in specific circumstances. Signed integers, man. The bug surfaces near production. So, do you count the lines of code that were necessary to write the compiler itself? What about the language libraries? (The fore-mentioned bug was discovered thanks to the addition of assertion-like guarding code that arguably increased the code size.)

Lines of code/size of code/code complexity are poor man's statistic compared to the analysis of the coupling, cohesion, code maturity. Also, if the code is reusable, then it will be tested repeatedly and improved over time. It wont contribute to the code/bugs ratio in the same way. It will contribute to the stability of the entire system in the same way as STL does (over-optimism acknowledged). So, to say that small code base implies fewer bugs is IMHO misleading. Reusing code with well defined responsibilities reduces the number of bugs.

Also, partitioned implementation will benefit from unit testing. Small problems result in easily detectable bugs. Of course, some problems are inherently complex.

Ok, scratched my ego again :)

[sohguanh]

Reusing code with well defined responsibilities reduces the number of bugs.

Library code may not be bug free but the above statement does not remove the bugs either. It can only reduce but not eliminate.

So given two options, taking the library route is the norm amongst most organizations. Organizations want to focus on the business aspects of their business. Library code stability, performance etc etc are usually not their top priority. It is then up to the IT developers to make sure the software they built is as good/fast/stable etc (a subjective issue I know) as it is for their users.

Maybe if the software is meant for mission critical systems say software onboard a satellite in outer space, software onboard homing missiles, software onboard planes etc etc will organizations take a more closer look at the developers use of library code as bugs in the library can be disastrous.