Skip to content

Practical Guide to Scientific Writing

Frédéric Quesnel

1. About

This guide offers clear rules on various aspects of writing a scientific article. It aims to prevent some common mistakes made by inexperienced writers (and once by the author of this document!). Of course, there is not only one right way to write, and a well-written article may not follow the recommendations in this document. This guide should therefore be seen as one of several good writing practices.

This guide has been designed primarily for writing applied operations research articles. It is therefore possible that certain recommendations may be inapplicable or irrelevant in another context.

If you have any comments or suggestions that would improve this guide, please submit them to quesnel.frederic@uqam.ca.

2. Organization of Explanations

2.1 Problematic, Formulation, and Solving Method

If you are presenting a mathematical model for a given problem, or a method for solving a given problem (e.g. an algorithm), please present separately:

  • The problem: Describe the context and the optimization problem. Use a minimal amount of mathematical symbols.
  • The mathematical model: Define the appropriate notation and write down the equations of the mathematical model.
  • The solving method: The procedure or algorithm used to solve the problem.

These elements may or may not be presented in different sections. However, they must always be presented sequentially. Note that in some cases, one or more of these elements may be omitted (for example, if a standard optimization software package is used as the solution method).

2.2 Presenting a Mathematical Model

Presenting in order:

  • The notations used for parameters and variables.
  • The equations of the mathematical model (objective function, constraints).
  • An explanation of the objective function and each constraint.

In addition,

  • The equations are numbered (referred to using the \eqref{...} command).

2.3 Describing a Graph or Network

Present, in order:

  • Nodes.
  • Arcs.
  • Other graph information (arc costs, bounds on arcs and nodes, resources, etc.).

In addition:

  • It can be useful to group arcs and nodes into categories (e.g. waiting arcs, arrival nodes, etc.).
  • Describe arcs and nodes in the singular form (e.g. "a node is created for each customer", not "nodes are created for customers"). The same applies to the description of other information.
  • Explain non-intuitive graph structures, particularly using examples.

2.4 Describing an Algorithm

Describing an algorithm is more complicated than it sounds. Before writing an algorithm, you should consider the following points:

  • Level of granularity: Some elements of the algorithm need to be described precisely, while others can be left more vague. Including too much detail will have the effect of hiding important parts from the reader. For example, instead of giving the formula corresponding to the algorithm's stopping criterion, you can simply write "If STOPPING CRITERION, STOP".
  • Notation and symbols: Too much notation makes the description more complex, while too little notation can be detrimental to understanding. A compromise must be found. My advice is to write the algorithm using as few symbols as possible, and to add them only when necessary.
  • Sub-function: It is often advantageous to use "sub-functions" that perform operations not directly related to the main algorithm. This allows the reader to concentrate on the key elements of the algorithm, without worrying about the details. When these sub-functions perform "standard" operations (sorting, finding the maximum of a set, etc.), trivial or otherwise explained in the text, they do not need to be defined. In other cases, we can define another algorithm corresponding to these sub-functions.

Finally (and this is a personal preference of the author), consider presenting your algorithms in the form of a flowchart.

3. Floating Environments (Tables and Figures)

3.1 General Rules

  • The figure/table must contain a caption.
  • Always use the figure/table number to refer to it. Avoid formulations such as "in the following figure/below", as its location may vary (floating LaTeX environment).
  • Content must be centered.

3.2 Figures

  • Be sure to follow the General Rules.
  • Use a high-resolution image or a vector graphic.
  • Make sure the figure looks good and is understandable in black and white.

3.3 Tables

Present, in order:

  1. A reference to the table.
  2. A description of the appropriate rows and columns in the table.
  3. The table.
  4. If necessary, an analysis of the table.

In addition,

  • Be sure to follow the General Rules.
  • Tables of results: Each column must correspond to an element addressed in the discussion.
  • Avoid rotating tables in landscape mode. Consider splitting the table into several tables or reducing space by writing headings on several lines.
  • Enter units (e.g. seconds, $, etc.) when not obvious.

3.3.1 My Table is Too Big for the Page!

If the table you are presenting is too large for the page, consider:

  • Removing irrelevant columns. If a value is not being discussed or analyzed, there is often no point in including it in a table.
  • Splitting the table in two.
  • Putting column headings on two lines. This can be done using the \tabular and \multirow commands.
  • Removing spaces between columns. This can be done using the @{} symbols in the \tabular environment header. For example: \begin{tabular}{@{}c@{}c@{}}.

4. Miscellaneous

4.1 Acronyms

  • When using the term for the first time, define the acronym in parentheses.
  • Always use the acronym instead of the term thereafter, except in chapter and section titles.
  • Acronyms are pluralized. For example: a linear program (LP) and linear programs (LPs).

4.2 Synonyms

The use of synonyms to describe the same concept is not recommended.