StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Really hard question. I hope your answers turn up something good. Meanwhile, here is a catalog of mistakes or other annoying things that I have found in beginners' code. There is some overlap with the Cal Tech style page that Kornel Kisielewicz points to. Some of my advice is every bit as vague and useless as the HaskellWiki "gems", but I hope at least it is better advice :-)</p> <ul> <li><p>Format your code so it fits in 80 columns. (Advanced users may prefer 87 or 88; beyond that is pushing it.)</p></li> <li><p>Don't forget that <code>let</code> bindings and <code>where</code> clauses create a mutually recursive nest of definitions, <em>not</em> a <em>sequence</em> of definitions.</p></li> <li><p>Take advantage of <code>where</code> clauses, especially their ability to see function parameters that are already in scope (nice vague advice). If you are really grokking Haskell, your code should have a lot more <code>where</code>-bindings than <code>let</code>-bindings. Too many <code>let</code>-bindings is a sign of an unreconstructed ML programmer or Lisp programmer.</p></li> <li><p>Avoid redundant parentheses. Some places where redundant parentheses are particularly offensive are</p> <ul> <li><p>Around the condition in an <code>if</code> expression (brands you as an unreconstructed C programmer)</p></li> <li><p>Around a function application which is itself the argument of an infix operator (<em>Function application binds tighter than any infix operator</em>. This fact should be burned into every Haskeller's brain, in much the same way that us dinosaurs had APL's right-to-left scan rule burned in.)</p></li> </ul></li> <li><p>Put spaces around infix operators. Put a space following each comma in a tuple literal.</p></li> <li><p>Prefer a space between a function and its argument, even if the argument is parenthesized.</p></li> <li><p>Use the <code>$</code> operator judiciously to cut down on parentheses. Be aware of the close relationship between <code>$</code> and infix <code>.</code>:</p> <pre><code>f $ g $ h x == (f . g . h) x == f . g . h $ x </code></pre></li> <li><p>Don't overlook the built-in <code>Maybe</code> and <code>Either</code> types.</p></li> <li><p>Never write <code>if <expression> then True else False</code>; the correct phrase is simply <code><expression></code>.</p></li> <li><p>Don't use <code>head</code> or <code>tail</code> when you could use pattern matching.</p></li> <li><p>Don't overlook function composition with the infix dot operator.</p></li> <li><p>Use line breaks carefully. Line breaks can increase readability, but there is a tradeoff: Your editor may display only 40–50 lines at once. If you need to read and understand a large function all at once, you mustn't overuse line breaks.</p></li> <li><p>Almost always prefer the <code>--</code> comments which run to end of line over the <code>{- ... -}</code> comments. The braced comments may be appropriate for large headers—that's it.</p></li> <li><p>Give each top-level function an explicit type signature.</p></li> <li><p>When possible, align <code>--</code> lines, <code>=</code> signs, and even parentheses and commas that occur in adjacent lines.</p></li> <li><p>Influenced as I am by GHC central, I have a very mild preference to use <code>camelCase</code> for exported identifiers and <code>short_name</code> with underscores for local <code>where</code>-bound or <code>let</code>-bound variables.</p></li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload