How to write a literature review in computer science

Computer science literature moves faster than the systems that record it. The result you need to discuss may be a preprint from last month, the definitive version of a method may be a conference paper rather than a journal article, and the strongest evidence for a claim may sit in a benchmark table. A computer science literature review has to handle all of that while still meeting the standards examiners apply to any thesis chapter.

The good news is that CS has developed its own review machinery: taxonomy-driven surveys, systematic literature review guidelines from empirical software engineering, and snowballing techniques that exploit the citation graph. Used deliberately, they produce a related-work chapter that actually positions your contribution.

This guide covers where to search, how to handle conference papers and preprints, taxonomy-first structure, systematic methods, a worked outline, and how to keep an AI-assisted review grounded in the papers you hold.

What a computer science literature review needs to do

Most CS theses need one of two forms. The survey-style related-work chapter organises the field into a taxonomy and places your contribution inside it. The systematic literature review, common in software engineering, follows widely used guidelines: predefined questions, documented searches, explicit criteria, and structured data extraction. Name which one you are writing, because they are marked differently.

Either way, the chapter carries your novelty claim. Examiners test that claim against the completeness of your coverage: a missing line of related work reads as either a search failure or a dodge, and a single overlooked paper can turn a claimed contribution into an incremental one. The review is where you show the claim survives contact with the field.

Decide scope explicitly. How far back you go depends on the subfield: foundational papers stay in scope however old they are, but a survey of methods can often bound itself to the era after a clear inflection point in the field, provided you name the boundary and justify it.

Where to search: ACM, IEEE Xplore, DBLP, and arXiv

CS is spread across publisher libraries, bibliographic indexes, and preprint servers, and each has a role:

CiteDash's Literature Finder searches an internal corpus plus live OpenAlex, Semantic Scholar, arXiv and PubMed in one query, which suits CS well: preprints surface alongside published versions and the citation trail, and you can chase both directions from any paper you save.

Set up alerts where the databases support them, and note which venues in your subfield are not well indexed anywhere, because workshops and some niche conferences still need manual sweeps of their proceedings pages.

• ACM Digital Library: core coverage across most of computer science, from systems to HCI
• IEEE Xplore: networking, hardware, signal processing, and a large share of machine learning venues
• DBLP: the cleanest bibliographic index of CS venues, ideal for tracing an author or a conference series
• arXiv: where much of the field appears first, especially machine learning and theory
• Semantic Scholar and Google Scholar: citation graphs and broad discovery across venues
• Scopus or Web of Science: useful when your committee expects traditional citation metrics

Source types: conference papers, journals, preprints, and artifacts

In most areas of computer science, peer-reviewed conferences are the primary publication venues, and a review that privileges journals misreads the field. The full mix looks like this:

• Peer-reviewed conference papers: the primary venue in most CS subfields
• Journal articles: archival or extended versions, central in theory and software engineering
• arXiv preprints: often the newest results, unreviewed until accepted somewhere
• Theses and technical reports: implementation detail that never fits in the paper
• Code, datasets, and benchmarks: artifacts you may need to cite alongside the papers
• Standards and RFCs where the topic touches protocols or interoperability

Handle preprints and versions carefully

Cite the peer-reviewed version when one exists. Before you rely on an arXiv paper, check whether it was later accepted at a venue, and note which version you read: a v1 and a v4 of the same preprint can differ in results, claims, and framing.

Calibrate your prose to review status. An unreviewed preprint reports a result; it does not establish one. Examiners in CS are used to preprints and will not penalise you for citing them, but they will notice if you treat every preprint claim as settled.

Treat leaderboards and benchmark claims with the same version discipline. Results move as datasets are revised and evaluation scripts change, so record the dataset version and evaluation protocol behind any number you quote. Code availability is worth noting too: a result with released code and reproducible settings deserves more weight in your synthesis than one without.

Structure: build a taxonomy first, then place the papers

Strong CS reviews are organised by a taxonomy of the problem space: the approaches, their assumptions, and their evaluation settings. Weak ones are ordered by year or by paper. Design the taxonomy before you write, revise it as your reading sharpens, and let its dimensions become your section structure.

Comparison tables do the disciplined work. Papers as rows; approach, dataset, evaluation metric, and assumptions as columns. Filling the table forces you to read carefully, because every cell has to come from the paper itself rather than from a survey's summary of it.

Derive the dimensions from your research questions rather than from convenience. If your thesis claims efficiency gains, computational cost must be a column; if it claims generality, the range of evaluation settings must be. A taxonomy whose dimensions match your claims is what lets the review conclude something rather than merely organise.

Systematic literature reviews and snowballing

If you run a formal SLR, follow the recognised sequence: research questions, search strings per database, inclusion and exclusion criteria, quality assessment, and structured data extraction, reported with PRISMA-style counts and a flow diagram. Software engineering committees in particular will expect the protocol to be reproducible.

Complement string searches with snowballing: backward through the references of included papers, forward through the papers that cite them, iterating until new papers stop appearing. The citation graph is the most reliable map of CS, because terminology shifts faster than citation links do. For running wide searches efficiently, see how to search 250 million papers with the Literature Finder.

Deduplicate as you merge sources, because the same work can appear as a preprint, a conference paper, and an extended journal version. Pick one canonical entry per work, note the variants, and count it once in any systematic tally.

A worked outline for a computer science literature review

Here is an outline for a thesis on graph neural networks for traffic forecasting, adaptable to most CS topics:

The comparison section earns its keep at the defense. When a committee member asks how your method differs from a paper you cited, the answer should already be a row in your table.

Adapt the branches to your own taxonomy, and keep the final branch narrow: it should contain the handful of papers your contribution is directly measured against, read more closely than anything else in the chapter.

• Introduction: scope, search method, and the taxonomy that organises the chapter
• Problem formulation: how the literature defines the task and evaluates it
• Branch 1: classical and statistical approaches, and where they hit limits
• Branch 2: deep learning approaches grouped by architecture family
• Branch 3: the specific line of work your thesis extends
• Comparison: datasets, metrics, and evaluation settings across approaches
• Open problems and gap: what the taxonomy shows is missing, and your contribution

Keep the review current while you write

Months pass between writing the chapter and defending it, and in CS that is long enough for the state of the art to move. Re-run your saved searches on a schedule, watch for new papers citing your anchors, and state the date of your final search in the chapter so the boundary is explicit.

CiteDash's library reading statuses help manage a moving pile: you can see at a glance what is screened, what is read, and what still needs extraction, which matters when new papers keep arriving during write-up.

Conference cycles give you natural checkpoints: after each major deadline and proceedings release in your subfield, sweep for new entries in your taxonomy. A review refreshed on that rhythm never drifts far from the field it describes.

Write related-work prose that positions, not lists

The prose form examiners want is comparative: state the shared idea of a group of papers, name the representative works, then say precisely how your approach differs along one of the taxonomy's dimensions. One paragraph per group, not one per paper, and the differences stated in technical terms rather than adjectives.

Precision earns trust. Attribute techniques to the papers that introduced them, distinguish concurrent work honestly, and resist the survey-paper habit of citing twelve papers in one bracket without saying what any of them did. A committee reads the related-work prose as a proxy for how carefully you read.

How a computer science review stays grounded in CiteDash

Fabricated references are a well-documented failure mode of general chatbots, and CS paper titles are easy to fake plausibly. CiteDash removes the possibility: every citation is a database object that resolves to a real paper, and free-text references do not exist in the system.

Save papers to your library by PDF upload or DOI, then use Ask and extract to pull architectures, datasets, and reported settings with sentence-level provenance, so each extracted detail binds to the exact passage in the paper. Build your comparison table as an evidence matrix in the Synthesis Lab, papers against the dimensions of your taxonomy.

When you draft, the Fact Checker verifies each claim against the full-text PDFs you hold before the text reaches you. A claim without a verifiable source is flagged, which is precisely the guard a novelty argument needs.

The Reference Manager keeps the bibliography consistent as the review grows, with IEEE among the 12 citation styles it supports, and the Thesis Assembler can compile to LaTeX when your department expects it.

Mistakes examiners flag in computer science reviews

CS committees see the same failures repeatedly:

Every one of these is a grounding problem. Read the sources, extract from the papers themselves, keep the search current, and let the taxonomy carry the argument. That is the related-work chapter that makes a committee trust the contribution behind it.

• Related work listed paper by paper, with no taxonomy and no comparison dimension
• The arXiv version cited when a peer-reviewed version exists
• Benchmark numbers quoted from another paper's summary rather than the source
• An obvious line of related work missing entirely
• Novelty claims that a single citation would contradict
• A last-search date so old the review misses the current state of the art