"Estimating Understandability of Software Documents" is a paper published in ACM Software Engineering Notes, Vol. 21, No. 4, 1996, pp. 81-92.
"Natural Naming in Software Development and Maintenance" is a doctoral thesis published in 1995.
A traditional abbreviated name for a variable which stores a character that is read from the keyboard might be ch. A natural version of such a name could be character_from_keyboard or characterFromKeyboard. A traditional abbreviated name for an index variable is i. This variable could be given a natural name such as character_index if an array of characters is being indexed, or event_index if an array of Event objects is being indexed.
Natural naming means implicitly that abbreviations and acronyms are
considered harmful in computer programs. (An acronym is a special case of an abbreviation.)
Abbreviations make computer programs less readable and understandable, which in turn
slows down activities related software development. The use of abbreviations
is especially harmful in large software development projects in which
programmers write programs that contain hundreds or thousands of names.
Because inventing informative natural names is an activity that needs
to be learned, it is good to study programming with example programs
that are written with natural names.
As I say in the Epilogue of my C++ book, I am not the only
person who has discovered the benefits of natural naming in programming and
software development. One company that recommends avoiding abbreviations
in names is Microsoft. The Internet pages of Microsoft Developer Network (MSDN)
as well as the C# Language Specification, a freely available
ECMA Standard number 334,
recommend that abbreviations should not be used in names.
(Use Google to find the General Naming Conventions of Microsoft.)
As I say in the Epilogue of my C++ book, I am not the only person who has discovered the benefits of natural naming in programming and software development. One company that recommends avoiding abbreviations in names is Microsoft. The Internet pages of Microsoft Developer Network (MSDN) as well as the C# Language Specification, a freely available ECMA Standard number 334, recommend that abbreviations should not be used in names. (Use Google to find the General Naming Conventions of Microsoft.)
A comprehensive discussion about natural naming can be found here.
If you want to see how programs with natural names look like, click here to find more than 850 programs that are written with natural names.
Here you can find Prolog programs
written with natural names.
I am, at least to some extent, against the use of debuggers because it is possible that the sole existence of those tools can make programmers less careful in their work. Errors in computer programs are errors in thinking and they result from inadequate understanding of the programming language or the application domain. I think it is more natural to try to understand the programming language and the application domain well than to resort to a tool after a program has been found behaving in a strange way.
A former colleague of mine, Mr. Ari Okkonen, once said during a software design course that we should get rid of spending time on debugging and, instead, start carefully designing programs. During that course Ari was teaching the use of a certain software design method, but in my opinion it is possible to add carefulness to programming work so that you simply carefully select informative natural names for your program. You have to spend time inventing the names but that spent time then increases your knowledge about the program you are developing.
When I was working in Holland in 1988, I once met a Belgian colleague whose boss had forbidden the members a software development team to use debugging tools. The reason for the ban of debugging tools was that when those tools are available people tend to rely too much on those tools and hence they forget how to write "good" programs.
At least theoretically, programs should be written so that they work as intended right after they have been written, and they compile without errors during the first compilation. This should be the aim in programming and software development work, though this goal can seldomly be reached. If one even thinks that he or she will use a debugging tool after a program has been written, the person in question has an obscure goal in his or her work. How can such a person produce well-working programs?
I find it quite annoying that some integrated development
environments have a Debug button so easily available on their toolbars.
The existence of such a button on a toolbar means as if the development
tool would say: "Here is this Debug button. Because you are such a stupid
person that you inevitably make errors, it is better to debug your programs."
Could it be that the existence of a Debug button on a toolbar is a kind
of invitation to writing low-quality programs? Does the Debug button say:
"Don't think too much. Just press this button when you have problems."
As I have explained in the epilogue of the C++ book, the reason why I wrote the book was that I wanted to write a programming book in which all example programs are written with natural names, names that are made of usually several natural words and not of abbrevaitions. According to my experiences, this kind of programming style forces a person to think carefully during the process of programming, and that results in better programs and less programming errors.
I suppose that a teacher or some other professional should accept, at least to some extent, the idea of natural naming in order to use my books in his or her work.
What I have learned during the past years is that people (inlcluding me) can be very sensitive about naming and other matters related to programming style. Programming is, at least partly, a kind of emotional process. Talented people are very proud about how they write their programs, and it can be an insult to propose some other way to do their work. Thus, if one has used abbreviations in programming for a long time, it may be difficult to accept the idea of natural naming.
I can tell you a personal example about the difficulties that are involved in accepting new programming styles. During the spring 2002, I started to study C# programming after having almost finished my C++ book. (C#, "see sharp", is a programming language developed by Microsoft and it is like Java in many ways.) Before starting with C#, I was accustomed to the convention that class names are capitalized (e.g. Date), whereas all other names including method names begin with a lowercase letter (e.g. search_largest_integer, searchLargestInteger). When I saw that in the C# book I was reading method names are capitalized (e.g. SearchLargestInteger), I was furious. How can they do such a thing? Writing method names with an uppercase first letter is against the tradition in C, C++, Java, etc. I almost stopped studying the C# language because of this scandalous deviation from the traditional programming style. However, as time passed, the uppercase letters in method names started to look less impossible, and I found myself at least partially accustomed to this naming style.
Based on this and other experiences, I can understand that it may be difficult to start writing character_index instead of i, command_line_parameters instead of args, bytes_from_file instead of buf, etc. When I started to use natural names in computer programs more than 15 years ago, I was very unsure whether computer programs can be written that way, and I was wondering why people do not write programs that way.
What I can recommend is that just try to use natural names
in practice. Write a small program in which you use long names, at least
two words in each name! It is difficult because you have to think about
how to name variables, methods, classes, etc. It is difficult because you
have to spend time to find the right names. But when you think while you
write a program, it is likely that you write a better program. Errors in
programs are a result of not thinking enough.