Code patterns allow you to search for specific snippets within program source code or other files.
A code pattern's options are described in detail below.
A summary of what the code pattern is checking. Shown to users if test is shared.
The Ruby regular expression to search for.
The specific file(s) (relative to
/home/nt-user/workspace) to search. Supports file globs. Defaults to all files (
Optionally add some text to test your regular expression with.
A list of matches found.
If the results from the code pattern should be shared with the user.
If the regular expression should be case sensitive.
If disabled, the code pattern will pass when the pattern is NOT present in the code.
In the above example we have 1 task, comprised of 3 code patterns, one of which failed. When the check is expanded the code pattern is shown to the user. Code patterns are regex expressions that can become very complex!
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]...(and that is only the first line!).
Code patterns can often be avoided by using unit tests or test cases to check the end result instead of the implementation.
In the example above, the code pattern is displayed to the user, it is important that the user understand what the test is doing. In most cases, it is unlikely that a student will know what a regex is or what it is trying to do. This is why task and check titles should be descriptive, eg. “Declared
humidityPercentage as an optional”.
Code patterns can be used to test that patterns are not present as well, they will pass when something is not detected, this is useful for detecting patterns that should not be found in code, but have the adverse effect of passing with starter code.