<p>I tend to use something resembling Python syntax. Python is close enough to pseudocode already that in some cases my pseudocode can shade into being actual working code.</p>

CC BY-SA 3.0
2013-11-17T20:18:26.223Z
Me also, but in Ruby. With github gists you can easily share executable snippets for them to play with. https://gist.github.com/chadbrewbaker/7202412
Chad Brewbaker
CC BY-SA 3.0
2015-05-26T23:38:06.730Z
Python is however not good to represent linear algebra. Octave is a better fit I think in this case (closer to pseudocode).
gaborous
CC BY-SA 3.0
2011-11-09T16:50:49.940Z
2011-11-09T16:50:49.940Z
David Eppstein
<p>If you want to have definite code (i.e. little to no math, close to real programming) you might want to consider to have code that actually compiles. This has several advantages:</p>

<ul>
<li>You get syntax highlighting everywhere.</li>
<li>Compiler checks syntax for you and enforces consistency.</li>
<li>You can unit-test your implementations to improve code quality.</li>
<li>You can run the algorithm and compare measured runtimes to analyses (thusly motivating advanced analysis techniques).</li>
</ul>

<p>A professor at my university does this in his algorithms course. His language of choice is Modula. I don't think the particular choice of language matters, though. Just stick to one (per paradigm) that fits your level of abstraction best.</p>

CC BY-SA 3.0
2015-05-26T23:40:25.657Z
"Just stick to one (per paradigm) that fits your level of abstraction best." I think this is a great advice to find an alternative to pseudocode. There are lots of languages, and almost always there is at least one that target a simple syntax for specific paradigm: Ada for concurrent design, Octave for linear algebra, Python for procedural, NetLogo for multi-agents systems, Prolog for logic, CLIPS for rule-based programming, etc.
gaborous
CC BY-SA 3.0
2015-05-27T06:11:25.780Z
@gaborous If you can have readable, abstract code -- go for it. Unfortunately, I suspect that this will have you using at least three languages in any larger body of work; that would be unfortunate, too.
Raphael
CC BY-SA 3.0
2015-05-27T13:23:28.023Z
of course I agree for larger code there's no language, but for small, core algorithms, it's often possible to find a language which is very close to pseudocode.
gaborous
CC BY-SA 3.0
2011-11-11T21:27:56.907Z
2011-11-11T21:27:56.907Z
Raphael
<p>Writing pseudocode is like writing code:  It's not particularly important which standard you follow, as long as you (and the people you write with) actually follow <em>some</em> standard. </p>

<p>But for the record, here's the idiosyncratic standard I use in my lecture notes, research papers, and upcoming book.  </p>

<ul>
<li><p>Use standard imperative syntax for control flow and memory access — if, while, for, return, array[index], function(arguments).  Spell out "else if".</p>

<ul>
<li>But use $field(record)$ instead of <code>record.field</code> or <code>record-&gt;field</code></li>
</ul></li>
<li><p>Use standard mathematical notation for math — Write $xy$ instead of <code>x*y</code>, $a\bmod b$ instead of <code>a%b</code>, $s\le t$ instead of <code>s &lt;= t</code>, $\lnot p$ instead of <code>!p</code>, $\sqrt{x}$ instead of <code>sqrt(x)</code>, $\pi$ instead of <code>PI</code>, $\infty$ instead of <code>MAX_INT</code>, etc.</p>

<ul>
<li><p>But use $x\gets y$ for assignment, to avoid the <code>==</code> problem.</p></li>
<li><p>But avoid notation (and pseudocode!) entirely if English is clearer.</p>

<ul>
<li>Symmetrically, avoid English if notation is clearer!</li>
</ul></li>
</ul></li>
<li><p>Minimize syntactic sugar — Indicate block structure by consistent indentation (à la Python).  Omit sugary keywords like "begin/end" or "do/od" or "fi".  Omit line numbers.  Do <em>not</em> emphasize keywords like "for" or "while" or "if" by setting them in a different <code>typeface</code> or <strong>style</strong>.  Ever.  Just don't.</p>

<ul>
<li><p>But typeset algorithm names and constants in \textsc{Small Caps}, variable names in <em>italic</em>, and literal strings in sans serif.</p></li>
<li><p>But add a small amount of vertical "breathing" space (<code>\\[0.5ex]</code>) between meaningful code chunks.</p></li>
</ul></li>
<li><p>Don't specify unimportant details.  If it doesn't matter what order you visit the vertices, just say "for all vertices".</p></li>
</ul>

<p>For example, here is a recursive formulation of <a href="http://en.wikipedia.org/wiki/Bor%C5%AFvka%27s_algorithm" rel="noreferrer">Borůvka's minimum spanning tree algorithm</a>.  I've previously defined $G / L$ as the graph obtained from $G$ by contracting all edges in the set $L$, and Flatten as a subroutine that removes loops and parallel edges.</p>

<p><img src="https://i.sstatic.net/gzgWB.png" alt="Borůvka&#39;s algorithm"></p>

<p>I use my own lightweight <a href="http://www.cs.uiuc.edu/~jeffe/pubs/tex/jeffe.sty" rel="noreferrer"><code>algorithm</code> LaTeX environment</a> to typeset pseudocode.  (It's just a <code>tabbing</code> environment inside an <code>\fbox</code>.)  Here's my source code for Borůvka's algorithm:</p>

<pre><code>\begin{algorithm}
 \textul{$\textsc{Borůvka}(G)$:}\+
\\ if $G$ has no edges\+
\\  return $\varnothing$\-
\\[0.5ex]
 $L \gets \varnothing$
\\ for each vertex $v$ of $G$\+
\\  add the lightest edge incident to $v$ to $L$\-
\\[0.5ex]
 return $L \cup \textsc{Borůvka}(\textsc{Flatten}(G / L))$
\end{algorithm}
</code></pre>

CC BY-SA 3.0
2011-11-10T17:03:23.203Z
interesting that you use field(record) instead of record[field]. I imagine this is the "$f_j(v)$ is the $j^{th}$ coordinate of $v$" view of the world ?
Suresh Venkat
CC BY-SA 3.0
2011-11-10T17:14:26.343Z
@SureshVenkat: It's how you usually do it in functional languages, and also the notation in TAoCP. (Obviously, I can't know if that's why JɛﬀE uses this notation.)
Radu GRIGore
CC BY-SA 3.0
2011-11-10T18:45:47.320Z
Doesn't this environment run into problems when you have "lines" that span more than one line?
Andrew D. King
CC BY-SA 3.0
2011-11-10T20:04:28.360Z
The main reason to be careful with pseudo-code is that it is easy to get confused about the algorithm so it is important to emphasize some things. Jeff's example above for Boruvka illustrates this. In the code L is being treated as a set. An edge uv can be the lightest edge incident to u as well as v so it is added twice in the loop but it does not matter if you think of L as a set. However, this is not obvious and some one implementing this can easily be tripped up if they implement L as a list.
Chandra Chekuri
CC BY-SA 3.0
2011-11-10T20:21:34.500Z
@JɛﬀE do you not like the standard LaTeX algorithms environment ?
Suresh Venkat
CC BY-SA 3.0
2011-11-11T16:14:26.493Z
“Don't specify unimportant details.”  This is very true, but also a little ironic….
Tsuyoshi Ito
CC BY-SA 3.0
2011-11-14T10:00:30.733Z
@SureshVenkat: What "standard"?
Jeffε
CC BY-SA 3.0
2011-11-14T10:05:08.027Z
@AndrewD.King: In theory, yes; in practice, it never happens.
Jeffε
CC BY-SA 3.0
2011-11-14T10:09:22.933Z
@TsuyoshiIto: Only a little?!
Jeffε
CC BY-SA 3.0
2011-11-14T10:14:07.667Z
@ChandraChekuri: Yes, implementing sets incorrectly can cause problems in algorithms that manipulate sets.
Jeffε
CC BY-SA 3.0
2011-11-14T13:18:54.793Z
JɛﬀE: If you prefer, you can take “a little” as a euphemism. :)
Tsuyoshi Ito
CC BY-SA 3.0
2011-11-14T16:11:42.137Z
@JE: There's a standard latex algorithms package (algorithms + algorithmic to be precise, like table + tabular)
Suresh Venkat
CC BY-SA 3.0
2011-11-16T13:38:13.827Z
@SureshVenkat: Oh, that.  No, I can't stand it.  Bold keywords make the baby Jesus cry.  Dijkstra should lose his Turing award for introducing that execrable typographical convention.
Jeffε
CC BY-SA 3.0
2013-11-18T09:29:36.867Z
I think it is a good idea to have line numbers if you are explaining something about the algorithm ("note that the recursive call in Line 9....") Of course, you should do the references to the line numbers with \label and \ref.
Daniel Marx
CC BY-SA 3.0
2011-11-10T14:04:33.473Z
2011-11-10T14:04:33.473Z
Jeffε
<p>This is about how effectively we can express an algorithm at hand. I need this for my undergraduate teaching. </p>

<p>I understand there is no such thing as standard way of writing a pseudo code. Different authors follow different conventions. </p>

<p>It would be helpful if people here point out, the way they follow and think the best one.</p>

<p>Is there any book that deals with this in a good detail?</p>

CC BY-SA 3.0
2011-11-09T17:23:08.980Z
"best" is very subjective, I think you should modify the title and in place of asking for "best" ask for what people do in practice. Maybe something like "how to present algorithms" or "good practices for presenting algorithms". You may also want to be more specific since presenting algorithms: 1. to students in an undergrad class 2. in a textbook 3. in a conference paper are very different tasks.
Kaveh
CC BY-SA 3.0
2011-11-10T15:48:15.853Z
You may also want to check the relevant sections of [Mathematical Writting](http://www-cs-faculty.stanford.edu/~uno/klr.html) by Knuth, Larrabee, and Roberts.
Kaveh
<ds.algorithms><soft-question><advice-request><writing>
Good practices for writing algorithms
user3162
# Good practices for writing algorithms

(Asked by: username_0 on 2011-11-09)

This is about how effectively we can express an algorithm at hand. I need this for my undergraduate teaching.

I understand there is no such thing as standard way of writing a pseudo code. Different authors follow different conventions.

It would be helpful if people here point out, the way they follow and think the best one.

Is there any book that deals with this in a good detail?

**Tags:** ds.algorithms, soft-question, advice-request, writing

> **Comments:**
> **username_1**: "best" is very subjective, I think you should modify the title and in place of asking for "best" ask for what people do in practice. Maybe something like "how to present algorithms" or "good practices for presenting algorithms". You may also want to be more specific since presenting algorithms: 1. to students in an undergrad class 2. in a textbook 3. in a conference paper are very different tasks.  
> **username_1**: You may also want to check the relevant sections of [Mathematical Writting](http://www-cs-faculty.stanford.edu/~uno/klr.html) by Knuth, Larrabee, and Roberts.  

---

## 3 answers

### Answer by username_6 on 2011-11-10. Score: 25 | Accepted answer

Writing pseudocode is like writing code:  It's not particularly important which standard you follow, as long as you (and the people you write with) actually follow some standard. 
But for the record, here's the idiosyncratic standard I use in my lecture notes, research papers, and upcoming book.  

Use standard imperative syntax for control flow and memory access — if, while, for, return, array[index], function(arguments).  Spell out "else if".

But use $field(record)$ instead of record.field or record->field

Use standard mathematical notation for math — Write $xy$ instead of x*y, $a\bmod b$ instead of a%b, $s\le t$ instead of s <= t, $\lnot p$ instead of !p, $\sqrt{x}$ instead of sqrt(x), $\pi$ instead of PI, $\infty$ instead of MAX_INT, etc.

But use $x\gets y$ for assignment, to avoid the == problem.
But avoid notation (and pseudocode!) entirely if English is clearer.

Symmetrically, avoid English if notation is clearer!


Minimize syntactic sugar — Indicate block structure by consistent indentation (à la Python).  Omit sugary keywords like "begin/end" or "do/od" or "fi".  Omit line numbers.  Do not emphasize keywords like "for" or "while" or "if" by setting them in a different typeface or style.  Ever.  Just don't.

But typeset algorithm names and constants in \textsc{Small Caps}, variable names in italic, and literal strings in sans serif.
But add a small amount of vertical "breathing" space (\\[0.5ex]) between meaningful code chunks.

Don't specify unimportant details.  If it doesn't matter what order you visit the vertices, just say "for all vertices".

For example, here is a recursive formulation of Borůvka's minimum spanning tree algorithm.  I've previously defined $G / L$ as the graph obtained from $G$ by contracting all edges in the set $L$, and Flatten as a subroutine that removes loops and parallel edges.

I use my own lightweight algorithm LaTeX environment to typeset pseudocode.  (It's just a tabbing environment inside an \fbox.)  Here's my source code for Borůvka's algorithm:
\begin{algorithm}
 \textul{$\textsc{Borůvka}(G)$:}\+
\\ if $G$ has no edges\+
\\  return $\varnothing$\-
\\[0.5ex]
 $L \gets \varnothing$
\\ for each vertex $v$ of $G$\+
\\  add the lightest edge incident to $v$ to $L$\-
\\[0.5ex]
 return $L \cup \textsc{Borůvka}(\textsc{Flatten}(G / L))$
\end{algorithm}

> **Comments:**
> **username_7**: interesting that you use field(record) instead of record[field]. I imagine this is the "$f_j(v)$ is the $j^{th}$ coordinate of $v$" view of the world ?  
> **username_8**: @SureshVenkat: It's how you usually do it in functional languages, and also the notation in TAoCP. (Obviously, I can't know if that's why JɛﬀE uses this notation.)  
> **username_9**: Doesn't this environment run into problems when you have "lines" that span more than one line?  
> **username_10**: The main reason to be careful with pseudo-code is that it is easy to get confused about the algorithm so it is important to emphasize some things. Jeff's example above for Boruvka illustrates this. In the code L is being treated as a set. An edge uv can be the lightest edge incident to u as well as v so it is added twice in the loop but it does not matter if you think of L as a set. However, this is not obvious and some one implementing this can easily be tripped up if they implement L as a list.  
> **username_7**: @JɛﬀE do you not like the standard LaTeX algorithms environment ?  
> **username_11**: “Don't specify unimportant details.”  This is very true, but also a little ironic….  
> **username_6**: @SureshVenkat: What "standard"?  
> **username_6**: @AndrewD.King: In theory, yes; in practice, it never happens.  
> **username_6**: @TsuyoshiIto: Only a little?!  
> **username_6**: @ChandraChekuri: Yes, implementing sets incorrectly can cause problems in algorithms that manipulate sets.  
> **username_11**: JɛﬀE: If you prefer, you can take “a little” as a euphemism. :)  
> **username_7**: @JE: There's a standard latex algorithms package (algorithms + algorithmic to be precise, like table + tabular)  
> **username_6**: @SureshVenkat: Oh, that.  No, I can't stand it.  Bold keywords make the baby Jesus cry.  Dijkstra should lose his Turing award for introducing that execrable typographical convention.  
> **username_12**: I think it is a good idea to have line numbers if you are explaining something about the algorithm ("note that the recursive call in Line 9....") Of course, you should do the references to the line numbers with \label and \ref.  

---

### Answer by username_2 on 2011-11-09. Score: 11

I tend to use something resembling Python syntax. Python is close enough to pseudocode already that in some cases my pseudocode can shade into being actual working code.

> **Comments:**
> **username_3**: Me also, but in Ruby. With github gists you can easily share executable snippets for them to play with. https://gist.github.com/chadbrewbaker/7202412  
> **username_4**: Python is however not good to represent linear algebra. Octave is a better fit I think in this case (closer to pseudocode).  

---

### Answer by username_5 on 2011-11-11. Score: 3

If you want to have definite code (i.e. little to no math, close to real programming) you might want to consider to have code that actually compiles. This has several advantages:

* You get syntax highlighting everywhere.
* Compiler checks syntax for you and enforces consistency.
* You can unit-test your implementations to improve code quality.
* You can run the algorithm and compare measured runtimes to analyses (thusly motivating advanced analysis techniques).

A professor at my university does this in his algorithms course. His language of choice is Modula. I don't think the particular choice of language matters, though. Just stick to one (per paradigm) that fits your level of abstraction best.

> **Comments:**
> **username_4**: "Just stick to one (per paradigm) that fits your level of abstraction best." I think this is a great advice to find an alternative to pseudocode. There are lots of languages, and almost always there is at least one that target a simple syntax for specific paradigm: Ada for concurrent design, Octave for linear algebra, Python for procedural, NetLogo for multi-agents systems, Prolog for logic, CLIPS for rule-based programming, etc.  
> **username_5**: @username_4 If you can have readable, abstract code -- go for it. Unfortunately, I suspect that this will have you using at least three languages in any larger body of work; that would be unfortunate, too.  
> **username_4**: of course I agree for larger code there's no language, but for small, core algorithms, it's often possible to find a language which is very close to pseudocode.  

---

