SSW Code Auditor > Regular Expression Rule Tutorial

  1. The boss has told us that we need to have a rule for the naming of all Boolean properties in our code.
    For a Boolean property, its name must begin with a verb - otherwise the meaning of the property is very confusing.

    Let's create our rule.  In Code Auditor, select a job and click on the Add Rules
     
  2. Give the rule a name.

    Figure: Adding a new rule
     
  3. Edit the Rule, and give it a Note explaining what this rule should do.

    Figure: Editing the rule
     
  4. We want to search for our particular rule in all C# files.  So select the "Search In:" criteria and select *.cs
    The easiest way to start creating your rule is to write down the pattern that you want to match.  So we'll put that in as well.

    Select "should exist" in "file contents".


    Figure: Search-In file type, and start writing our RegEx pattern
     
  5. We head over to the "Test" tab.  Let's create some test cases so we can check our pattern.

    Figure: Error in Regex Analyzer

    One of the first thing we should see is that the Regex Analyzer is complaining about something in the pattern.
    Looks like we forgot to escape the { and } characters.  (These are special characters in RegEx.  So we need to escape them by prefixing them with a backslash \ character).

    Our pattern should now be:

    bool IsEnabled \{\}

    See Also: MSDN: Regular Expression Language Elements You are going to a site outside of SSW, MSDN: Character Escapes You are going to a site outside of SSW
     
  6. So head back to Search tab, add our backspaces and come back.  Let's add our test cases.
    We create the following Test Case:

    bool IsEnabled {}


    Figure: Creating a Test Case for this pattern

    Press the Test button.  You should see:

    Figure: Pass our first pattern!

    Select the radio button for "Should Pass", as this Test Case is a good one.
     
  7. Create a few more test case:

    bool
    IsEnabled
    {
    }

    bool IsEnabled {
        return true;
    }


    Figure: Our pattern fail on the two new test cases
     
  8. Let's go back and fix our RegEx pattern in the Search tab.

    The 2nd test case failed because our Pattern doesn't allow extra spaces, or new lines between the code keywords.  So we modify the pattern and replace all the " " (space) with \s+ (one or more whitespace characters)

    bool\s+IsEnabled\s+\{\}

    The 3rd test case failed because we have some code in the property code block (between { and }) and our pattern wasn't prepared to see what's inside.  Since we still don't really care what's in side, we'll just match anything.

    Match everything by the pattern .*  (0 or more of any character).

    bool\s+IsEnabled\s+\{.*\}

    See Also: MSDN: Character Classes You are going to a site outside of SSW

    Because our pattern goes across multiple lines, we need to configure a special RegEx option that allows the . (any character) to match carriage return character as well.  This particular option is called Singleline option, and can be set with the syntax (?s: ) 

    Our resulting pattern should look like:

    (?s:bool\s+IsEnabled\s+{.*})

    See Also: MSDN: Misc. Constructs You are going to a site outside of SSW


    Figure: All our test cases passes now!
     
  9. Back to test tab.  Add this new test case:

    bool HasXFunctionality
    {
        return true;
    }

    So far, our pattern only matches IsEnabled for the property name.  We want it to match anything that looks like IsXXX and HasXXX.
    First, we separate the Is/Has from the later word.  Using the Or-construct (|)

    (?s:bool\s+(Is|Has)Enabled\s+{.*})

    See Also: MSDN: Alternate Constructs You are going to a site outside of SSW

    Then we replace the name of the property with any possible word.  There's a special character class in RegEx for any alphanumeric character.  \w (means word-class).

    (?s:bool\s+(Is|Has)\w+\s+{.*})


    Figure: Pass on our 4th test case
     
  10. This is all good.  But currently Code Auditor is only telling us the files that are correct.  This information isn't very useful.  Because what we need to know, are the files that are NOT correct.

    First let's add a test case that is supposed to fail.

    bool NoVerbProperty {}

    Remember to select "Should Fail" for this test case.

    Figure: A new test case that should fail
     
  11. Need to modify the pattern.

    There is an advanced syntax here.  The pattern (?! )
    This pattern is a Negative Look-Ahead pattern.  It means that if we match this pattern, then fail immediately the current test without further testing.

    (?s:bool\s+(?!Is|Has)\w+\s+{.*})

    See Also: MSDN: Grouping Constructs You are going to a site outside of SSW

    We also need to toggle the files we want to report back: Select "Should Not Exist" instead of "Should Exist"


    Figure: The modified rule.
     
  12. A quick update to improve our rule.
    In C# there is a syntax for default indexer property.  It looks like this:

    bool property[] {}

    Let's modify the pattern slightly further to allow for the optional [ and ].
    Because these two are special characters, we need to prefix with the escape character \ to make \[ and \]
    They are optional, so put them in a group (\[\]) and use the ? quantifier (which means 0 or 1 occurance).
    Allow for some space between the property name and the [ ].  \s*

    (?s:bool\s+(?!Is|Has)\w+\s*(\[\])?\s+{.*})

    Add two more test cases as well.

    bool IsOk [] {}
    bool NotOK [] {}
     
  13. Our final results

    Figure: The rule pattern


    Figure: The test cases