Associate Professor · Carnegie Mellon University · Institute for Software Research
Our paper "The Love/Hate Relationship with The C Preprocessor: An Interview Study" has just been accepted for ECOOP 2015 and that was one of the papers for which we discussed possible titles in quite some length. I would like to use this opportunity to reflect a little about our process of selecting titles and would like to share some rejected title ideas below...
I find selecting good paper titles quite difficult. A good title is short and easy to remember and says something about the work and preferably even something about the results. A title is the first thing a potential reader encounters and is the first and sometimes only criteria to decide whether to read or review the paper or attend the talk. A good title probably has quite some impact on whether the work is read and remembered.
I have a number of papers for which I regret the title. Our OOPSLA'11 paper “Variability-Aware Parsing in the Presence of Lexical Macros and Conditional Compilation” is a good example. Its title is technically precise but clunky. Variability-aware parsing is our own term and I don't expect others have an intuitive idea of what it entails. A year later, an almost identical approach was published as “SuperC: Parsing all of C by taming the preprocessor” (there are lots of technical differences, but conceptually both papers are very similar and make ideas of splitting and joining parsers going back to the early 1980s and 1990s work at a large scale). The SuperC title is shorter and much more intuitive. It describes the goal from the user's perspective (parsing all of C) instead of the technical issues that make parsing unpreprocessed C code hard (lexical macros and conditional compilation). Although it's true that you could use the technique also for other languages that use lexical macros and conditional compilation (and we have actually done so, for example, in the context of analyzing PHP), the main goal was and is to analyze C; I guess that people who can figure out that their problem is similar to parsing unpreprocessed C code can figure out that our tools might apply. The tool name SuperC in the title is definitively flashier than our concept of Variability-Aware Parsing. Although I like our tool name TypeChef, it doesn't convey what it is about. Furthermore, since we used the name TypeChef in the title of an early workshop paper sketching a rough idea of the project, now some people tend to cite that now completely outdated paper rather than the actual later research that now allows us to parse, type check, and statically analyze unmodified and unpreprocessed C code at the scale of the Linux kernel.
For the ECOOP paper, we actually had a longer discussion about the title through several iterations over email and Skype. The paper is about an interview study with open source developers on how they perceive the C preprocessor. Essentially, we were wondering why people kept using the C preprocessor despite heavy criticism and why they would not adopt any of the alternatives that researchers have come up over the years (from syntactic preprocessors to languages with sophisticated metaprogramming facilities). Although problems are well known, even C# still contains lexical conditional compilation. Anyway, we needed a title describing that we studied the developers' perception of the C preprocessor with interviews.
Our first placeholder title was “Why is the C preprocessor still breathing?”, but that felt a little aggressive and wasn't saying much anyway. Going back to my email archive, here are a bunch of early suggestions:
Some of them indicate how we performed the study and they are more or less describing our research questions, but none cover any results. At this point, we started brainstorming a bit for titles. One patterns for titles that I like (that I noticed first explicitly with Emerson's paper “Cowboys, ankle sprains, and keepers of quality: how is video game development different from software development?”) is to use bits of results or quotes in the title. This doesn't convey much meaning upfront, but makes the paper easy to remember when you have seen the results and see how they are reflected in the title. Here are a list of suggestions:
--
And while I'm already diving into old emails, here some alternatives to our paper “Understanding Understanding Source Code with Functional Magnetic Resonance Imaging”. I really like this title although (or because) almost everybody stumbles over the “Understanding Understanding” part in the beginning and we actually explain this in the beginning of the talk, but it also pretty exactly describes what the paper is about.
We went from
And finally we met somewhere in the middle.