Code similarity detection platform

Source similarity is not the same as text similarity. Two independently written solutions can share required APIs and instructor-provided templates. Two related submissions can look different after identifiers, whitespace, comments, or statement layout change. A useful review tool has to reduce those superficial differences without erasing meaningful program structure.

The platform was built for programming-course analysis. My responsibility was the C and C++ similarity core and its path into an asynchronous, anonymized review workflow.

Source first passes through language-aware tokenization. Comments and formatting disappear; selected identifiers and literal forms are normalized; tokens that originate in the assignment template are subtracted. The resulting stream represents more of the student's structural choices and less of the surface presentation.

Fingerprinting reduces the candidate space before a more detailed Greedy String Tiling comparison identifies long, non-overlapping matches. The pipeline records enough positional information to map a match back to readable source for a reviewer.

Required starter code can dominate a short assignment. If it remains in every submission, the similarity score rewards compliance with the assignment rather than evidence of shared authorship. Removing template-derived regions before comparison materially improves the signal available to the rest of the algorithm.

The subtraction step also needs restraint. Overly broad removal can discard student choices adjacent to a template. Matching therefore operates on normalized token sequences with explicit boundaries and retains provenance for later display.

A similarity number is not a verdict. Analyses run asynchronously because a course-sized comparison set is not an interactive request. Results are anonymized and presented side by side with matched regions highlighted, allowing an instructor to inspect evidence without the interface claiming certainty the algorithm does not have.

The separation between candidate generation, comparison, and reporting also makes the system testable. Known transformations probe normalization; constructed pairs probe tiling; whole-class fixtures probe ranking and throughput.

The project placed third among forty teams in the course evaluation. The competitive result was gratifying, but the stronger outcome was the explanation path: a reviewer could move from a ranked pair to the source regions that produced it.

This project reinforced a broader engineering rule. Detection systems should help people examine evidence. When the domain has consequences for a person, a bare score is an incomplete interface.

The algorithm finds a trail. A reviewer decides what the trail means.