How many lines does your code have?

Question

This question was prompted by observing a faculty member in projects evaluation. Before asking anything else, the very first question she asked from every student was: "How many lines does your code have?"

So I need to know how important this question is and is it really worth asking the nervous students who have just arrived to present their full projects rather than a routine programming assignment?

P.S: While I am neither in favour nor against this question but I have been coding since 2009/10 and my personal experience reminds me that I still don't remember the lines of code for even my own freelancing softwares (even for my thesis program - by don't remembering I mean I even don't remember whether it was 1200 lines or 1800 lines).

Answer 1

What's the point?

Why does the number of lines in the project matter all that much? Unless the code is extraordinarily long or short (i.e. orders of magnitude away from what is expected), lines of code aren't a good indicator of whether a project is good or bad.

I've heard of one example where some students were set the task of creating a Caesar cipher¹ program. If you're aware of it, you'll know that it can be trivially solved by using modular arithmetic²:

def encrypt(ciphertext, shift):
    output = ''
    for character in ciphertext:
        output += (character + shift) % 26
    return character

So, the 'smart' solution uses 5 lines.

One student submitted a solution to that function with 1382 lines.³

Wait, what?

I suppose you'd quickly realise that this student's solution was... sub-optimal... if you asked them how many lines when they presented their project.

And here's why:

def encrypt(ciphertext, shift):
    output = ''
    for character in ciphertext:
        if shift == 1:
            if character == 'A':
                output += 'B'
            elif character == 'B':
                output += 'C'
            ...

So now you can see the merits of using code length to spot solutions that are over 250x longer than necessary.

But when the difference is much smaller, why bother using lines as an indicator of anything? Hopefully, students are writing clear, maintainable code, not playing code golf, so a longer, explicit solution may actually be better.

Equally, treating a higher LoC measurement as a better project is a bad idea. If you do that, you're encouraging unnecessarily verbose solutions, like our student who wrote 1400 lines for a 5 line problem.

Summary

• LoC can be useful for spotting really badly wrong solutions, but setting 'targets' with it can be harmful.

• Asking for the length directly is probably pointless—instead, just take a look at that when you review the code and mark it.

---

¹You might also know a variant of this as the ROT13 cipher where the shift is 13. This has the convenient property of being self-inverse, so you don't need to subtract to decrypt in a separate function. If our student was really clever and wanted to implement that in Python 2, they could have just written input().encode('rot13'). It's a whole new world up here!

²There's a bit of a lie-to-children here, if you're not paying attention. That code assumes that all the letters you want to encode are encoded from 0 to 25 (e.g. 0 = A, 1 = B). That's not how character encodings work in reality (there's an offset in ASCII before you get to the capital letters), but it's not relevant for the example.

³I cheated and calculated the amount of lines you'd use from that approach, rather than actually writing the whole thing and counting the lines.

Answer 2

I'm surprised that you didn't ask this teacher why she asked this question and how it fits into her overall evaluation.

I don't think anyone can answer this question without more information. We can speculate on situations in which it might be a good question and we can speculate on situations in which it might be a terrible question, but we can't know unless we know why it was asked. Some of the other answers here provide such speculation.

Moreover, you don't say how accurate the teacher expected the answer to be. And we don't know anything about how the teacher intended to use the answer.

I have, myself, asked students at the beginning of a project to tell me how big their self-defined project will be using various measures. That sounds especially stupid until you know that my only goal was to get them to start to think about estimation, which they had never done. The numbers they gave weren't a goal for the project, but only a source of reflection at the end. So at the end, such a question would be completely natural and expected. And expected to be widely divergent from the earlier estimate, of course, since this was their first attempt.

Answer 3

I agree with the other posters here: using num LoC as an indicator is a very poor assessment of the code.

I would ask instead:

1) Does it work

2) Is it readable?

3) Has it followed the correct conventions? Spacing, layout, indentation etc.

4) is it modular: resusable, logically broken into functions/methods with appropriate names for funcs/methods and variables

5) Is the documentation adequate (docstring/header, method docs, comments only where appropriate)

Less lines of code does not always mean more efficient.

Using regular expressions may be pretty cool, but can make it very difficult to read for anyone that has to do maintenance on the code, or even to understand.

Answer 4

Reason 1 : Because without printing it out you can not weigh it.

When I was an university, there was a myth that some lazy teachers (I don't know the technical terms for the roles), would weigh your reports, and give a grade base on that. I heard of one student that handed in some work with a load of blank paper attached, and got a good grade.

Reason 2 : To see how complex it is.

I remember a story by Michael Jackson, about judging how brilliant some one is. I will include the last 3 paragraphs here.

“Terrific,” I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. “But what about Jane?” I said. “I thought Jane was very good. She picked up the program design ideas very fast.”

“Yes,” said the DP Manager. “Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet — if you see what I mean?”

I saw what he meant.

Reason 3 : To see how complex it is.

Over complex code is bad, see in working out the final grade, the number of lines of code, goes some ware in the denominator.

Reason 4 : Looking for outliers

This is the only one that would make any sense, but people do a lot of thinks that don't make sense.

Because they knew how many line it should take, and they were looking for statistical outliers. If the line count is way off then it is a sign of a problem.

Summary

In any case, I could not count lines of code. Even looking for outliers is throught with dangers.

A few years back, when I was a software engineer. Some one introduced a software metrics tool. It measured Mccabe complexity (various complexities of the code). It was a good tool, and very useful. You could find parts of the code that were un-usual. Often you could find bugs by examining these parts of the code.

One day the head of QA came to me, screaming. He was waving a bit of paper with the results of the tests. It showed that a module, that I had written had a complexity for class dependency that was off the chart. I pointed out that all the other complexity metrics were close to zero. He screamed, "but what about this one". I pointed out, that this class was a factory, it was its job to own this complexity, because it would be worse to have it spread about. I said "if it was spread about, then the metrics would not find it, ..." he interrupted "then spread it about". I continued "... but then the code would be much more complex." -- He looked at me blackly.

We stopped using the tool shortly after that. A shame. It was a good tool. It helped us find bugs. However it did not tell us where the bugs were. It told us what the probably bug density is, if you knew how to read it.

So yes lines of code can be useful, but only as a statistical tool.

Answer 5

Because it is an easy question to start with?

It only takes seconds to count the LOC in a project. Faster than asking. So the point is not the factual information by itself.

The point is starting an interview with a nervous student, about a project of some size. Not a 20 lines exercise for which an interview with each student is a waste of time.

Question followed by:

• how many files?
• What are the most important ones?
• Their responsibilities?

and

• Please show some significant part of the code and explain it to me.

Answer 6

As others have noted, the simple lines of code doesn't always have a lot of meaning in terms of the project's quality. My guess is that the question is primarily intended to catch the outliers, those projects with a lot less or more code than average.

In the programming industry I have noticed an odd trend among certain programmers that go through great lengths to make their code as terse as possible. Variables are short, each line is crammed with as many instructions as possible, etc. Some constructs such as "comprehensions", streams, lambdas or map/reduce allow you to pack a lot of complexity into a few lines. This results in code that takes up the minimum of space but is often hard for humans to interpret, as if the programmer forgets that humans look at code as often as computers do. Programs like this would have far fewer lines of code than average but be of poor quality.

On the other hand, a common mistake made by novice programmers is to write a routine, then copy and paste it and make a few small changes to it. Sometimes called "copy pasta" this is a poor programming practice because it results in code that is redundant and the same bug can appear in many places in the code. Restructuring and refactoring code can be tricky and time consuming and when programmers get in a hurry they sometimes just copy paste. Programs like this would have far more lines of code than average but be of poor quality.

Of course the simple line of code check doesn't catch either of these situations, there are automatic ways of trying to detect code quality but they are much more complex and subjective.

Answer 7

Unless the student is some kind of an expert already, lines of code will be a easy way to filter out those who have no idea what they are doing.

Lets say the lab manual has about 30 lines for the bubble sort implementation. Leaving out exceptionally talented students, most students would have at least 30 lines, and if they don't they probably haven't written the code.

Its the same concept as in reports. Faculties will ask you to write 2 pages, but what if the content only merits 1 page or 4? Its just another way of valuation.

Answer 8

The scenario here doesn't really give much context for the evaluator's question. Most importantly, we have no information about what she did as a result of the opening question. It is perfectly possible that this opening was a hidden request for context - is the presenter actually familiar with the code or just doing the PR part of the project? By asking a 'harmless' question which has no right answer, it makes the rest of the questions much easier to pitch.

There is nothing worse when doing an interview than asking an opening question which your student doesn't understand well enough even to be able to guess the answer.