Let’s write more CodeXM checkers (second-stage ignition)

Class names, and their members too!

Of course you’re likely to pick up on the pattern here. Following the structure we’ve now become familiar with, you would enumerate all the classes you define in your codebase like this:

for c in globalset allClasses % nonconformingClassName

where we will define what a nonconforming class name is with our own custom pattern. In all, the checker would look like this:

pattern nonconformingClassName {
  classDefinition {
    .declaredType.identifier != myProperCaseName;
  }
};

checker {
  name = "CLASS_NAMING_VIOLATION";
  reports = for c in globalset allClasses % nonconformingClassName
    :
    {
      events = [
        { description = "Class "
                      + (c.declaredType.identifier ?? "(shown here)")
                      + " does not follow naming convention for class members.";
          location = c.location;
        }
      ];
    };
};

For simplicity, we’ve just assumed that class names should be in ProperCase form; at this point you should feel comfortable replacing the reference to myProperCaseName with whatever pattern is appropriate for your own naming convention.

This takes care of class names. Next up: data members. Let’s look at how we do that:

for c in globalset allClasses:
  for mem in c.fieldList % nonconformingMemberName

That’s right—we’ve stepped up the game, going from a simple single for loop to where we now nest an inner loop (examining the field members) within the outer loop that examines all the classes.

And yes, you likely noticed that the inner one does not use the globalset keyword.

What gives?

Well, CodeXM—like Coverity in general—is designed to scale. It must be able to examine projects with a few dozen functions, or a few million. Of course, it’s expected to be able to handle either with equal ease. This demands the ability to handle sets that can become large, while other sets can safely be expected to remain in the realm of practical. Knowing which is which allows CodeXM to do smarter things when handling either. Making sure you know which is which means you don’t accidentally write a Coverity checker that won’t scale. Hence the keyword.

The chief takeaway is that you can nest loops, but only the outermost should be examining the contents of a globalset. There are ways to have a Coverity checker examine two global sets, but let’s leave that subject for another day. If you’re familiar with big-O notation or time complexity, things that are O(n2) generally don’t have great performance characteristics. CodeXM may be powerful stuff, but it can’t defy that reality.

But let’s get back to examining data members. You’ll see that the logic of the nested classes really just amounts to examining all the fields (nonstatic data members) of all the classes in your project. The set-filtering which-are operator, %, is used to identify any fields that don’t conform to the established naming convention.

But wait, what about static data members?

No surprises here. It would be a separate loop, like this:

for c in globalset allClasses:
    for mem in c.staticFieldList  % nonconformingStaticMemberName

Couldn’t that be folded into the same checker? Maybe, but that could complicate things if you have separate rules to apply to each, or want to tailor the resulting event messages. In general, it’s frequently more efficient (and productive) to define stand-alone checkers with minimal decision logic.

In the big reveal, here are the checkers we described above, plus the patterns we defined to support them.

pattern nonconformingClassName {
  classDefinition {
    .declaredType.identifier != ProperCaseName;
  }
};

checker {
  name = "CLASS_NAMING_VIOLATION";
  reports = for c in globalset allClasses % nonconformingClassName
    :
    {
      events = [
        { description = "Class "
                      + (c.declaredType.identifier ?? "(shown here)")
                      + " does not follow naming convention for class members.";
          location = c.location;
        }
      ];
    };
};

pattern nonconformingMemberName
{
  fieldSymbol {     // expect members to be prefixed with m_ and be camelCase
    .identifier     != Regex("^m_[a-z][a-z0-9]*([A-Z][a-z0-9]*)*$")
  }
};

pattern nonconformingStaticMemberName
{
  fieldSymbol {     // as nonstatic members, but prefixed with ms_
    .identifier     != Regex("^ms_[A-Z][a-z0-9]*([A-Z][a-z0-9]*)*$")
  }
};

checker {
  name = "CLASS_MEMBER_NAMING_VIOLATION";
  reports = for c in globalset allClasses:
              for mem in c.fieldList  % nonconformingMemberName
    :
    {
      events = [
        { description = "Class member"
                      + mem
                      + " does not follow naming convention for class members.";
          location = mem.location;
        }
      ];
    };
};

checker {
  name = "CLASS_STATIC_MEMBER_NAMING_VIOLATION";
  reports = for c in globalset allClasses:
              for mem in c.staticFieldList  % nonconformingStaticMemberName
    :
    {
      events = [
        { description = "Static class member "
                      + mem
                      + " does not follow naming convention for static members.";
          location = mem.location;
        }
      ];
    };
};

Orbit achieved. We’ll consider this assignment complete; where you take this next is up to you. As we’ve seen, most of these checkers look remarkably similar, just varying in the things we examine and the messages we report when we find something of interest. (And to be honest, most simple checkers will look very much like this.) More sophisticated checkers are possible and will use more elements of the language that we haven’t covered so far. Yes, there is more you can learn about CodeXM, but as you see, even with these little bits, there’s quite a bit possible.

If all this naming-convention stuff is too much far-fetched pie-in-the-sky, maybe you’d like something a little more down-to-earth.

Pasta, anyone?