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).

  • $\begingroup$ If you can define 'worth asking', this question would be better. I'd hope you remember the difference between 50 LOC and 50k though... $\endgroup$ – Sean Houlihane Aug 26 '17 at 20:30
  • $\begingroup$ Was she asking them to come up with a figure from memory, or did they have a computer with the source code in front of them? $\endgroup$ – Gilles Aug 26 '17 at 20:34
  • $\begingroup$ @Gilles She was asking them to answer it precisely to the .. say 673 lines of code and they had a computer with source code in it but this question was asked during project evaluation. Her question was normally: Now come to the code.. Wait a minute! Before opening it, tell me how many lines does it have? and introspection began $\endgroup$ – Failed Scientist Aug 26 '17 at 22:50

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 cipher1 program. If you're aware of it, you'll know that it can be trivially solved by using modular arithmetic2:

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.3

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.


  • 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.

1You 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!

2There'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.

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


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.

  • $\begingroup$ regex can be readable. If you break them up. Lots of separate bits that you join together. E.g. LetterOrUnderscore+LetterOrUnderscoreOrNumber+"*" $\endgroup$ – ctrl-alt-delor Aug 26 '17 at 22:11

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.


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.


In any case, I could not count lines of code. Even looking for outliers is through with dangers. I remember the quality manager coming to me with a big grin on his face. He had just got a new code metrics analyser. He had run the code for a large medical pump project (that I was working on), through it. It showed that one of my modules had a very, very, very high value for coupling. Much, much higher than any other module. I asked to see the data, it showed near zero for every other metric. I smiled and looked across to the name of the module, it was ……… something_factory. Yes, it was this modules job to have all the coupling, so other module could have none. I looked back at the quality manager, with a smile. But he did not understand why I was smiling. It took several meetings with my boss and human resources, to finally get him off of our backs.


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.


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.