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 concerns 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.

Best Practices for Regular Expressions

The vast majority of these rules is 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

New Public Product Roadmap – See What's In Store For Q1

We’re excited to release a public product roadmap for 2020.  Now, those outside Codacy can see what our team is working on...

4 Trends To Boost Software Quality in 2020

Today’s abundance of technology has created an increased demand for higher software quality. With companies aware of this, spending on IT worldwide...

7 Reasons Dev Teams Choose Codacy Over Other Automated Code Review Tools

Today more than 100,000 developers at leading global organizations like PayPal and Adobe across industries use Codacy (read customer case studies). ...

Introducing GitHub Sync For Seamless User Management

Announcing GitHub Sync: Synced Organizations For GitHub We are thrilled to announce "GitHub Sync" -- automatic user and repository...

Ringing In 2020 With Codacy

It’s been an exciting 2019 at Codacy and we expect more excitement in 2020. Over the last 12 months we’ve built out...