Thread: Your biggest project: how many lines have you written?

Sorry cyberfish, that is still not good enough. It should be:

Code:

std::cout << 1;;;;;;;;;
std::cout << std::endl;
std::cout << 2;;;;;;;;;
std::cout << std::endl;
std::cout << 3;;;;;;;;;
std::cout << std::endl;
std::cout << 4;;;;;;;;;
std::cout << std::endl;
std::cout << 5;;;;;;;;;
std::cout << std::endl;
std::cout << 6;;;;;;;;;
std::cout << std::endl;
std::cout << 7;;;;;;;;;
std::cout << std::endl;
std::cout << 8;;;;;;;;;
std::cout << std::endl;
std::cout << 9;;;;;;;;;
std::cout << std::endl;
std::cout << 10;;;;;;;;
std::cout << std::endl;

Originally Posted by Bubba

However line counts really do not mean much to me in the grand scheme of things.

Just as a matter of interest, do employers give any weight to LoCs?

Would a programmer include LoCs on their resumes to show involvement/participation in projects?

Looks like < 200 lines is making a late surge.

Originally Posted by happyclown

Just as a matter of interest, do employers give any weight to LoCs?

Some do. Seasoned programmers will tend to look elsewhere for employment ..... lines of code is a very poor measure of programmer productivity.

Originally Posted by happyclown

Would a programmer include LoCs on their resumes to show involvement/participation in projects?

Only the inexperienced ones.

Programmers measuring progress in LOC are like airplane engineers measuring progress in weight. When I was even more unexperienced than right now, I did some ~10k LOC projects which I would easily do in maybe 1000 lines today, while increasing readability and performance by several orders of magnitude.

To this respect, LOC is just a measure of this: LOC.

Greets,
Philip

Originally Posted by Snafuist

Programmers measuring progress in LOC are like airplane engineers measuring progress in weight. When I was even more unexperienced than right now, I did some ~10k LOC projects which I would easily do in maybe 1000 lines today, while increasing readability and performance by several orders of magnitude.

Which is exactly the reason I like to keep track of it. It's not, "Whoa, look how heavy my airplane is," it's more like "Whoa, look how heavy my airplane is, something's wrong."

Originally Posted by Snafuist

Programmers measuring progress in LOC are like airplane engineers measuring progress in weight. When I was even more unexperienced than right now, I did some ~10k LOC projects which I would easily do in maybe 1000 lines today, while increasing readability and performance by several orders of magnitude.

Originally Posted by brewbuck

Which is exactly the reason I like to keep track of it. It's not, "Whoa, look how heavy my airplane is," it's more like "Whoa, look how heavy my airplane is, something's wrong."

I disagree with this... I see no analogy of airplane weight and lines of code as simply lines of code does not necessarily have a negative or positive impact on a compiled application. I never look at my lines of code and say "Whoa, this is too big... I could probably make it perform better if I reduce the number of lines." That's what I monitor memory and CPU usage for. I would say a better analogy to lines of code would perhaps be wiring for an electrical engineer. You can make the same circuit will 20 neatly organized wires or 30 messy, tangled wires... they may perform identically, but in the end, the difference is how easy it is to upgrade and maintain. That's why lines of code matter... because some day in the future, I might want to go back and look at this and actually know what's going on.

Originally Posted by abachler

1.3 million lines. It's an AI application that tests combinations of varous AI methods to find optimal processing sequences.

Holy crap! Was that all your code or the whole team? How long did it take to write all that?

Originally Posted by bithub

I don't look at LoC as any sort of measurement either way. If I start dictating my design decisions based on how many lines of code it generates, my code quality would go downhill pretty fast. Pretty much any well written code can be rewritten to its detriment using more or less lines.

There are quite a few reasons why, all other things being equal, fewer lines is better.

1. Sample-based profilers are more accurate when the program image is smaller, since a sample covers a larger percentage of the total code space.

2. More lines written means more lines that must be tested. If you are shooting for extremely high coverage numbers (90% or more) one of the easiest ways to get there is to start removing/refactoring code.

3. Fewer lines lead (in general) to faster compile cycles

I'm not saying that you should make your code more obscure just to reduce the line count. But between two equally clear, equally efficient solutions, I will always choose the shorter one.

During testing, when it turns out some entire module is not being used, my first question isn't "How can we improve the tests to hit this module better?" My first question is "Can we delete this module?"

Originally Posted by abachler

It's generally pretty good at finding a probably approximately correct configuration given enough runtime.

Sounds like a bad implementation of a brute force algorithm ;-)

Greets,
Philip

Originally Posted by abachler

1.3 million lines. It's an AI application that tests combinations of varous AI methods to find optimal processing sequences.

Is it designed at all? Or just implement as you think of it? If it's the latter, it'd be rather ... interesting.

What's it written in by the way?