Moving from MZ-Tools 3.0 to 8.0 Part 8: The Nomenclature Rules Review

One feature that was completely missing in MZ-Tools 3.0 was a nomenclature review for the names of classes, methods, variables, constants, parameters, etc. While many teams have some kind of nomenclature standard in a Word or PDF document, it’s difficult to enforce it if you need to do it through manual reviews. MZ-Tools 8.0 introduces the Nomenclature Rules Review as part of its Quality Review feature:


The nomenclature rules are created, customized and enabled/disabled in the corresponding section of the “Options” window, “Team Options” tab, “Quality Review” > “Nomenclature Rules Review” node:

In that page you have buttons to go to the pages where you define type tags, which can be prefixes or suffixes for types, such as “s” for String, “i” for Integer, etc. and control tags, such as “cmd” for Command, or “chk” for CheckBox. Once you have defined the type and control tags you can start creating a nomenclature rule in this window:


As you can see, after an (optional) Id for the nomenclature rule and a description, the first important thing is the item to review, which can be any object or item with a “Name” property, from the project group file to a parameter:


Once selected the item to review, there are three kinds of nomenclature rules. The first one sets a convention for the name, where the convention is composed of up to two prefixes, a name with a case (upper case, lower case, Pascal case, camel case, etc.), and up to two suffixes. For example, you may want to name member fields of a class with the “m_” prefix (for “member”), followed by another prefix which is the type tag (such as “s” for string, “i” for integer, etc.):


The second kind of nomenclature rule checks that the “Name” property meets some condition. For example, that the name starts with some string, or doesn’t end with some other string, or that matches some regular expression:


The third kind of nomenclature rule is about the length of the name, since you may want to avoid very short or very long names:


You may have noticed that apart from the “What to review” tab, there are another two tabs. The second tab sets when to review the item. If you don’t set conditions, the item is always reviewed. But for example, you may want to review items of an ActiveX dll or control only when they are “Public”, since they are visible to users of your component, and you don’t care so much about “Private” or “Friend” declarations:


So, you can define conditions that are combined, and each condition is composed of a property, and operator and a value or set of values:


The third and last tab is to enter some explanation of the review, and how to fix it:


When the Nomenclature Rules Review finds violations of some nomenclature rule, it shows them in the Results toolwindow:


Each result has a context menu where you can locate the result, remove it from the list, or view the rule that has been violated:


The following window is shown with the Id, description and suggested fix (if entered when creating the rule). To view the full nomenclature rule definition you can click the “View Rule” button:


To summarize, the Nomenclature Rules Review is very customizable and allows you to create rules for any standard that you may have. It’s ideal for teams, consultants that must follow the naming standards of a client or even for individual developers that want to be consistent in their coding style.