Comparing student code against past submissions

===============================================

 

A short account of comparing student code against past submissions from the side that has to sit in the meeting afterwards rather than the side that runs the comparison.

 

Deciding what the output is for

-------------------------------

Publish the method to the people being measured. Students and candidates who know what is compared, against what, and what happens next behave differently from those who do not — and the difference shows up as less of the thing you were detecting. Detection and deterrence are not in tension here; secrecy about the method buys a marginally higher catch rate and gives up nearly all of the deterrent effect.

 

What the reviewer actually needs

--------------------------------

Staff turnover is the real adversary. The person who chose the threshold, knew which languages were parsed properly and remembered why one course was excluded will leave, and what remains is a number nobody can defend. Written-down reasoning is not bureaucracy here; it is the only mechanism by which a practice outlives the individual who set it up.

 

Making it survive the year

--------------------------

Self-plagiarism and legitimate reuse need separate handling, and a similarity score cannot tell them apart. A student reusing their own prior submission, a developer reusing a snippet from an internal library and an author lifting a file from a public repository can all produce the same number. Only provenance separates them, so provenance has to be captured at the moment of the match rather than reconstructed later.

 

Putting it into practice

------------------------

Corpus, provenance and a readable report — a code similarity checker without all three is a demo.

 

Reference: https://codequiry.com