Logo

Naming Conventions

Hungarian notation

A brilliant programmer at Microsoft, Charles Simonyi, more or less invented the Hungarian Notation. The idea probably was oriented around the idea that a name had to carry additional information such as type of variable, size of variable, how it might be used. I've never favored this notation as it seemed to me to get in the way of reading each statment. It also tends to lengthen the names.

Names

So things should be nouns. Actions should be verbs. Attributes could be adjectives or nouns. I grew up in this business when name had restricted lengths by virtue of the programming language. So short names were required. This led to the map method of converting long names to short names. If I recall it correctly the map method takes a long name and removes characters from the end first and removes vowels before consonants. We used that for years to make almost readable names from longer spellings.

Now I've noticed that names can be any reasonable length, some 50 characters long to spell out some complicated information. Yuk. I want to use the line to convey some useful information about what is going on (which is usually not carried in a single name). So less abbreviation but still meaningful names that are not too long.

One Rule for Names

Ok, I do have one sort of rule, suggestion, leaning... In multiple word names that define something (abbreviated or not) each word (or abbreviation) is Capitalized (e.g. MyClass). Names that define something are capitalized. Class names are capitalized. Typedefs are capitalized. Static constants are capitalized. Things that are objects or variables, i.e. single things, are not capitalized (e.g. myClass). Here are some examples:

class MyClass;
typedef IterT<MyClass, MyDatum> MCIter;    // defines something --Capitalized

class MyClass {                            // class -- Capitalizaed
  o o o
  };

static MyKeyString TCchar* = _T("KeyString");   // static object -- Capitalized

MyClass myClass;               // object -- not capitalized
MCIter  iter(MyClass);         // not capitalized

// In the middle of a function somewhere:

  iniFile.write(Section, MyKeyString, _T("Data sent to AppName.ini file"));

Names Within Functions

Since a function is all visible in the editor, the quality of the name is less important. So here are some conventions for intermediate variables used temporarily:

  • i, j, k -- array indexes, usually integers (i.e. int) but could be a larger version
  • p, q, r -- pointers to something spelled out in the list of local variables
  • s, stg, t, cs -- strings s and t are my String class and cs is either CString or Cstring
  • ch, tch -- a single character, an UniCode character

Other variables in functions are given names and appear in the list of local varialbes right after the function definition.

Names in Classes

Tough topic and I'll return to that when I talk about classes, objects and Objected Oriented Programming (a highfalutin title if I ever heard one). But I grew up developing packages (files with a single purpose) back before Ada and OOP came along. I don't build compilcated classes (for the most part) now but I think of them as Objects instead of packages.

Classes define things or multi-part procedures so the names of Classes should reflect to kind of thing it defines. I don't know how to define how I come up with names but I can tell you that sometimes I start with one name and over time as I learn more about the class and what it should be doing for the program I rename it and also rename some of its internal functions (methods in OOP speak).

Mostly classes define some primitive data structure to be some higher form of existance in the program. So the names given to the elements reflect the nature of an operation on the data or some attribute of the data. In some cases the name allows a restricted view of the actual data (with or without the ability to change the data). I have some pet names for some of the operations, attributes and viewing functions that I'll talk about later.