How to Write a Computer Science PhD Thesis in the Discipline’s Register: Voice, Tense, Algorithms and Reproducibility (2026)

A computer science thesis is written in the register of the field: precise claims tied to evidence, consistent notation, past tense for what you did and present tense for what the thesis contains, and enough detail on the evaluation and the code that another researcher could repeat it. Check conventions such as “I” versus “we” with your supervisor and department, then apply them consistently.

Why does register matter in a computer science thesis?

A computer science thesis is read by examiners who are experts in your subfield and who have read hundreds of papers in the field’s own style. They expect the thesis to sound like the discipline: direct, specific and measured. They are also reading something that a conference paper is not, a single sustained argument with a thesis statement and several contribution chapters. Many candidates arrive at the writing-up stage with three or four papers and discover that stitching them together produces a document that reads as separate papers, with different voices, different notation and different definitions of the same term. Most of the work of writing the thesis in the right register is making those papers into one text. The structure of that argument is covered in how to structure a computer science PhD thesis; this guide is about the sentences. The register of another discipline is described in how to write a law PhD thesis in the discipline’s own register, which is a useful contrast.

Should you write “I” or “we”?

There is no universal rule, and the safest answer is to follow your department’s theses and your supervisor’s preference. Computer science papers often use “we”, including in single-author work, partly as a convention that includes the reader. Many theses use “I” for the candidate’s own work, because a thesis is examined as an individual’s contribution and the examiners need to know what you did. A workable approach that combines both:

• Use “I” for decisions, designs and analyses that you carried out yourself, particularly in the introduction, the contribution statements and the conclusion.
• Use “we” for work that was done jointly, in chapters adapted from co-authored papers, and say at the start of the chapter exactly what your contribution was.
• Use “we” in the inclusive sense for reasoning shared with the reader, as in “we can see that the bound holds”, only if your department’s theses do.
• Whichever you choose, apply it across the thesis. A mixture produced by pasting papers together is a signal that the chapters have not been rewritten.

Whatever your choice, the clarity of authorship matters. Universities set rules for jointly authored work in a thesis. For example, the University of Edinburgh’s Postgraduate Research Thesis Guidance, effective from 1 August 2026, says jointly or multiple-authored publications can be included but students must ensure appropriate permission is obtained and their contribution is clearly indicated. The detail of that guidance is in Edinburgh’s PhD thesis rules for 2026, and your own university will have its own version.

Which tense should you use?

Use tenses to tell the reader what kind of statement they are reading.

The most common slip is mixing tenses within one paragraph about a single experiment. Describe the procedure in the past and the results shown in a table in the present, and keep the distinction visible.

How should you word claims?

Computer science theses are examined on whether claims are supported, so calibrate the verb to the evidence. “Outperforms” needs a stated baseline, a metric and a comparison that goes beyond a single run. “Novel” needs a literature review that shows the gap. “Scales” needs a stated range and a measurement. When the evidence is partial, say “suggests” or “is consistent with”. The choice of verbs and what each commits you to is discussed in which reporting verb you should use. Here are two illustrative rewrites.

• Before: “Our method is much faster than existing approaches.”
• After: “On the three benchmark datasets, the method reduced mean running time by between a quarter and a half compared with the strongest baseline, over 10 runs per configuration.”
• Before: “The proposed system solves the scalability problem.”
• After: “The system sustained the tested workload up to the largest size evaluated, and Section 6.4 discusses what is not known beyond that size.”

The numbers in these rewrites are invented for illustration. The point is the form: the sentence names what was compared, how, and how often.

How do you write algorithms and notation?

Notation is where papers stitched into a thesis most visibly disagree. One chapter uses n for the number of nodes and another uses N; one defines a graph as G = (V, E) and another as G(V, E); a symbol is reused for two different things. Fix this deliberately.

1. Build a notation table before you rewrite the chapters, with every symbol, its meaning and the chapter where it is introduced, and then change the text to match it.
2. Define each symbol at first use in the chapter, even if it was defined earlier. Examiners read chapters out of order.
3. State input and output for every algorithm before the pseudocode, and say what the algorithm guarantees.
4. Pair pseudocode with prose. Give the pseudocode for precision and a plain-language paragraph for the idea, and refer to line numbers when you discuss steps.
5. State complexity or correctness claims precisely and say whether they are proven in the thesis, proven elsewhere with a citation, or observed empirically.
6. Put long code in an appendix or repository and keep the body for the parts that carry the argument.

For a systems thesis, describe the architecture in a stable order: the problem it addresses, the components, how they interact, the design decisions and the alternatives you rejected, and finally the limits. Examiners often ask about the alternatives, so write them down.

What should an evaluation section report?

An evaluation is the part of a computer science thesis that most often attracts viva questions, because it is where claims meet evidence. Report enough that another researcher could repeat it.

• Research questions that the experiments answer, mapped to the claims in the introduction.
• Datasets or workloads, with source, size, any preprocessing and how splits were made.
• Baselines and why they are the right comparison, including the strongest available and not only the easiest.
• Metrics and why they measure what you claim.
• Environment: hardware, operating system, language and library versions, and random seeds where randomness matters.
• Number of runs and variability, shown as spread or confidence intervals, and any statistical test with its assumptions.
• Threats to validity: what might make the results misleading, including whether the benchmarks resemble real use.

Report negative and mixed results as carefully as positive ones. A clearly stated negative result strengthens a thesis because it shows you understood the limits of the method, while an omitted one is a viva question waiting to happen.

How do you handle reproducibility, code and software citation?

Examiners in computer science increasingly look for enough information to repeat the work. A short reproducibility statement, in the evaluation chapter or an appendix, can say where the code and data are held, which version was used and how to run the main experiments. Archive the version you used in a repository that gives a persistent identifier, rather than pointing to a moving development branch. When you use other people’s software, cite it. The FORCE11 Software Citation Working Group summarised the recommendations of its work between June 2015 and April 2016 in “Software citation principles” (Smith, Katz, Niemeyer and the working group, PeerJ Computer Science, 2016), whose goal was a consolidated set of principles to encourage consistent software citation. In practice, cite the software with its authors, title, version and a persistent address, as you would a paper.

How do you turn papers into chapters?

Papers are written for reviewers who have a page limit and a short attention span; a thesis is written for examiners who read everything. Turning a paper into a chapter means more than pasting it in.

1. Restore what the paper cut. Page limits remove derivations, extra experiments and negative results. Put the useful ones back.
2. Add a chapter introduction and conclusion that place the work in the thesis argument and link to the neighbouring chapters, in the spirit of how to signpost a PhD thesis so examiners can navigate it.
3. Harmonise terminology, notation, tense and person with the notation table and the choices above.
4. State your contribution at the start of any co-authored chapter, in a form your university accepts.
5. Check permissions. If a publisher holds the copyright, check what you may reuse and acknowledge the original publication.
6. Remove the duplication. Background sections that repeat across papers belong in one place, and related work should be organised by theme, not by paper.

The same rewrite also helps your proposal-to-thesis continuity: the claims you made in a computer science PhD research proposal should be the ones the thesis now supports, or explain why they changed.

A final-read checklist

1. Is person (I, we) consistent across all chapters, and is authorship of co-authored work stated?
2. Is tense used consistently for procedures, results and thesis structure?
3. Is every claim matched to evidence in the thesis, with the verb calibrated to the evidence?
4. Is every symbol defined at first use and consistent with the notation table?
5. Does each evaluation report datasets, baselines, metrics, environment, runs and variability?
6. Is there a reproducibility statement, and is the code version archived?
7. Is software cited, with versions?
8. Do the contribution claims in the introduction match the conclusions in the final chapter?

Frequently asked questions

Should a computer science thesis use I or we?

Follow your department’s theses and your supervisor. A common approach is I for your own decisions and analyses and we for jointly authored work, with the split stated in each co-authored chapter, applied consistently across the thesis.

Which tense should I use for experiments?

Past tense for what you did and what earlier researchers did, present tense for established facts, for what a table or figure shows and for what the thesis or a chapter contains.

How do I turn several papers into one thesis voice?

Rewrite each chapter so that terminology, notation, tense and person are consistent, add an introduction and conclusion to each chapter that place it in the argument, and state your own contribution to any co-authored work.

What should I report about an evaluation?

Datasets, baselines, metrics, software and hardware versions, random seeds where relevant, the number of runs, a measure of variability, and any statistical test, together with threats to validity.

How do I cite software I used?

Cite it as you would a paper, with authors, title, version and a persistent identifier or repository address. The FORCE11 Software Citation Working Group set out principles for this in the 2016 paper Software citation principles.

Can I include published papers as thesis chapters?

Many universities allow it, with conditions. For example, the University of Edinburgh’s thesis guidance says jointly or multiple-authored publications can be included but students must ensure appropriate permission is obtained and their contribution is clearly indicated. Check your own university’s rules.

How do I write an algorithm so examiners can follow it?

Define every symbol at first use, use consistent notation across chapters, give the pseudocode and a plain-language description, state the input and output, and say what you can and cannot prove about its behaviour.

Is a reproducibility statement necessary?

It is not universally required, but examiners in computer science increasingly look for enough detail to repeat the work, and a short statement saying where the code and data are and what version was used is good practice.

What should I do about negative results?

Report them with the same care as positive ones and say what they show. A clearly reported negative result strengthens a thesis; an omitted one invites a viva question.

What do examiners flag in the writing of a computer science thesis?

Common queries are claims stronger than the evidence, undefined notation, inconsistent terminology between chapters, missing evaluation detail and unclear attribution of contributions.

Finishing the write-up on schedule

Rewriting papers into a single voice is a slow, detailed job at the point in the PhD when time is shortest. Tesify is used by 9,000+ students across 15,000+ chapters to organise a thesis chapter by chapter, and the thesis stays 100% written by you. The claims, the notation and the evidence are yours; a chapter plan helps you keep track of which chapters have been harmonised and which have not.