Home Developer Regular Expressions: Best Practices

Regular Expressions: Best Practices

Author

Date

Category

Pretty much every main programming language supports Regular Expressions, and many static analysis tools have patterns that relate to regular expressions.

So before you look, tell us: would you expect these patterns to be the same from language to language? Totally different?

Here’s what I found:

Ruby

Starting with Ruby, we can easily find two patterns from two different tools:

The first one refers to a possible ambiguity where the usage of parentheses removes said ambiguity.

The second one is a ReDOS vulnerability derived from using user-controlled input in a regular expression.

So far, so good; they both make sense.

(you can find more about Ruby Static Analysis tools in this post)

JavaScript

In a completely different environment, we can also find regular expression rules in ESLint:

So what are they?

The first three refer to possible typos; the fourth one suggests the usage of

var re = /foo {3}bar/;

instead of:

var re = /foo   bar/;

(seriously, can you immediately tell how many spaces are there?)

The two last ones are to remove ambiguity of the slash character in certain cases (in /=foo/, is /= the beginning of a regular expression or the division operator?)

So we’re basically looking for typos, removing ambiguity and making a regular expression easier to read (hopefully).

Java

Let’s look at the Java patterns:

Here we find invalid syntax, a problem with using File.separator on a regular expression, the possible typo of using . or | as a regular expression in a string function (such as split, for instance) and, again, a ReDOS vulnerability.

(you can find more about Java Static Analysis tools in this post)

Perl

It’s hard to talk about regular expressions without mentioning Perl.

Here are some regular expression patterns from Perl::Critic:

Right away, you see there are more patterns here than for the other languages in this post (in fact, there are more rules here than in the other languages combined).

While the first of these rules concern a possible problem in the code, the vast majority of them are, in fact, related to readability, with some of them also touching performance issues (single char alternation and unused captures, for instance).

It’s also interesting to note that the last three refer to the usage of the /s, /x and /m modifiers, also for the sake of clarity. You can read more about these modifiers on Perl’s documentation, but for brevity:

  • /s makes . also match n
  • /x makes whitespace allowed in a regular expression
  • /m, with a multiline string, makes ^ and $ match the start and end of each line, and not just the string’s

If you’re looking to see what a badly concocted regular expression might look like (as if you’ve never seen one before), here’s an example that breaks 7 of these rules (we’re looking for two slashes followed by an alphanumeric character and a digit 1 or 2):

m#//([A-Za-z0-9_])(1|2)#;

This expression uses the # character as a delimiter, captures groups that are never used (trust us, we didn’t use them), alternates two chars instead of putting them in a class and disregards the existence of the w named character class using a verbose version of it instead; all that, of course, combined with the absence of the three recommended modifiers.

A much cleaner version of this expression would be:

m{ //w[12] }sxm;

All the problems have now been solved, and, let’s face it, the expression is much easier on the eyes.

If you just start using regular expressions in Perl, this cheat sheet can greatly help you. It contains the different classes, characters, and modifiers used in the regular expression, with explanations.

Best Practices for Regular Expressions

The vast majority of these rules are connected to four different things:

  • readability
  • performance
  • possible typos
  • ReDOS vulnerabilities

Learning about these rules will help you write better regular expressions.

Oddly, and while some patterns are present for different languages, many aren’t; in some cases, it makes sense, as they refer to intricacies of the languages; in others, it might just be that there’s not enough demand for them or, perhaps, it could be just a matter of time until someone implements them.

In any case, and regardless of the language(s) you’re using, it is highly recommended that you use a static analysis tool in your code to improve it and prevent these and other problems; or, better still, to have a tool that combines the advantages of different tools without disrupting your workflow, such as Codacy.


Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!


About Codacy

Codacy is used by thousands of developers to analyze billions of lines of code every day!

Getting started is easy – and free! Just use your  GitHub, Bitbucket or Google account to sign up.

GET STARTED

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Subscribe to our newsletter

To be updated with all the latest news, offers and special announcements.

Recent posts

Code reviews in large-scale projects: best practices for managers

Managing code reviews for large-scale projects can be challenging, as the volume and complexity of the code might seem overwhelming. However,...

Now live: introducing Coverage summary on your Git provider!

You spoke; we listened! We’re very excited to announce you can now see the Coverage summary directly on GitHub as a...

Top mistakes your dev team makes when performing code reviews

Code reviews are an essential part of any software development process and are crucial for improving code quality. However, despite their...

Codacy Pulse now supports Bitbucket integration

We're very excited to announce that Codacy Pulse now supports Bitbucket integration! You can collect changes and deployment data from Bitbucket...

Tips for implementing DORA metrics and how Pulse can help

DORA (DevOps Research and Assessment) metrics are a powerful way to measure the performance of software delivery organizations. By tracking key...