Improving readability of proofs

✱ Try to add some redundancy as a kind of error-correcting code, especially in definitions:

No matter how careful you are, there will always be parts of the proof that will be ambiguous or risk being misunderstood (or simply where we might wonder “is this really what was meant here?”). Try to give the reader ways to check that their understanding is correct. This is particularly important in definitions, because a misunderstood definition often makes all that follows unrecuperable.

One possible approach that I try to use is to repeat definitions twice by putting them once in symbols and once in word. E.g., “let $P := \{x\in\mathbb{R} : x>0\}$ be the set of positive real numbers” (this one might help the reader who is unsure whether “positive” means “$>0$” or “$\geq 0$”; of course, adding “open” before “set” might provide an additional check), or “let $N := \mathbb{R}\setminus P$ be the complement of $P$” (this might help the reader who is unsure what the symbol “$\setminus$” means). But of course there are all sorts of additional hints that you can add to let the reader check that they are still on the same page.

✱ Make sure the structure of the argument is apparent even if one skips over the details:

By this I mean that proofs often contain many arguments nested within arguments nested within assumptions nested within case distinctions, and so on. Some readers won't read the details of the sub-sub-subcase arguments but still want to follow the overall theme of the proof. So it's important that the overall structure of the proof is very easily apparent, that one can tell where each sub-part lies with respect to the others. So don't hesitate to label cases and subcases, to remind the reader things like “still working under the assumption that $x>0$”, to be extra clear on where each hypothesis starts and ends (don't just write “if $x>0$” if it will be clearer to write “we temporarily assume $x>0$ (…) this concludes our assumption that $x>0$”).

✱ Try to explain the point of every assumption from the start especially when working toward a contradiction:

I find it very confusing, when I read something like “assume $X$ is slithy and mimsy” which contradicts my intuition, not to know whether we are trying to reach a contradiction (so indeed $X$ cannot be slithy and mimsy and my intuition was correct) or whether this is an important possibility. So at the very least, when doing a proof by contradiction, write something like “assume toward a contradiction that (…)”. But it can also help the reader to add hints in non-contradiction cases like “we first handle the untypical case where (…)”.

✱ If you have some standing assumptions, try to repeat them occasionally:

There are sometimes good reasons to write “all foobars in this paper are assumed to be cromulent” in the introduction. But if you do so, keep in mind that some readers will have skipped the introduction, so try to remind them occasionally, when this plays a major role, “we are working under the convention that ‘foobar’ means ‘cromulent foobar’ (see introduction, §1.42)” or some such thign.

Here is one version of the checklist I mentioned in the question.

Naming of Variables

• Get rid of unneccessary renamings. If a group is called 'G' in one chapter and 'H' in the next, rewrite the entire next chapter to also call it 'G' there.
• Use similar names for similar things. If we have two vector spaces and a subspace of each of them, call them $W\subset V$ and $W'\subset V'$. If we once used $i$ as an index somewhere, we should not use $i$ as elements of a set $I$ somewhere else (unless $I$ denotes the set of all indices, where... )
• It is best not to name things if you can get away with it. Instead of 'Let $V$ be a vector space. Then for every vector $v\in V$' write 'For every vector $v$'. This only works if $V$ is not used later. Sometimes this requires reordering some sentences and it usually results in using 'it' instead of the variable name. In such a situation, it must be clear, what it refers to.

Organization of Proofs

• Don't repeat yourself. If you have several similar proofs, can you move parts of it into a separate lemma and refer to it.
• Is it clear to the reader, why we are doing this right now. A sentence like 'The goal of this section is... ' might help. If it is very technical, just admit that sadly we have to establish some technical results needed in the proof of...
• At the end of the proof it should be clear that the proof is done. Sometimes if you reduce a statement to more and more technical statements, at the end one has to do a mental backtracking to notice that the final step actually completes the proof. This should be written down explicitly.
• Check if you can replace proofs by contradiction with direct proofs. Often they get more readable.
• Try to reorder all arguments in a proof such that the order makes more sense. Usually a statement should follow from what is written directly before it and what is written much earlier. Try not to jump around too much.

Sentences

• Sentences should be complete. Especially if they contain formulas. It is easy to forget that I still have to finish a sentence after writing down a displayed formula.
• Make sure that all implicit quantifiers in each statement are understandable.
• Check it you can use language instead of $\forall/\exists$ quantifiers in formulas. This makes it easier to follow.

Definitions and assumptions

• Think about when and where to repeat assumptions. If all lemmas/propositions/theorems of one section have the same assumptions, write them down only once at the beginning to not repeat yourself. This makes refering to such statements much harder, since they have assumptions that are written down somewhere else. The main theorems should always state all their assumptions explicitly.
• Stay consistent with definitions. If you write down a sentence 'All vector spaces in this section are assumed to be finite-dimensional' , then never write down 'Let $V$ be a finite-dimensional vector space', otherwise always write it down if needed. You can still stress that a certain statement also holds for infinite-dimensional vector spaces.
• Check whether you can get away with removing an assumption. For example, if you somewhere in the proof turned a left-action into a right action using the isomorphism $G\cong G^{op}$ which exists for groups), check whether you really have to do this or whether you could state the statement in terms of right actions instead. Maybe the result then also works for monoids.
• Never mix up different writings of the same thing. I still don't know whether to write 'finite dimensional' or 'finite-dimensional' or 'finitedimensional'. But its best not to mix it up. Analogously $\subseteq$ vs $\subset$ vs $\subsetneq$

Formatting / LaTeX

• If a proof ends with a formula, use \qedhere.
• Always use cleverref, it makes changing lemmas to propositions much easier.
• Use '~' a non-breaking space instead of ' ' in all citations. Instead of '\cite[Theorem 2.1]{paper}' write '\cite[Theorem~2.1]{paper}' so that Latex knows not to do the line-break after theorem.
• Don't be to lazy to declare math operators $\mathop{\rm GL}_n(\mathbb{C})$ vs $GL_n(\mathbb{C})$.
• use the same environments for displayed formulas. I am a fan of \begin{align*} even if it is just one line.

My two basic principles:

• if the reader needs to write or draw something in order to understand/check the proof, then provide it,

• give an outline of the proof for the ones who do not want to check it but are interested in the overall idea.

A lot of readability problems can be spotted by rereading one's proofs from a detached perspective. Ask yourself "would this sentence be clear if I didn't already know what I meant? could it be misunderstood? are these notations actually standard?". These questions are easiest to answer after a "cooldown period" of weeks or months from writing the relevant parts of the paper. But even before that, you can e.g. google the terminology and notation you are using and check whether it really is common and means what you think it means (prepare for nasty surprises; I am still not over the fact that the product $\alpha \beta$ of two permutations can mean "$\alpha$ after $\beta$" or "$\beta$ after $\alpha$" depending on whom you ask).

Fixing these problems is a different story, though. Undefined notation is easy, at least -- just define it or (in complex situations) cite a source you know defines it correctly. To fight ambiguous wording and ineffable sub-arguments is the hard part, since English is not a very precise language in the first place (the typical "it" can refer to two or three different things in a sentence), and many proofs use data structures that have never been formally specified (e.g., what type of object is the cycle decomposition of a permutation?); in some parts of combinatorics, well-written proofs are the exception, not the rule. Things that help include

(1) breaking up proofs into lemmas, as self-contained as possible (great when it works),

(2) giving examples (good for understanding definitions and for explaining why certain arguments don't work; not so useful for understanding why arguments do work, since a reader will as likely be distracted), and

(3) having a collection of metaphors handy that build on existing intuitions (e.g., "tagging" the entries of a tuple with distinct tags so that you can refer to them unambiguously by their tags even if some of the original entries were equal).

The latter is best learned from well-written texts (Fulton's Young tableaux has taught me some, and I've seen people read Serre for that purpose). In principle, Hoare logic (loop invariants) is the gold standard for reasoning about algorithms, but I have seen it used correctly so infrequently in mathematical proofs that I rather prefer to not use nontrivial algorithms at all (but instead use "one-liners" or recurrent definitions with a clear recursive structure).

Sometimes I decide that there is no one ideal formulation, and end up writing two variants, one for the experienced reader and one for the beginner. See the proof of Lemma 2.5.6 in arXiv:2507.22386v1 for an example. Note that this is a toy case as far as combinatorics is concerned; many proofs are far more complicated.

In my experience, avoiding proof by contradiction is not generally a readability improvement; sometimes, it makes proofs cleaner, sometimes it makes them less focussed. But it has several other advantages, such as making the intermediate results of the proof potentially reusable, and making the proof constructive (although the non-constructivity of a proof by contradiction is often skin-deep).

Henrik Rüping has already said a lot about good practices in formatting and writing. Let me add a couple of my own:

• Always cite sources with precise pointers. Not "by 1 we know" but "by [1, Theorem 2.7.6] we know". The only exception is if you are citing a paper for a vague relatedness rather than for a specific claim or definition.

• Relatedly: Always cite arXiv preprints with version numbers. The numbering can easily shift from version to version; lemmas may just disappear; notation can change entirely.

• Separate introduction and definitions. The former is to give a birds'-eye view of what your work is and of the context it is relevant to; the latter is an integral part of the paper, where the no(ta)tions to be used are defined. Many readers will only skim the introduction (to be frank, you're probably writing it to impress referees, so it will be neither very readable nor precise), but they need to be able to fully understand the definitions. It serves no purpose in having the two mixed together.

• Use slanted or framed instead of italics for theorem statements. Yes, it is a good thing to separate them visually from the surrounding text, but you want to separate text from maths as well, and italics can make this very hard. "An R-matrix is an $f \in \operatorname{End}\left(V\otimes V\right)$" or "An R-matrix is an $f \in \operatorname{End}\left(V\otimes V\right)$" is much more readable than "$\mathit{An\ R\text{-}matrix\ is\ an}\ f \in \operatorname{End}\left(V\otimes V\right)$" (I've been using mathmode to approximate italics here on MO, but other than the spacing, this is how italicized text would look like).

• Check that your footnote anchors are distinguishable from exponents. I have seen "Let $x \in \mathbb{R}^3$" mean "Let $x \in \mathbb{R}$ [footnote 3]" far more often than I would expect it by chance. Usually, a better place to place the marker is not far away (e.g., on the "Let"); if not, then add some awkward-looking spaces before. Awkward beats confusing every time. If you do want words in a formula, don't abbreviate them, and use \text{...}.

• Generalizing the previous two points, ensure that math and text are easily distinguishable. Thus, for example, avoid the use of "s.t." or "i.e." inside formulas; avoid "Theorem 2.3. $4=5$"; avoid "$S = \left\{s_1, s_2\right\},\ s_1, s_2 \in \mathbb{Z}$" (just put "where" or "with" in between).

• Avoid overworked obsolete notations such as $[x]$ for the floor of $x$ (use $\left\lfloor x\right\rfloor$, which is easy to turn into something like \floor{x} by a single newcommand) or $(a, b)$ for the gcd of $a$ and $b$ (just say $\gcd(a,b)$).

• Don't hesitate to check for common mistakes. Run a script searching for unmatched parentheses. Search for "the the ". Check that $k$ is not used for both the base field and a summation index. Check that ambiguities such as "$a\leq b,c\leq d$" are absent. Run a spell checker, but don't just fix the typos it founds; look around them for other bugs. (A typo usually signals a section that hasn't been looked at enough.)

• I feel that one should not hesitate to add short comments which don't technically participate in the proof but help understanding it (although they should be moved before or after the proof if they take more than a few sentences). For example, it can be helpful to announce the proof technique before starting, e.g., "We are going to construct a non-determined game $A$ by diagonalizing over all strategies to ensure none is winning." This especially applies if there is something that might surprise your reader, e.g., "We cannot use Dijkstra's algorithm directly because the weight $w(e)$ might be negative when $e \in D \cap F^c$." Address natural questions, e.g., "We now iterate the construction to obtain $a_2$ (we could in fact prove that $a_1$ already works, but this argument is simpler)."

• When objects have an intuition which involves some irrelevant encodings to formalize (such as graphs, automata, games), it is often easier to understand a description in words. For example, "the graph $H$ obtained by removing the vertex $v$ from $G$" instead of "the graph $H := (V_G \setminus \{v\}, \{e \in E_G \ | \ v \not\in e\})$, and "the play where Eve plays according to the strategy $\sigma$ and Adam plays the successive terms of $u$ regardless of Eve's moves" instead of "the sequence $p$ defined by $p(2n) = \sigma(\langle p(0), \dots, p(2n-1)\rangle)$ and $p(2n+1) = u(n)$". Relatedly, avoid relying on foundational details when possible. For example, when $\beta$ is an ordinal, write "for all $\alpha < \beta$" rather than "for all $\alpha \in \beta$" since von Neumann's definition is not the only sensible construction of ordinals.

• Use unambiguous notation as much as possible. For example, $\subset$ can mean "subset" or "proper subset" depending on who you ask, so I'd always use $\subseteq$ or $\subsetneq$.

• Combine business with pleasure by watching Jean-Pierre Serre's talk How to write mathematics badly.

1. (Not so much about proofs but about writing in general) There is a hierarchy of components of the paper: title, abstract, introduction, body of the paper. Not many people will read the body of the paper, only those curious of the results. Thus, the introduction should be sufficiently informative: the interested reader should realize they are interested, the mildly curious reader should be able to learn the main results from the introduction. To achieve that goal, the abstract should contain the necessary keywords making it clear in what general direction the paper goes, for the two categories of readers mentioned above to want to read the introduction, and for the not so enthusiastic readers to get a general gist of where the paper is going, and for unenthused readers to stop reading there and not get annoyed at you that you made them read something irrelevant for them. And, of course, in the modern world where all starts from a list of new preprints in updates from the arXiv, the title helps one decide whether or not they want to read the abstract...

2. The number of papers these days is quite enormous, do not make your paper too hard to read. If you replace "In [1], the notion A is studied" by "In [1], Brown and Smith study the notion A", it would help many readers to not jump back and forth between the body of the paper and the list of references. As mentioned above, if you reference a concrete statement or definition or result, refer precisely (section, numbered theorem, page...). Collect notations (especially even mildly unusual ones) and conventions in one place for the convenience of the reader.

3. Try to accommodate the reader who wants to ask questions about the paper: it is easier to ask "what the formula (5) means" than "what the third formula in the middle of the proof on page 35 means". Do not number the same thing twice: in the introduction, when stating main theorems, do not use the theorem environment, but rather create a separate unnumbered theorem environment for the introduction, and indicate in the parentheses the actual number that the theorem has in the body of the paper.

4. Try to make the notation at least mildly suggestive: we all saw papers in which $A$ denotes a vector space and on the same page $V$ denotes an associative algebra. Try to use different fonts for objects of different types (vectors, modules, categories...).

5. Once a proof is written, re-read it in a week or two, ideally after working on something completely different. It helps to see it from the point of view different from yours: remember that you spent a long time thinking about it, and you cannot expect a similar investment from the reader.

6. Even better, try to read the proof out loud. Sometimes, looking at the page you wrote you see what "should be there", not what is there. Reading out loud sometimes helps notice something you do not see otherwise.

7. Not all proofs in maths are elegant, but if the proof feels too heavy, spend some time trying to see if you missed some ways to work around the very technical parts. If some part remains way too technical, you may consider moving it to the appendix for better readability, leaving just the statement to streamline the proof a bit. If some part is likely to be useful in the future regardless of the present purpose, make it a separate Lemma/Proposition.

• When you cite a lemma/theorem from a different paper, repeat it in your notation and using your definitions of the terms.
• For long proofs: After the proof, explain the proof again alongside a common example, preferably with images or diagrams. This creates a mental picture of the argument in the reader's head.

There are some things I have always tried to keep in mind, which are still missing from the answers so far:

Names have power, so use them

Quite often important theorems/lemmata/definitions/equations, etc. have a clear name, either historical (e.g. named after someone) or given by their function (e.g. something like "monotonicity formula", "reduction lemma", "reflexivity property", etc.). Using that name consistently whenever they appear can make everything much more readable.

In a proof their value comes from strengthening mental references. Imagine a sentence like

"Combining (7) with Lemma 3.13 we conclude that $X$ satisfies Definition 2.5."

where the respective numbers occur somewhere 20+ pages earlier. This completely breaks any sort of reading flow, as the only way to parse this is by going back all those pages to find the respective statements and figuring out how they relate to each other. If they occur on different pages this might require quite a bit of flipping backwards and forwards.

Some people suggest repeating important information, but depending on the size of the statements, this can quickly become unfeasible, in particular if several of them are involved. Now contrast this with

"Combining the monotonicity formula (7) with the reduction Lemma 3.13 we conclude that $X$ satisfies the reflexivity property (Definition 2.5)."

Five more words and you immediately have a feeling about what is going on. Even if you don't remember the precise statements, you have a rough feeling about what each part is supposed to do. This might either be enough to believe that step of the proof, or if you decide to use the numbers to look up the references, for each of them it tells you what aspect to look for, as it relates to the others.

A picture can say more than a thousand words

Many times I have seen statements like "Consider the domain $\Omega = \{\dots$" followed by half a dozen of inequalities between $x,y$ and $z$, or "consider the cutoff-function $\phi$" followed by a 5+ line case statement. In this case the only way for me to understand what is going on, is to take a long detour and draw a diagram/plot myself. While doing this, I will likely make several mistakes or focus on getting unimportant parts of the definition right, while ignoring crucial details.

All this could be easily avoided by the author providing the correct picture for me, making the actual proof and the authors intentions much more readable. While this is of course more obvious in geometrical topics, it can work for surprisingly theoretical results. It also helps in remembering what's going on and in conjunction with the first point, can even help in naming and providing references. The snake lemma for exact sequences is a famous example for that, where the picture explains a purely abstract result much better than any long text would and at the same time gives it its memorable name.

Sadly figures are often an afterthought at best. Somehow people are able to spend hours honing notation and wording, but then if they produce a picture at all, it looks like a five minute job in some vector-equivalent of MS paint, with badly positioned labels in inconsistent fonts and small gaps between lines that should end in the same point. (Which also is a good reminder to generate the image in a way that allows for easy editing.)

Leslie Lamport has some interesting suggestions for writing clear proofs in his articles "How to Write a Proof" (1993) and "How to Write a 21^st Century Proof" (2012). He advocates for writing structured/hierarchical proofs in place of prose. He also suggests that proof sketches should appear between the statement to be proved and the proof itself (at any level of the hierarchical proof, not only at the beginning of the proof). His system seems to be based on natural deduction.

Lamport's suggestions might be radical even today, but this could change as proof assistants become more widely used by mathematicians. The package pf2.sty can be used to format hierarchical proofs in LaTeX.

I have used Lamport's method to write down some combinatorial proofs where I had to keep track of several cases and subcases (running several layers deep). However, the structured proofs did not go into the final version of the manuscript. I also found his method to be very useful when reading Lang's Algebra during my PhD: it could be just me, but the proofs in that textbook were not easy for me to follow, in the sense that I couldn't understand how one sentence follows from previous ones. Putting the proofs in a structured format clarified many things for me.