How to Structure a Thesis Project in LaTeX
Plan a maintainable root file, front matter, chapter folders, figures, bibliography, appendices, and review workflow for a long LaTeX thesis.
Summary: Keep one short root document, separate chapters and appendices into named files, store figures predictably, use one bibliography source, and compile the complete root regularly. Institutional rules always take priority over a general starter.
Begin with the submission rules
Before choosing a class or folder layout, obtain the current thesis instructions from your university or faculty. Check the approved document class or template, title page, declarations, margins, line spacing, page numbering, required front matter, reference style, archive format, and accessibility rules.
A general book or report structure can help you plan, but it is not evidence of institutional approval. If an official class file is supplied, keep it with the project and read its documentation before changing its commands.
Use a predictable folder tree
A small project does not need many layers. Give every directory one purpose and use lowercase, stable file names without spaces when practical.
thesis/
├── main.tex
├── references.bib
├── frontmatter/
│ ├── abstract.tex
│ └── acknowledgements.tex
├── chapters/
│ ├── introduction.tex
│ ├── literature-review.tex
│ ├── methods.tex
│ ├── results.tex
│ └── discussion.tex
├── appendices/
│ └── supplementary-methods.tex
└── figures/
├── system-overview.pdf
└── results-plot.png
Do not create a separate directory for every figure if that makes paths harder to understand. A flat figures/ folder with descriptive names is often enough.
Keep the root document short
The root should define document-wide settings and assemble the major parts. Chapter files should contain chapter content, not another document class or document environment.
\documentclass[12pt]{book}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{hyperref}
\begin{document}
\frontmatter
\maketitle
\input{frontmatter/abstract}
\input{frontmatter/acknowledgements}
\tableofcontents
\mainmatter
\include{chapters/introduction}
\include{chapters/literature-review}
\include{chapters/methods}
\include{chapters/results}
\include{chapters/discussion}
\appendix
\include{appendices/supplementary-methods}
\bibliographystyle{plain}
\bibliography{references}
\end{document}
The book class provides \frontmatter, \mainmatter, and \backmatter. An official thesis class may provide different commands, so follow its manual instead of copying this example unchanged.
Choose between input and include deliberately
\input{file} inserts a file at that point and is useful for short sections or front matter. \include{file} is designed for larger units such as chapters and starts them on a new page. It also works with \includeonly in suitable projects when you want a shorter local drafting build.
Do not split every subsection into another file. Separate units that have a clear owner or purpose, can be reviewed independently, or make navigation materially easier.
Manage figures and tables with stable labels
\begin{figure}[htbp]
\centering
\includegraphics[width=.82\linewidth]{figures/system-overview.pdf}
\caption{Overview of the proposed system.}
\label{fig:system-overview}
\end{figure}
As shown in Figure~\ref{fig:system-overview}, ...
Use a consistent label prefix such as fig:, tab:, eq:, or sec:. Place a figure or table label after its caption so the reference receives the intended number. Keep original high-quality figure files outside the project as a separate backup when necessary.
Use one controlled bibliography source
A single references.bib is easy to search and back up. Use stable citation keys that describe the author and year rather than temporary numbers.
@article{lovelace1843notes,
author = {Lovelace, Ada},
title = {Notes by the Translator},
journal = {Scientific Memoirs},
year = {1843}
}
Choose classic BibTeX or another bibliography workflow according to the official template and supported build environment; do not mix commands from different systems casually. Compile enough times for citations and cross-references to settle, and read bibliography errors in the log. The LaTeX2e reference manual documents core splitting, front/back matter, references, and BibTeX commands.
Compile the complete thesis regularly
A chapter can look correct alone while the assembled thesis has broken numbering, duplicate labels, missing references, inconsistent spacing, or a bibliography problem. Keep main.tex selected as the root and run a complete build at meaningful milestones.
| When | What to inspect |
|---|---|
| After changing the preamble | Every chapter, font, heading, and package warning |
| After adding a chapter | Contents, numbering, labels, and references |
| After bibliography edits | Citations, missing entries, style, and ordering |
| Before supervisor review | PDF page flow plus unresolved source comments |
| Before submission | Institutional checklist, final log, PDF, and source archive |
Plan review without overwriting work
Give collaborators only the role they need. A viewer can read and comment; an editor can change source. Keep comments focused on exact text, resolve them deliberately, and use saved revisions before a structural rewrite. Collaboration at save boundaries still needs communication when two people edit the same file.
Common structure mistakes
- Putting
\documentclassand another document environment in every chapter. - Using inconsistent file-name case that works on one computer and fails on another.
- Copying the same bibliography entry into several files.
- Changing an official class to solve a visual preference without checking the rules.
- Compiling only the active chapter until the day of submission.
- Using manual section numbers instead of LaTeX's sectioning and reference system.
A maintainable finish
Before submission, compile from the root, read the log, inspect every page, test links, confirm the bibliography, and export a clean source ZIP. If a multi-file project is moving from another editor, follow the LaTeX ZIP import checklist. If the assembled thesis produces layout warnings, work through the guide to overfull and underfull hboxes rather than suppressing them globally.