Sander Leemans

During writing and reviewing, I compiled the following list of style "anti-patterns" and hints:

1. Woolly language: text that can be removed without changing the meaning of a sentence. For instance: while being either inside or outside, I like to eat ice cream. Better: I like to eat ice cream.
2. Woolly formalisms: avoid timestamps and identifiers wherever possible. It is not programming, it is formal writing. For instance: an event log is a set of events; each event has a unique timestamp and a trace identifier; a trace is a sequence of events, ordered by timestamp, with the same trace identifier. Better: an event log is a collection of traces, which are sequences of events.
3. Term switching/avoid synonyms: if two terms refer to the same thing, then the terms should be the same. It makes the text boring, true, but also much easier to understand. For instance: I was sitting on the couch when suddenly our cat joined me on the sofa. Better: I was sitting on the couch when suddenly our cat joined me on the couch.
4. Needless unargued claims: in a scientific text, every statement needs to be argued or proven. Thus, it is best to avoid qualifying phrases if they are not essential to the text. For instance: Petri nets were the first and are the best process modelling formalism. Better: Petri nets are a process modelling formalism.
5. Reverse-order reasoning: put the reason before the conclusion. For instance: BPMN models are easier to master than Petri nets, because they allow for more elaborate constructs. Better: As BPMN models allow for more elaborate constructs than Petri nets, they are easier to master.
6. Selling the pen rather than the problem: first, watch this video: how would you sell somebody a pen? Second, watch this video. In a paper that introduces a technique or algorithm, do not focus on the techique itself too early (first video); first establish the context and the problem (second video), such that your technique comes second as a natural solution.
7. Figure misplacement: \begin{figure}[hbtpH!]: if you do not want something to float, then do not make it a float. For best spacing, use [t] or [b], but only at the end of the writing process, just before submission.
8. Font inflation: use $a$ for variables, $A$ for sets and tuples, and $\mathcal{A}$ for sets of sets. Use $f$ for functions. If running out of letters, use Greek letters. Use \texttt{a} for constants. Do not introduce symbols for universes: if it is necessary to explicitly formally bound a variable (often, this can be done in text), do it from a specific set, not from a universe.
9. Do not fight with Latex's layout system; you'll not win. Avoid \vspace, \hspace, ~ and \!, as these mess up the layout. For the spacing within and between floats such as tables and figures, use the appropriate length adjustments to save space, such as textfloatsep. If a paragraph should be shortened, then rephrase it. In math formulae, do not manually adjust space, but help Latex with the proper semantical constructs, such as \DeclareMathOperator. If a formula does not fit on a line, then shorten it or break it apart; squeezing it on the line will not help readability.
   The only exceptions I apply are ~\cite{...}, which links the reference to the word before with an unbreakable space, and in an align environment around the ampersand: x ={} & y tells Latex that the = is an infix operator, and gets it to apply the correct spacing.
10. Overemphasis: indicate emphasis with \emph, as this allows the template to determine how emphasis is created. That is, do not use \textbf, \textit or \textsc. Emphasise the following:
    • In a definition environment, emphasise the concept(s) you are defining.
    • In an in-line definition, emphasise the concept(s) you are definining.
    • In the introduction, you may emphasise the key distinguishing factor.
    • If an abbreviation is too similar to a normal word, then \textsc the abbreviation.
    Do not emphasise anything else. If you feel the need the emphasise a certain phrase, then rewrite the parts around the phrase. In a well-written text, emphasis distracts and is counterproductive.
11. Overcapitalisation: capitals draw attention and should be used sparingly. Capitalise the following:
    • In top-level section headers, capitalise the first word and every word that is not a small word (on, in, the, etc.);
    • Names of particular algorithms, formalisms, people, etc.: 'Business Process Management and Notation', `Petri net', `Heuristics Miner';
    • Abbreviations: stochastic labelled Petri net (SLPN);
    • References: `Section 4.1' and `Figure 5'.
    Do not capitalise the following:
    • Small words, such as on, in, the, etc.;
    • Lower-level section headers: (only capitalise the first words and proper names);
    • Names of research fields or generic concepts: 'business process management', `directly follows graph', `Petri net';
    • After a colon (:), unless a completely new sentence starts;
    • Multiple references: `sections 4, 5 and 6'.
12. Every float (table/figure/algorithm) must have a caption and be referred to in the text. The caption should end in a period, and be descriptive but short and concise.
13. In tables, best avoid horizontal and vertical lines, except at the start of the table, between the header and the body, and at the end of the table. White space between rows and columns works much better to indicate grouping. Use the booktabs package's \toprule, \midrule and \bottomrule commands for nice spacing. Align every number column to the right, and give each number an equivalent appropriate number of significant digits. According to the SI, the thousand separator is a space, and a decimal separator is either a period or a comma. For instance: 10 000.3670. Every other column is aligned to the left.
14. Data, information, semantics and behaviour are only used in a singular form: `some data is obtained', `multiple types of behaviour'.
15. Avoid the -ing form if "that" or ", which" would work as well. For instance: that and which are small signal words conveying the reader the purpose of the next phrase. Better: that and which are small signal words, which convey the reader the purpose of the next phrase.
16. I prefer English (sometimes also called British English), but ensure the dialect of English is consistent. Commas serve to assist readers in understanding the sentence structure (unlike in German, where they are part of the grammar). Use them sparingly; avoid Oxford commas, unless they help avoid confusion.
17. Keep Latex source code organised:
    • Indent like you would program code. This helps to keep track of environments and sections.
    • Start every sentence on a new line. Collaborators and future you will be grateful, and diff tools will work better.