Descriptive naming

It is surprising to see great programmers choose misleading names for concepts in their writings while advocating descriptive names in computer programs.

One speculation is that authors enjoy playing with analogies that make sense to them. One such name makes sense to the namer, sticks in their mind, and provides a sense of ownership. Unfortunately, all these criteria are serving the author as opposed to the reader.

Another speculation is that the namer is well aware of the mismatch (between the name and the target concept) but he thinks it is fine: “the reader has been reading my book so he has got to understand what I mean by x.” This is okay for fiction, but it is problematic in technical essays. The problem emerges when that name starts to get a life outside the book. You start to hear the name everywhere, but the name (without the context provided by the book) does not make sense. You read the descriptions for that concept and the literal definitions for the name, but the mismatch just adds up to the confusion. Even if you read an accurate description of the concept, you do not believe it: you suspect that it is incorrect or incomplete because it does not match the name. And you would be right. Because a concept description that does not provide an etymology for the name is incomplete. You probably have to read the original book to see for yourself that the namer was being almost arbitrarily playful while choosing that name.

I am not going to include the unprofessional and unacceptable “just to sound smart” reason in my speculations. Even if I am wrong, I prefer to presume that these writers are professional and that they prioritize the good of the community over personal myopic gains.

If you have a large audience, it is your professional responsibility to use descriptive words for concept names. An easy workaround is to ask for an outside opinion.