Skip to main content
added 143 characters in body
Source Link
Aurora0001
  • 3.5k
  • 16
  • 43

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 golfwriting clear, maintainable code, not playing code golf, so a longer, explicit solution may actually be better.

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!

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.

1You might also know a variant of this as the ROT13 cipher. 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!

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.

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!

Source Link
Aurora0001
  • 3.5k
  • 16
  • 43

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.

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.


1You might also know a variant of this as the ROT13 cipher. 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.