Andreas Zeller

Andreas Zeller (high resolution photo)

Andreas Zeller is faculty at the CISPA Helmholtz Center for Information Security and professor for Software Engineering at Saarland University. His research on automated debugging, mining software archives, specification mining, and security testing has proven highly influential. Zeller is one of the few researchers to have received two ERC Advanced Grants, most recently for his S3 project. Zeller is an ACM Fellow and holds an ACM SIGSOFT Outstanding Research Award.

Mail:  andreas.zeller@cispa.de
Phone:  +49 681 87083-1001
Bluesky:  @andreaszeller.bsky.social
Mastodon:  @AndreasZeller@mastodon.social
Linkedin:  andreaszeller
GitHub:  andreas-zeller

Hosted on GitHub Pages — Theme by orderedlist

5 April 2013

My top ten presentation issues in other's papers

by Andreas Zeller

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.)
tags: