My top ten presentation issues in other's papers

I am a frequent reviewer of submissions for scientific journals and conferences.  By far most of my reviews are specific to the individual paper, its contributions, and its issues.  However, there is a small number of presentation problems which I have to report again and again.  All these problem are very minor, and none of them will make me reject your paper.  However, fixing them is a matter of minutes, and will make your paper an easier read for both readers and reviewers:
  1. Abstracts without results.  Many abstracts end with the words "We conducted a study to show the effectiveness of our approach".  There's three things wrong in here:
    1. You conduct a study to evaluate your approach – if you run your study with a predetermined outcome, I will suspect a flaw in your setup.
    2. As a reader of your abstract, I am not so much interested in your process, but in your results; if you want cliffhangers, go and write TV shows instead. 
    3. You need results to sell your paper in the review process – in particular for outsiders who take only a brief glance at your paper.
    So make this "Our study shows a 25% precision increase" or some other strong argument.
  2. Multi-letter identifiers in LaTeX math mode.  In LaTeX, $foo$ stands for the product of three variables f, o, and, o; and LaTeX typesets it as such.  If you want one variable, use $\textit{foo}$.  (For a computer scientist, this is the single biggest design failure of TeX and LaTeX.)
  3. Confuse hyphens, minus signs, and dashes.  All these typeset into different characters: 
    1. Hyphens: state-1 is blue, state-2 is red.
    2. Minus signs: $\textit{bar} = \textit{foo} - 1$
    3. En-dashes (for ranges): A car has 3--4~wheels
    4. Em-Dashes (for sentences): He said ``captain''---I said ``wot''.  (This can also be typeset using en-dashes with spaces, as in He said ``captain''~-- I said ``wot''.)
  4. Bad capitalization in BibTeX references, as in "[1] Jai: a javascript api ide" (should be "[1] JAI: A JavaScript API IDE")  I could include this in all my reviews and be right 60% of the time.
  5. Omitting reference information.  I see papers omitting page numbers, conference names, editors, or even authors.  I suppose that "[1] Smith et al., ICSE 2004" is something I should Google, and I hope there's just one Smith at ICSE.  (This even occurs in papers whose venues have no page limit for references!)
  6. Orphaned numbers, as in "I want 17<newline>foos."  Tie numbers to items using non-breakable space (Word) or using a tilde (LaTeX): I want 17~foos.
  7. Orphaned lines and titles.  Section title at end of page 3, actual section on page 4.  Better yet: a single line of text left under a table, such that you easily confuse content and caption.  "LaTeX gets this wrong" is not an excuse; please fix this.
  8. Using monospacing with a non-monospaced font (or vice versa).  This seems to be a default setting of the LaTeX "listings" environment – using Times fonts and arranging the letters at equal distance.  Use monospaced fonts with monospacing, and proportional fonts otherwise.
  9. Omitting articles, as in "Main feature is lack of articles".  Now that spell checkers weed out the most blatant errors, the more subtle errors remain – and this is my #1 grammar issue.  If your native language has no articles, take double care.
  10. Testing the limits.  Page limits are there for a reason – not to save trees, but to save the time of your readers by requiring you to focus on the main points.  Cramming every little detail into the paper will decrease readability and alienate your readers; it may also lead to desk rejection if you alter the format.  Stick to standard style, cut down your paper to one page less than the limit and have your paper proof read by others, then add whatever your proof readers missed.
All these issues can be fixed through simple proofreading, and leave your readers and reviewers more time to enjoy the actual content.  And now that the syntax is done, let's get back to semantics!

(As a reviewer or reader, what are your favorite gripes?  Use the commenting function below.)


  1. Thanks for enumerating these aspects. While I don't mind (3) to (9), I find the others really important.

    I do HATE imprecise abstracts --- use them for concise information to help the reader, not as "ad space"!

  2. I'm sorry you had to see a citation where you were editor but your name wasn't listed.

  3. Ah, I still like Kent Beck's abstract style:



Note: Only a member of this blog may post a comment.