Some friends of mine coded Tetris in our school's Delphi course. It worked, and when we all had to present our projects in the end everyone was stunned by them, because they scrolled through one huge file showing some thousand lines of code. What they actually did was draw every Tetris block in every orientation in its own function and for every keystroke and every block and (!) every orientation they had a separate function checking the block against the level. This was so plain stupid I hardly fell of my chair when they showed me the code.
I want to cite Steve Ballmer:
In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand line of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 50K-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS/2, how much they did. How many K-LOCs did you do? And we kept trying to convince them - hey, if we have - a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less K-LOC. K-LOCs, K-LOCs, that's the methodology. Ugh! Anyway, that always makes my back just crinkle up at the thought of the whole thing.
Honestly, SLOCs is just not the way to compare source code. I know that you all might think size matters, but it just makes my head ache when I read something like this:
But I've written all this code more than once, from scratch, cause it used to be WDL and I ported it... so can I count it twice?
If I was interviewing someone for a job and he told me something like that he'd not get the job.
What I do find interesting, though, is in how much source files you separate your code.
