You have completed the debugging, written the set-up instructions, and described your results. Then there’s a note about similarity checking in the submission criteria. Does that mean your source code, your report, or everything inside the project folder?
All three components may be reviewed, but not necessarily by the same tool. What gets checked depends on the software being used, the supported file types, and the settings chosen by the instructor. A successful upload does not mean that each file was checked for similarity.
Knowing the distinctions means you can prepare a submission without tagging every matched line as a problem.
Start With the Submission Workflow
Don’t focus on percentages until you know which parts of the assignment are actually being checked.
Think of an assignment with Python files, a Markdown README, and a PDF report. An instructor may run a code analyser on the Python files and send the report to a text-matching service. The README may be reviewed separately. This is one way of doing things, not the fixed arrangement.
Tool settings are what make these distinctions essential. JPlag allows educators to specify file suffixes, to target certain folders, and to ignore named files. Turnitin also differentiates between accepting a file and supporting it for a Similarity Report.
See the assignment instructions for separate requirements for source files, documentation and written analysis. If the instructions are ambiguous, enquire which parts undergo automated checks.
| Part of the assignment | What may be checked | Typical type of tool |
|---|---|---|
| Source code | Syntax, structure, similar code patterns | JPlag, MOSS or similar code-analysis tools |
| README | Written documentation, if included in text checking | Text similarity tool |
| Written report | Matching text against web, publications, and previous submissions | Turnitin or another document similarity checker |
Reviewing the documentation is a separate task from testing whether the code runs. Your report explains design choices, while the README covers installation and setup. Before using an online similarity checker, review both files and note any passages that may need closer attention. If your course uses a service such as safe assign, compare any flagged passages with the relevant sections of your documentation rather than focusing only on the overall percentage. For example, an explanation of input validation should match the checks in your programme. Borrowed definitions need references, and installation commands should work exactly as written. Finish by comparing the documentation with the submitted code rather than an earlier version that may behave differently.
Source Code: More Than Matching Words
Checking code similarity is not a normal document comparison adapted to a computer language.
JPlag, for instance, compares programming syntax and structure rather than just the raw text. Changes in formatting or variable names do not necessarily remove structural similarities between programs. Tools such as JPlag can still identify similar code segments that may require closer review.
But shared structure needs context. Consider an exercise where everyone has to implement the same short algorithm with a given function signature. Some similarity would therefore be expected. A reviewer should distinguish expected similarities caused by the assignment structure from similarities in code that students were expected to develop independently.
Starter code counts here. Moss allows you to exclude matches on any shared material you expect to see, such as code and libraries you provide. But that capacity does not determine if your course has such exclusions set up.
Your practical goal is to distinguish between instructor-provided material and the code you wrote yourself. Please keep any required templates, cite any acceptable code from outside, and explain major changes.
A code score does not mean that all comments or docstrings were compared as prose. Rather than interpreting one outcome as a judgement on the entire application, ask about coverage.
README: Treat Documentation as Submitted Writing
Pay as much attention to your README as you do to the programme.
Whether it gets into an automatic comparison is contingent upon the workflow. A check that is restricted to certain source-code files does not automatically include a Markdown page. A supported input format is also offered for separate text checking.
Emphasise the details the reader needs to use your submission. Explain the installation process, required inputs, expected output, and known limitations. Try the instructions yourself before submitting them.
For example, “Run the application” is not very informative. A more useful explanation will identify the command, working directory, and sample input file.
Be honest about limitations too. Perhaps the application rejects empty files but handles missing columns poorly. Explaining that behaviour gives the reader more than an inherited claim about “robust error handling.”
Keep required commands exactly as they need to be. Do not rewrite a valid installation command simply to make it look different. Focus on making the explanation around it specific to your implementation.
Report: Text Matches, Not Proof of Understanding
When a written programming report is submitted via a compatible procedure, document similarity testing can be applied. Turnitin checks your writing against sources including web material, prior student submissions, and publications. Matching texts are shown for your review.
The explanatory parts of the study are well worth a thorough reading: the background material, the descriptions of the algorithms, the discussion of the testing, and the conclusions.
Rather than writing the report based on broad concepts, describe what happened in your project. Why did you take that approach? Which test revealed a weakness? What did you find out when you looked into it?
Suppose you were comparing two search algorithms. Describe your inputs, the conditions under which you tested them, and the results you saw. Quote technical explanations that are borrowed, but identify your own conclusions.
There is also a distinction between text comparison and code analysis. Finding the same text in a document is not the same as analysing the programme structure of that document. Various forms of checking exist, such as Turnitin's text-matching and JPlag's structural approach.
Please follow the required format when submitting and make sure that your report is still readable. Turnitin’s guidance states that appropriate PDFs should have selectable text rather than just scanned photos.
What Is Your Work Compared Against?
“Checked for similarity” doesn’t notify you about possible sources of comparison.
JPlag compares the programmes given to it. The manual clearly indicates that it does not search the internet. Instructors may incorporate current entries and collections from prior batches. Those older entries have to be considered in the analysis.
Turnitin has a distinct model and checks the text against the collections it has access to. Its documentation includes internet content, archived student work and publications. That is not to be taken as access to every document or repository available.
So the interesting question is not “What checker is used by this course?” Ask what is being checked and what it is being compared to.
A Similarity Percentage Is Not a Verdict
A highlighted match is something to look at. It does not explain why the match is there.
Tools such as MOSS identify similarity, not plagiarism. A high similarity score should be treated as a signal for human review rather than as a verdict by itself. Human review is still required.
Correctly quoted and referenced content might be a match for written work too. Turnitin allows for specific exclusions such as quotations and bibliographic material that can alter the score shown.
Don’t treat a specific percentage as a target. Instead, think about the relevant piece, its source, and the rules of the assignment.
If a result is questionable, ask for the matched parts instead of debating about the headline figure. Bring the assignment template, related references, and actual development data to the discussion.
Check the Whole Submission Before Uploading
Instead of checking them separately, a helpful final check-in integrates the three components:
- Code: Identify the parts provided and the external contributions allowed, and make sure the submitted version runs.
- README: Test each instruction and eliminate any claims that do not describe your implementation.
- Report: Confirm findings, attribute sources, and ensure the explanation matches the code submitted.
Read through the files again. If the report describes input validation, find that validation within the programme. If a README promises an output file, verify if the application produces one.
It’s not about making every line different from everybody else’s. Submit a project whose code, instructions, and analysis are consistent with one another—and where borrowed material and original contributions are clearly identified.
