Define what the code is meant to demonstrate
Analysis code can serve three distinct purposes. It can show how a particular claim was derived, allow a technical re-run, or become a reusable research output. A PDF appendix mainly supports the first. A versioned, archived repository can support all three. Before choosing a location, write down the intended test: should an examiner inspect a handful of commands, regenerate the complete result, or adapt the workflow to new data?
Whichever location you choose, the dissertation must point to the code precisely. State the filename, version and relevant section. A bare footnote URL is weak evidence because the destination may change, access may disappear and the exact assessed revision remains ambiguous.
When an appendix is the clearest option
An appendix suits compact scripts that make sense without a larger file tree and will be archived with the thesis. It is immediately available to examiners, follows the same citation logic as the document and can be numbered precisely. Small calculations, coding rules and queries that substantiate one central table are particularly good candidates.
The limitations are execution and maintenance. Line wrapping, hyphenation and typographic quotation marks can corrupt code. Hundreds of pages can also obscure more useful supporting material. Print only the explanatory core in a legible monospaced format and submit the original plain-text file where permitted. Do not fill the appendix with automatically generated libraries or lengthy output.
What a repository adds
A repository can keep structure, history, documentation, tests and environment specifications together. Cite a fixed release or commit rather than the moving head of the main branch. Where appropriate, preserve the release in a long-term archive with a DOI or another persistent identifier. GitHub documents citation files and releases, while Zenodo describes how released versions can be archived.
Public reuse also needs a licence. Code that is visible online is not automatically licensed for reuse. Treat the software, data and narrative documentation separately where rights differ. A useful README explains scope, prerequisites, installation, one clear start command, inputs, outputs, authorship and known limitations.
Confidentiality comes before convenience
Review the complete version history, not only the current files. Deleted tokens, internal host names, personal file paths and old datasets may survive in earlier commits. Use test fixtures or synthetic examples when real research data cannot be shared. Put placeholders in a documented example configuration and keep credentials outside version control.
Code may itself reveal small groups, collection sites or sensitive exclusion decisions. Where that risk is material, an institutional archive with an embargo or controlled access may be appropriate. Provide public metadata stating what is withheld, why, and how a legitimate reviewer can request access. This guide offers general publication information, not legal or data-protection advice.
The minimum package for an inspectable submission
- Fix the submitted state as a release or identified commit.
- Order scripts by execution and identify one entry point.
- Describe software versions, dependencies and installation.
- Separate raw input, intermediate data and generated outputs.
- Add a licence, preferred citation and contact route.
- Test the package in a clean folder and log the result.
Cite the specific revision rather than the hosting platform in general. Depending on the required style, the record can contain creators, title, year, version, archive, DOI or URL and access date. Our guide to citing a GitHub repository works through the identifiers.
A hybrid often gives the strongest evidence
The choice need not be exclusive. A short key excerpt in the appendix can keep the argument intelligible, while the repository carries the complete executable package. Both should identify the same release. This preserves immediate readability without forcing a working codebase into a printed layout. Finally, test all public links from a signed-out browser and archive the revision that the thesis actually cites.
Keep a small manifest listing each submitted item, its purpose and checksum. If the institution accepts supplementary files separately, include their filenames in the thesis and deposit record. A reader should never need to guess whether “analysis_final2” or the repository main branch produced the table under discussion.