Academic Writing Cheatsheet for Computer Science, Machine Learning, and Robotics Papers

This cheatsheet is intended for students writing papers for top-tier computer science, machine learning, computer vision, and robotics conferences.

Scoring

[5/5] = highly important and common pitfall
[4/5] = important and frequent
[3/5] = useful and moderately common
[2/5] = good to have but less central
[1/5] = minor refinement

1. Claims and Contributions

1-1. [5/5] State one central claim and make it unmistakable.
A strong paper should be summarizable in one sentence. If the reader cannot identify the paper’s main claim, the paper likely lacks focus.
1-2. [5/5] Bound every claim by the evidence.
Do not claim generality from one dataset, one simulator, one robot platform, or one task family. Prefer “on nuScenes” or “in our closed-loop simulator” over broad claims such as “for autonomous driving.”
1-3. [5/5] Make contributions explicit and refutable.
Each contribution should be a claim that later sections can substantiate with proof, analysis, experiments, or a released artifact.
1-4. [4/5] Separate contribution from implementation detail.
Not every engineering choice is a contribution. A contribution should change what the reader understands, can do, or evaluate.
1-5. [4/5] Describe novelty precisely, without puffery.
Say whether the novelty lies in the problem, method, benchmark, dataset, analysis, or empirical finding. Avoid unsupported “first,” “novel,” or “state-of-the-art” claims.

2. Abstract, Introduction, and Narrative

2-1. [5/5] The abstract should state the problem, gap, idea, key result, and conclusion.
Do not merely say that experiments were conducted. State the main empirical or theoretical outcome when space permits.
2-2. [5/5] The introduction should explain why the problem matters and why existing approaches are insufficient.
Then state the core idea and contributions clearly. The introduction should not be a compressed method section.
2-3. [5/5] Give away the punchline early.
The reader should understand the paper’s main claim and value before reaching the experiments. Important results should not be buried late in the paper.
2-4. [5/5] Tell a direct story, not the chronology of the project.
A paper should present the clearest route to the idea and evidence, not the order in which the authors discovered them.
2-5. [4/5] Use a concrete example before abstraction when it improves intuition.
A short example can make a problem, failure mode, or method easier to understand before formal notation or the general case.

3. Evidence and Experimental Reporting

3-1. [5/5] Match the strength of the claim to the strength of the evidence.
Strong claims require strong evidence. If experiments are limited, the claim should be correspondingly limited.
3-2. [5/5] State the evaluation protocol and critical implementation details clearly.
Include dataset splits, metrics, baselines, number of seeds or runs, filtering criteria, and nonstandard evaluation choices. Details that materially affect the results should appear in the main text; secondary or repetitive details can go to the appendix.
3-3. [5/5] Tie each experiment to a claim.
Every main experiment should answer a specific question: effectiveness, robustness, generalization, efficiency, component contribution, or failure behavior.
3-4. [5/5] Report uncertainty when relevant and avoid cherry-picking.
For stochastic training, small datasets, unstable metrics, or high-variance evaluation, report standard deviation, confidence intervals, multiple seeds, or a clear statement of variability. If one metric improves and another degrades, report both.
3-5. [4/5] Report only warranted numerical precision.
Do not report more decimal places than the measurement supports. Distinguish clearly between absolute differences, percentage points, and relative improvements.
3-6. [4/5] Explain practical significance, not only numerical significance.
A better number is not automatically a meaningful advance. Explain whether the improvement changes the scientific conclusion, deployment relevance, or practical behavior.

4. Method, Terminology, and Mathematical Notation

4-1. [5/5] Start from the problem formulation.
Define inputs, outputs, objective, assumptions, and constraints before describing the algorithm.
4-2. [5/5] Define important terms, symbols, assumptions, and variables on first use.
Readers should not guess what a term or symbol means. Terms such as “realism,” “safety,” “interaction,” “robustness,” “causality,” and “interpretability” should be tied to measurable criteria, model behavior, or formal assumptions.
4-3. [5/5] Use consistent terminology and descriptive names.
Do not switch between (p_\theta), (\pi_\theta), (f_\theta), “model,” and “policy” unless each has a distinct meaning. Avoid labels such as “Approach 1,” “Module A,” or acronyms that do not reduce cognitive load.
4-4. [5/5] Clarify what is learned, optimized, predicted, retrieved, or controlled.
Many method sections become unclear because the target object is ambiguous. State whether the method learns a policy, estimates a reward, predicts trajectories, retrieves context, optimizes a latent variable, or controls an agent.
4-5. [5/5] Separate assumptions from design choices.
Assumptions describe what the method requires to be valid. Design choices describe how the method is constructed. Mixing them obscures applicability.
4-6. [5/5] Explain why each major component exists.
Avoid listing modules without motivation. Each component should address a specific limitation, requirement, or claim.
4-7. [5/5] Explain equations in words and integrate them grammatically into the text.
An equation is part of the sentence. After presenting an equation, state what it computes, optimizes, constrains, or estimates.
4-8. [5/5] Make indices, sets, dimensions, and mathematical scope explicit.
Check that every expectation has a distribution, every summation has an index and range, every probability has a clear event, and every loss has clear arguments.
4-9. [5/5] Ensure the math matches the implemented algorithm.
If the implementation uses approximations, sampling, clipping, normalization, stop-gradient operations, or heuristic filtering, mention the important ones.
4-10. [4/5] Do not use equations as decoration.
Include an equation only if it improves precision, supports a derivation, defines an objective, or clarifies the method.
4-11. [4/5] Keep notation visually readable.
Avoid deeply nested subscripts and superscripts when possible. If notation becomes too dense, introduce intermediate variables or use an algorithm box.

5. Related Work and Positioning

5-1. [5/5] Organize related work by technical themes and explain relationships.
Do not write a paper-by-paper list without comparison. Related work should position the contribution.
5-2. [5/5] State how your work differs from each relevant cluster of prior work.
Explain how your paper differs from, builds on, or complements each group. Positioning is part of the contribution, not an afterthought.
5-3. [4/5] As a default, place detailed related work after readers understand your problem and idea.
If the paper is a small variation on prior work, adapt accordingly. Excessive early related work can obscure the main idea.
5-4. [4/5] Be fair and precise when describing prior work.
Prior work usually has different assumptions, objectives, or constraints. Do not make other papers look weak merely to make your paper appear stronger.
5-5. [4/5] Cite primary sources when possible.
Cite the original method, dataset, benchmark, or theoretical result rather than only later papers that use it.

6. Figures and Tables

6-1. [5/5] Every figure or table should support a specific claim.
If it does not help the reader understand the problem, method, or evidence, reconsider including it.
6-2. [4/5] Captions should communicate the takeaway, not only describe the content.
Weak: “Results on Waymo.”
Stronger: “Our method reduces collision rate while preserving route progress on Waymo.”
6-3. [4/5] Make captions informative enough to support skimming.
Reviewers often skim figures and captions before reading the full text. Captions should provide enough context to make the figure interpretable.
6-4. [4/5] Use the main text to interpret figures, not to repeat all visible numbers.
The prose should explain the conclusion supported by the figure or table, not restate every value.
6-5. [4/5] Make tables easy to compare.
Align baselines, group related methods, report units, indicate whether higher or lower is better, and bold best results carefully.
6-6. [4/5] Use consistent terminology between text and visuals.
Figure labels, table entries, method names, metric names, and abbreviations should match the main text.

7. Paragraphs and Sentences

7-1. [5/5] Start paragraphs with a topic sentence and keep one conceptual unit per paragraph.
A paragraph should usually develop one idea: motivation, limitation, method component, result, or implication. Avoid a bag of sentences.
7-2. [5/5] Place old or linking information early and new or emphasized information late.
This old-to-new structure improves flow and helps readers track the argument.
7-3. [5/5] Keep the grammatical subject close to its verb.
Long interruptions between subject and verb often make technical sentences harder than necessary.
7-4. [5/5] Put important actions in verbs.
Avoid hiding the real action inside abstract nouns. Prefer “the model predicts trajectories” over “trajectory prediction is performed by the model.”
7-5. [5/5] Avoid ambiguous references.
Words such as “this,” “that,” “it,” and “they” should clearly refer to a specific object. Replace “This improves performance” with “The interaction module improves performance.”
7-6. [5/5] Do not overstate causality.
Use causal language only when the evidence supports it. “The auxiliary loss improves generalization” is stronger than “The auxiliary loss is associated with improved generalization” and requires stronger evidence.
7-7. [4/5] Prefer active voice when it improves clarity, but use passive voice when it preserves topic continuity.
Active voice often clarifies agency. Passive voice is acceptable when the actor is irrelevant or when the paragraph is about the object being acted upon.
7-8. [4/5] Avoid overly long sentences.
Long sentences often hide the main point. A useful rule is that one sentence should usually express one main idea.
7-9. [4/5] Use precise, direct language and remove empty boosters.
Words such as “clearly,” “obviously,” “very,” “significant,” “novel,” and “substantial” should be justified or deleted.
7-10. [3/5] Use mostly present tense for the paper’s claims and results.
Use present tense for established facts, paper contributions, and descriptions of figures/tables: “Table 2 shows...” Use past tense for specific completed actions: “Smith et al. evaluated...”

8. Limitations and Failure Cases

8-1. [4/5] State limitations honestly but precisely.
A limitation should define the boundary of the current evidence rather than sound like an unqualified weakness.
8-2. [4/5] Distinguish methodological limitations from experimental limitations.
Limited datasets, limited compute, simplified assumptions, metric mismatch, and missing real-world validation are different issues.
8-3. [4/5] Discuss failure cases when they reveal useful information.
Failure cases can clarify when the method works, when it fails, and what assumptions are violated.
8-4. [4/5] Avoid generic limitations.
“More experiments are needed” is weak. Specify which experiments are needed and why.
8-5. [3/5] Connect limitations to future work carefully.
Future work should follow logically from the limitations rather than introduce unrelated directions.

9. Revision and Review

9-1. [5/5] Check that every major claim has explicit evidence.
Unsupported claims should be softened, supported, or removed.
9-2. [5/5] Ask whether each section, paragraph, and sentence advances the main claim.
If a unit does not support the paper’s argument, cut it, move it, or rewrite it.
9-3. [5/5] Check consistency of terminology, notation, method names, and metrics.
Inconsistent terminology is one of the fastest ways to lose reviewer confidence.
9-4. [5/5] Get outside readers early.
Misunderstandings are evidence about the paper, not merely about the reader. Ask readers to identify the main claim, contribution, and weakest evidence.
9-5. [4/5] Read the paper from the reviewer’s perspective.
Ask: What is confusing? What claim would I challenge? What baseline would I expect? What evidence is missing?
9-6. [4/5] Remove text that sounds impressive but does not add information.
Clarity is more valuable than rhetorical intensity.
9-7. [4/5] Document and, when possible, automate the path from experiments to tables, figures, and final PDF.
This reduces stale plots, inconsistent numbers, bibliography errors, and last-minute revision mistakes.

ehsan-ami/academic_writing_cheatsheet.md

Select an option

No results found