JavaScript knows two ways to construct regular expressions. One way is the constructor of the RegExp object. E.g.

1
2
3
4

var r = new RegExp('abra');
if ("abracadabra".match(r)) {
    console.log("positive match");
}

The other way is via a literal regular expression syntax. E.g.

1
2
3
4

var r = /abra/;
if ("abracadabra".match(r)) {
    console.log("positive match");
}

I recently developed a strong preference for new RegExp(). The reason was found in a bug I recently solved with a coworker.

While working on a Grails application we were sending a Model to populate a View. On this View a property of the model was used to create a regular expression with. This was achieved with code simlar to the example below

1
2
3
4
5
6
7
8
9
10
11

(function(){
    var Account = {};

    ...

    Account.validator = createValidatorFrom(/${model.regexp}/);

    ...

    window.Account = Account;
})()

In this case model.regexp is used to create a regular expression that is passed into the createValidatorFrom JavaScript method. So far so good.

But what happens if the model.regexp is null? Then the ${model.regexp} will collapse to the empty string rending the JavaScript snippet invalid. The reason being that the literal regular expression accidently got turned into a single line comment hiding the closing bracket.

1
2
3
4
5
6
7
8
9
10
11

(function(){
    var Account = {};

    ...

    Account.validator = createValidatorFrom(//);

    ...

    window.Account = Account;
})()

If the new RegExp() constructor was used this would not become a problem. The constructor accepts a string. No slash-delimiter could be turned into a single line comment by accident.

Having said that, care should still be taken when working with regular expressions. Character classes like \d or \s tend to be interpreted in JavaScript string, causing problems of their own.