Consistent and Concise Naming
Concise and Consistent Naming
Florian Deißenb¨ock and Markus Pizka
Proceedings of the 13th International Workshop on Program Comprehension (IWPC’05)
I read this paper because it appeared in the bibliography of Identifier length and limited programmer memory.
This paper basically argues for extremely consistent identifier names in any given software project. The authors go so far as to argue for per project “identifier dictionaries”, so as to keep variable, package and function names rigidly consistent, and also to identify concepts relevant to the project. I’d be in favor of this getting one on any project I worked on, but the keeper of the dictionary is important. The usual politics-playing manager would be unable to choose names and identify concepts that don’t fit the politics of the day. Someone objective and dignified should keep the dictionary.
There are some interesting points made in this paper, like defining “concise” as “more meaningful”. The authors also understand that their project dictionary will have to contain application domain (what the project’s subject is, computer vision, or tax prep, or inventory accounting, and from the implementation domain, stacks, queues, and computer science concepts.
Here’s an interesting quote:
Technically, identifiers are merely syntactic entities acting as aliases for memory addresses where variables, method or classes are stored. But, since the introduction of symbolic names identifiers additionally have to fulfill a far more important purpose that is giving the reader of the program a clue to the concept behind these addresses, i.e. its meaning.
That’s quite profound. A definition of “identifier” is truly mundane, but has vast consequences to humans. If code has terrible identifier names, you have to read and understand entire functions before you can judge their relevancy. Also:
Lousy naming in one place spoils comprehension in numerous other places.
I’m really not too keen on their “formal model” of concepts and identifiers. It seems like a ton of work that could be ruined by a verdict from Oh High, where some executive vice president declares that concept A and concept B Must Be Grouped Together, as Concept C.
An interesting paper with a lot to think about in it, and also some great quotes.
This paper’s 25-item bibliography looks like it references some good material.