[ Home | Lab | New Students | Courses | Research | Publications | Activities ]

A foolish consistency is the hobgoblin of little minds,
adored by little statesmen and philosophers and divines.
--Ralph Waldo Emerson, Self-Reliance from here

This page is meant for my advisees. It enumerates several grammatical, stylistic, and other habits I have acquired about writing, editing, and presenting over the years. They may seem idiosyncratic in some cases, but often there is method to my madness. Even when these editing habits are idiosyncratic, I will insist on them.

An important observation: you simply have no choice but to learn to get your grammar and the rest of writing straight. You cannot outsource it. In particular, professional dissertation editors who make a business of fixing students' writing often leave some presentational errors and, worse, introduce technical errors and ambiguities. I am saying this on an evidence of one for a dissertation editor that a student of mine used plus several instances of professional editing I have seen my own and others' writing go through. Professional editors can help, but you are still responsible for what you write.

This page mixes in general advice and the expectations I have regarding any drafts or papers that I am handed by a student. I frequently notice these being violated by students. The violations distract me from scientific discussions which, after all, is what we should concentrate on. I hope to get these points better organized as I get the time. Your comments are welcome.

1. Use LaTeX and BibTeX for any serious writing.
2. Use the times package for easy conversion to pdf. To do so, place the following:

        \usepackage{times}
        

   in the preamble.
3. Place two spaces between sentences in the same para.
4. Use emacs if possible for text-preparation: it simplifies a lot of the editing.
5. I have recently had the occasion to use an Eclipse plugin for latex. It is not bad at all. If you use it, I suggest you set the defaults so that line breaks occur at 72 characters and there are two spaces between sentences.
6. Spell-check the whole document; then proof read it. It is rude to off-load this task on your readers (unless as a special request to proof read something after you have already proof read it yourself). Some reviewers will be quite offended to see bugs that you should have caught.
7. Always include the title, your name, and date on the title page.
8. Number all pages, preferably at bottom center.
9. For generic drafts use 12pt font with textwidth of 6.5 inches and textheight of 8.5 in. For submissions, use whatever format is required for submission.
10. Remember to acknowledge any financial support you receive through the university. Ask me for the numbers (IDs) of any grants that may have supported your work. Thank others who gave you comments. Don't thank your coauthors! If you thank some people, spell their names correctly, and use their given names and last names.

1. Place whitespace immediately before an open parenthesis or brace or bracket, but not immediately after. Citations typically come out in brackets, so leave a space before each of them.
2. Don't place whitespace immediately before a closing parenthesis or brace or bracket, but do place a space or a punctuation character immediately after. Citations typically come out in brackets, so leave a space or a punctuation character after each of them.
3. Place whitespace immediately after a comma, a colon, or a semicolon, but none immediately before them.
4. Don't use footnotes. Decide if it is worth stating in the main text; if not, don't say it.
5. Place all captions at the bottom of the given figure or table. Don't also have a caption within the figure, especially if you drew it separately and are including it in the paper. For separate figure files, name the files systematically and make the name match the internal LaTeX label for the figure. Mike Huhns prefers table captions at the top; that can work too if you do so uniformly. Also, publishers may impose their own styles.
6. Write all captions in sentence case: first letter (of first word) upper case, all else lower case. Don't end with a period unless you have multiple sentences in the caption (aside: you can have long captions to explain a figure right there, although generally you would put the explanations in the main text).
7. Almost always, you should refer to a figure from the main text. The publication Nature doesn't do that, but most will require it. It is a good idea even if not required—otherwise your readers may be confused about why you included a certain figure.
8. Write an en-dash as "--" with no spaces on either end. Thus "11--23" will appear as "11–23" and that's how you want it. Likewise, write an em-dash as "---" with no spaces on either end.
9. Use a single closing quote (') to mean an apostrophe, e.g., "Bob's car." An opening quote doesn't make an apostrophe.
10. Use apostrophes for possessives [and genitives, if you want to be technical :-)], but not for plurals. That is, avoid constructions like "ETD's" when you mean multiple ETDs. Use "ETD's" in sentences of the following form "The ETD's link is broken."
11. Don't use too many contractions. In particular, never use contractions such as "we'll," "I'll," "we've," and so on (not even in a draft paper). For more formal work, don't even use "don't," "doesn't," "can't," and "won't." And don't ever use "u" and "ur" in any writing where there is a risk that I might see it.
12. Don't use numerals in text for the smaller numbers. For example, don't say "the agent talks to 3 other agents." Some publications use words for numbers ten and smaller. That is a good strategy. Conversely, don't spell out a large number such as 157. It would be quite odd to read "our experiments involved one hundred fifty seven agents."
13. Don't begin a sentence with a lowercase letter. For example, if you are saying something about a technical word or a word in your program that begins with a lowercase letter, try to work in another word in front of it. For example, try not to write "serviceProvider refers to ..."; instead write "The serviceProvider field refers to ..." I might accept something like "eBay"—I won't insist on it either way. Uniformity throughout a document is key.
14. Don't begin a sentence with a numeral.
15. Don't begin a sentence with a citation.
16. Don't begin a sentence with a bracket or parenthesis.
17. When introducing a new term, don't use quotes; italicize the term instead. In general, the fewer the quoted terms the better.
18. In US usage, (commas or periods) and quotes go in a non-context free manner (e.g., ``this.'' or ``this,'').
19. In the rare case where you must use a footnote, do not place its superscript (in the main text) just before a comma or period. This too is US usage and not context free (in the sense of grammar), but it looks better (at least once you get used to it) because it reduces the white space visible above the punctuation.
20. Learn to distinguish "that" from "which." The previous sentence was my longstanding admonition, but it hasn't worked, so here's more detail:
    • P that Q means {x: P(x) and Q(y)}. For example, "large computers that are fast" refers computers that are both large and fast.
    • P, which Q means {x: P(x)} and by the way P entails Q. For example, "large computers, which are fast" refers to large computers and further claims that large computers are fast. People who have heard of ENIAC and interpret "fast" in modern terms recognize this claim to be false.
21. List three or more items with commas all the way: "A, B, and C" but not "A, B and C" unless B and C together are one thing. In that case, in some situations it might be better to phrase this as "B and C, and A" (which deviates from this rule a little by using a comma even when there are two items involved).
22. Go easy on the subscripts. LaTeX makes it attractive to write complex formulas, but complex formulas are never attractive. Don't over-complicate your notation.
23. Explain every figure at least briefly in text.
24. Keep simple line-drawings in figures—clutter arises easily if one is not careful and is not easy on the reader. Boxes with shadings rarely look good in a paper—too industrial and too much like a presentation. Scanned in figures are rarely appropriate except for early drafts—and for early drafts even scanned in hand drawings should be fine.
25. Use the same typeface for text in figures as in the main paper (times works well for both—even if they are slight variants of each other).
26. Use a smallish type size for the text in figures, e.g., 10 or 9pt. The main text of your paper will range from 10pt to 12pt, so 10pt in the figures will be ideal.
27. Make figures to be about 3.25in wide or about 5.5in wide. The former can fit in a two column format and save space. Doing so is often a consideration for most conference submissions. The latter can fit in the Springer Lecture Notes format, also a common format for computer science publications.
28. Color is fine, but relying on it is risky, because many people will print your paper on black-and-white printers. So you can't exploit color in the text (e.g., by saying, "the green box") and you ought to check that the greyscale version of the color is OK. Also, remember that some readers are color blind. However, color is useful when available, because it can highlight some relationships, so use it but make sure the paper will be comprehensible in greyscale.
29. In the Windows world, you can generate postscript is by printing to file when the printer is set to one of the oldest Apple Laserwriters for which your PC has drivers. Apparently, the old Laserwriters used an old version of postscript, which is compatible with most tools. This process is somewhat cumbersome. I don't recommend it except as a last resort.
30. Insert a space in references: "Chapter3 discusses" => "Chapter 3 discusses." In LaTeX, this means you would place a tilde before any \ref, as in "Section~\ref{sec-foo}."
31. For an in-text formula, put any ending parentheses on the same line as the rest of the formula—i.e., split the formula somewhere other than at the last parenthesis or even the last few parentheses.
32. Treat all items in the same item list alike in terms of capitalization.
33. Capitalize sections, subsections, subsubsections (i.e., make first letter of all big or important words upper case).
34. Use sentence case for paragraph headings and end each heading with a period.
35. End all items in an item list with or without periods (preferably with).
36. A document node (e.g., section) should either have no children (e.g., subsections) or have two or more children.
37. Item lists and enumerations should have two or more entries.
38. Use emphasis fonts, e.g., italics or bold, only for a few words or phrases.
39. I generally prefer to leave names of disciplines such as "computer science" in lower case, instead of "Computer Science." My rationale is that too many capitalized words spoil readability. Further, capitalization makes concepts appear more grand than they are.
40. Capitalize the following words carefully, also in your bib files:
    1. Internet.
    2. Web.
    3. eBay.
    4. tModel.
41. When a whole sentence is parenthetical, the period that ends the sentence goes within the parentheses.

1. Use quotes as ``this''—LaTeX will then print them correctly, although they might look weird on a browser. By contrast, LaTeX will print "foo" as having closing quotes on either side.
2. Encapsulated postscript (eps) fits in well into LaTeX. You can generate eps from drawing tools such as Visio. You can also convert postscript into eps through ghostview.
3. You can also embed pdf into LaTeX if you use pdflatex. pdflatex doesn't take postscript, though. A simple strategy is to generate eps and convert it to pdf via the tool epstopdf. In your latex files, include the figure via \includegraphics and do not specify the file extension. Then latex picks up with eps version whereas pdflatex picks up the pdf version of the figure.
4. Don't use hard constants for internal references in the paper. Use something like "Section~\ref{sec-foo} shows," which should expand to the correct section number and with a space to boot. Likewise, "Figure~\ref{fig-foo} illustrates ..." The ~ is a so-called tie in LaTeX. It forces the characters of either side of it to be typeset with an intervening space but on the same line. Using it helps avoid poor typesetting, e.g., where the last word of a line or page is "Figure" and the first word of the next line or page is "4."
5. When referring to a section, figure, table, or chapter, capitalize it, e.g., "Figure 4 illustrates this point," but not otherwise, e.g., "the following figures show ..." However, it is best not to say "the following figures" or "the above figures" because (1) LaTeX may place the figures differently than you expect when you edit the file or change the style and (2) you may move text around and suddenly find these implicit references (i.e., "above" and "following") to be out of whack.
6. Where appropriate use \texttt{...} to place a term or expression in typewriter (aka teletype or tt) font. This is good for small code-like text.
7. Don't use math fonts for identifiers that are longer than a letter. That is, $FP$ is wrong. It shows up with a large gap between the F and the P. Instead use \textit{FP}. When you need such an identifier as a subscript or superscript, enclose it in \mathrm as in $Q_{\mathrm{FP}}$.
8. For large formulas (with multiple subscripts), use \[ \] or other display modes in LaTeX to make sure they are large enough to read.

1. Use BibTeX, of course.
2. Use full name references, readily generated using

        \usepackage[square]{natbib}
        \bibliographystyle{plainnat}
        

   in the preamble and end of the LaTeX source files.
3. To use BibTeX correctly, you must put each reference into an entry of the correct kind, e.g., @book, @article, @inproceedings, and others.
4. BibTeX has a bad habit of putting all article and chapter titles in sentence case; this can mess up the capitalization of words. However, if you put the words in braces, their capitalization is safe, e.g.,

    title = {Life on the {Internet}} 

   will leave Internet capitalized.
5. Supply correct names for forum of publication (e.g., journal), appropriately capitalized.
6. Supply page numbers.
7. For collections, supply an editor; for proceedings you don't need to.
8. For collections and books, supply a publisher. Use a short name for the publisher as in my bib file. Supply an address for the publisher as a city name; the state and country name are not needed for well-known cities, e.g., "Berlin" is good enough—you don't need "Berlin, Germany."
9. Use full first names of authors (along with middle initials and full last name), not "G.B. Shaw" but "George B. Shaw" or even "George Bernard Shaw" (if, like Ralph Waldo Emerson, the author is known with his or her full middle name).
10. For multiple authors or editors, BibTeX uses
    {First1 M1. Last1 and First2 M2. Last2 and First3 M3. Last3 and First4 M4. Last4}
    The correct entries are generated from the above syntax; by contrast, if you start with
    {First1 M1. Last1, First2 M2. Last2, First3 M3. Last3, and First4 M4. Last4}
    it acts as if you have two authors, one with a long, weird name. Good examples are in the bib files I post.
11. First authors with names with suffixes must be treated specially; see my bib files; look for "Petrie, Jr.," for example.
12. Place your own bib entries in a separate file, ideally named eosLoginID.bib. Periodically, I may want to clean up the entries you made and add them to one of my files. You have access to my files, of course.
13. To make sure that certain words (such as Internet) are capitalized or are written in mixed case (such as tModel), enclose the entire word in braces, e.g., {Internet}. If the bib style were to force the entire title into uppercase, this won't work, but I haven't encountered such a style. A safer style would be {I}nternet, but I don't like this because it makes checking spellings harder.

1. Don't hesitate to get other students to comment on your work. They can help identify a lot of potential problems with the exposition or the content that you or I may not notice.
2. Be willing to reorganize your paper and rewrite large parts of it. It is generally a bad idea to get attached to some phrasing. Mark Twain once recommended that authors should find their favorite sentence in whatever they wrote and delete it.
3. See my page on Guidelines for Writing Papers
4. Reusing your own prose is potentially tricky. It is OK to share text between an externally submitted or published paper and an internal document (thesis, dissertation, written prelim, technical report). Specifically, a submission can be identical to a TR. However, there should not be two concurrent external submissions of the same material or a submission after a separate publication. It is OK to share across workshops and conferences, but a short note in the paper (indicating overlap) is appropriate.

   When you work on a new topic or have sufficiently new results, but with a similar motivation and technical framework as before, it is tempting to reuse old prose. In my experience, it is better to rewrite the motivation, because each (intended) target audience is different. For the technical framework, it might be OK to reuse older (debugged) descriptions as background with acknowledgment of previous publication. This assumes there are enough new results in the rest of the paper. The justification for reuse is that you can't be expected to invent, e.g., a new temporal logic in each paper. Moreover, you can relate your new work more easily to the existing body of work by using the framework used in the existing work. Of course, this presumes your interesting results are not in the logic per se.

For a technical talk, you need to be able to get into sufficient detail that the audience can walk away knowing the subject moderately well. They won't become specialists, but they should know what technical challenges there are and how you are addressing them. If people who attended your talk can summarize your talk confidently and well, that is the best success you can hope for!

1. When you are trying to report on other people's work and it was not clear to you, say what you understood and what was not clear. Don't dwell on what was not clear unless you can point to what is missing from the other work. Saying something is not clear is always tricky, because the authors presumably think it is and might be offended. If you can raise a technical objection that is a lot better. To convert a remark about unclarity into a remark about technical inadequacy, try to give an example. Say what interpretations are possible in the paper that you are reviewing. If one of the interpretations is acceptable probe it further or find another example where it is not acceptable. In the end, if there is an interpretation that works, then maybe the shortcoming of the explanation of the paper rather than its basic idea.
2. Put your name and the date on each presentation. Number all pages so I can easily give comments on a draft and the audience can easily ask questions about specific slides.
3. Zero in quickly on the new stuff—that is, have a short introduction.
4. Give an outline.
5. Avoid overly dense figures. If you can eliminate some detail, do.
6. Minimize mathematical symbols. If you need a few symbols, powerpoint with TexPoint can work. If you need a lot of symbols (extremely rare case), consider using LaTeX to prepare the slides. In fact, you can use LaTeX anyway even if powerpoint will work.
7. Leave some blank space at the bottom of your slides. Often, especially in large rooms such as for the major conferences, the bottom 10–15% of your slides won't be visible to the audience, especially those sitting at the back.
8. While you don't want too much text on your slides, place enough text that someone reading your slide can hope to guess at your intended meaning. There are two motivations for this. One, some people will read your slides, e.g., from handouts or off the Web. Two, sometimes the audio at a conference can be messed up and you don't have a chance getting through if your slides are not self-contained.
9. Use a pointer if you can. When you use a laser pointer, don't let it wander when you aren't using it. People pay a lot of attention to a pointer, even an erratic one or perhaps especially an erratic one.
10. As for papers, distinguish different kinds of terms with different type-faces.
11. Use sentence fragments in bullet items; only rarely are whole sentences OK.
12. When giving a talk, repeat any questions that are asked from the audience. Often, other attendees can't hear the question—and, you might be the only one with a mic. Plus, you should paraphrase the question to match more closely what you are going to answer.
13. Know reasonably standard pronunciations of the words that you are using. (I am beginning to assemble a list of tricky words.)
14. It is a good idea to skip over details when giving a presentation. This is one of the hardest things to carry out, though. Be careful not to let yourself be drawn into topics you decided you wouldn't care to present.
15. For a time-limited talk (aren't they all?) be aware of the time you have left. Pay attention to your conference session chair and request sufficient time warnings so you can be sure to include your key conclusions and leave time for questions.
16. Some people include a slide at the end that says "Questions?"—I find that quite rude. When you are addressing your peers or your graduate committee, you don't say "any questions?" to them. They will ask questions when they want to. Say nothing or say thanks.
17. For slides that are part of a series on a topic, use sequence numbers in the title, as in "Foo: 1" and so on. If you just say "Foo" it doesn't tell the audience that more is coming or where you are in the sequence. And, "...contd" and its variants are too long.