This document summarizes general writing guidelines at the Institute of Software Engineering and Programming Languages at Ulm University. If you have suggestions for improvements, or think something is outdated, please open a new issue.
[General] • [Proposal] [Thesis] [Presentation]
All of these guidelines are subject to discussion with your supervisor to be adapted to your specific scenario.
Current list of templates provided by the institute can be found on the SP GitHub page or the general template page
These guidelines apply to all types of scientific writing at our institute, like lecture papers, theses (bachelor and master), and the accompanying presentations.
- Stay consistent!
No matter whether you use British or American English, or whether you prefer the Oxford comma or not: Just stay consistent throughout your work. And, of course, make sure that you not suddenly break context and introduce new things/concepts, etc. — we can do better than the average LLM. - Abide by the template-specific formatting guidelines (check out the SP GitHub page or the general template page for available templates).
- Follow the current guidelines on AI usage in scientific writing as provided by your supervisor or institute (Ulm University AI Guidelines).
- Use a spell or grammar checker (e.g., Grammarly, LanguageTool, or the built-in checkers of your text editor). A couple of typos are acceptable, but too many distract from the content and look unprofessional.
- Do not use
\\for creating paragraphs, just use empty lines for creating a new paragraph. The template will take care of the correct visual layout. - Present your ideas in easy to follow, complete sentences.
Bullet-points are fine for summaries, just like this document, but they make your work harder to follow and look "cheap"/incomplete. If you have difficulties formulating complete sentences, check out resources like a Phrase Book. - Know your dashes!
In LaTeX, we use-(-) for hyphens,--(–) for en-dashes (like numeric rangespages 12--23), and---for em-dashes — like this.
- Do not "just" cite a paper from, e.g., arXiv without quality control like peer review.1
- Whenever possible, try to use the bibliography entries provided by dblp.org and ensure that a DOI is available for the respective entry (ask your supervisor whether a procured bibliography for important references is already available).
- When citing, make sure that references contain not just author, title, and year, but also the venue (e.g., the conference like ICSE, MSR, ASE, or a journal like TSE, TOSEM, or JSS).
- Prefer full publications over vision, tool-demo, or (especially) poster publications.
- We don't want to have citations at the start of a line.
In LaTeX, you can use~to prevent a line break between two words (a non-breaking space). For example, instead of writingcute \cite{Sihler2025,Sihler2026}, writecute~\cite{Sihler2025,Sihler2026}. - We try to avoid cites-as-subjects with numeric citation styles.
Instead of writing "As shown by [2]", we prefer "As shown by Sihler et al. [2]". In LaTeX you can use something like\citeauthor*{Sihler2025}~\cite{Sihler2025}. - This includes presentations. Here an on-slide citation should read, e.g. "Sihler et al. (ICSE, 2025): On the Cuteness of Penguins".
- Use a proper system to format citations (like BibLaTeX, templates should already include this).
I mean, this sounds obvious, but still, there are countless existing best practices for writing scientific texts but also for conducting evaluations, and more. The following is just an incomplete list and you should definitely ask your supervisor for further guidance.
- Empirical (Software) Evaluations:
SIGSOFT Empirical Standards, SIGPLAN Checklist - Picking the best/correct visualization for your data:
https://www.data-to-viz.com/
Please be aware, that these guidelines hold additionally of the General Guidelines.
- Include rough estimates of your work.
Of course you cannot know exactly how long something will take, but roughly calculating the time against the available time (e.g., roughly 45 days for a bachelor's thesis) helps to judge the feasibility of your planned work.2 - Ideally plan multiple iterations of your work to conduct intermediate evaluations and implement feedback from earlier iterations.
- Plan an additional buffer for writing your thesis before the submission date (at least 2 weeks buffer)
Please be aware, that these guidelines hold additionally of the General Guidelines.
- Include a proper abstract summarizing your work.
Style-wise we recommend you follow a structured abstract approach. - We do not write click-bait articles.
Start with the most important information and the results. List the details afterward. Ideally, your work follows a "pyramid shape" in which you progressively go into more and more detail for the specific aspects of your work. - The "pyramid" metaphor also holds for the thesis at large. The abstract and the introduction should cover/summarize all parts of the thesis at a high abstraction level. Each individual chapter then goes into the details of that chapter's topic.
- Consequently, already answer your research questions/list your contributions in the introduction.
You can also hint at them in the abstract, but your introduction should communicate to the reader what your research questions are and how you answered them (i.e., what your contributions are). - For bigger segments like chapters and sections, include topic-sentences.
These summarize the content of the respective segment and help the reader to quickly grasp the content (e.g., when skimming through the document). - Know your limits, know your threats.
Threats to validity are an important part of scientific work. Make sure to discuss the limitations of your work and how they might threaten the validity of your results (e.g. Types of Validity, also consider Lago et al., ESEM '24).
- Include the signed declaration of authenticity
(The thesis template provides a module for this). The thesis submission is only valid if a signed declaration of authenticity is included in the submitted thesis. - Persist your final state in an easily accessible way.
We encourage you to (at least at Ulm University) upload the compiled version of your final and submitted thesis to this repository as well. Please use the format<Surname><Firstname>-<Type>.pdffor the file name, where<Type>is eitherBachelorThesisorMasterThesis(e.g.,SihlerFlorian-MasterThesis.pdf). - Alongside your thesis you usually have to submit a reproducibility package. Please check out the respective guidelines (Ulm University Rep-Package Guidelines).
- Read the University FAQ Page for up-to-date information on submission guidelines.
Please be aware, that these guidelines hold additionally of the General Guidelines.
- Provide citations on the slides.
These allow to quickly search for the reference during the presentation. The citation should (at least) contain the title, year, first-author and venue (e.g., "Sihler et al. (ICSE, 2025): On the Cuteness of Penguins").
Footnotes
-
If you are unsure about the quality of a reference, please discuss this with your supervisor. In general, if there exists a peer-reviewed version of a work, prefer citing that version. ↩
-
Consider a classical benchmark evaluation. If you do not at least estimate the maximum runtime you may be stumped by an evaluation that was deemed sufficient but requires multiple weeks or months of computation. Something like 10k files, with a timeout of 5 minutes each results in (without parallelization) over 34 days of computation time - just for a single run. And benchmarks should always be run multiple times to account for variance. ↩