DEV Community

Discussion on: The Golden Rule of Variable Naming

Collapse
 
stepanstulov profile image
Stepan Stulov • Edited

Interesting article, but the golden rule of naming is indeed too open to interpretation.

The better of your code samples wouldn't pass our code review by at least these criteria:

  1. You have two names for the same thing: document vs. content. Should be strictly one name for one concept and one concept for one name. Unless you refer to content as part of the document, along with other parts like header etc. Let's stick with the latter hypothesis.
  2. You abbreviated document in docID. It should be documentID.
  3. You omitted certain specifics from your variable name. If you have a document, of whose content's you get a byte array of (which you will then for example deserialize into an actual instance of some class), your variable should be documentContentBytes. Same for the function: it should be GetDocumentContentBytes().

Naming things in a knowledge domain is indeed an art. One comes up with metaphors (like neural network), equivalents from real life (like network ports), completely abstract things or just funny stuff. But naming things in code is a 1-to-1 projection of your knowledge domain where you have absolutely no freedom. You just need to write it down like a disciplined lawyer, to the letter. Someone coined a term "German Naming Conventions" but I won't find the article anymore.

byte[] documentContentBytes = documentRepository.GetDocumentContentBytes(documentID);

Update: got it chrisdone.com/posts/german-naming-...