Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Are there any common practises for commenting the regular expressions: inline comments referring different part of RegEx or general comment for all expression?

share|improve this question
2  
There are but you need to be more specific. For example Bash supports inline comments and Python offers verbose regular expressions. –  faif Dec 5 '12 at 12:19
6  
My rule of thumb for regular expressions is: if you need to comment the regular expression, it's too complicated. –  zzzzBov Dec 5 '12 at 15:43
1  
And always include this link: regexcrossword.com –  Kieveli Apr 22 at 12:45
    
I don't necessarily agree that if you have to comment it, it's too complicated. A complicated regex can still save you tons of eye-glazing imperative code. Use a good descriptive variable name to assign the regex to. If it still isn't clear enough, use a brief comment to convey the original intent behind the regular expression. –  Craig Apr 22 at 16:47

6 Answers 6

up vote 8 down vote accepted
+100

In my view, a good practice is to concisely state in comments what the general idea of the regular expression is. This saves other developers (or sometimes yourself) the hassle of copy-pasting the regex in a parser like RegExr, only to understand what it does.

share|improve this answer
2  
RegExr will happen anyway, unless the dev is a regex savant. But I agree with providing a general description; that's what I do with my regexes. –  Robert Harvey Dec 5 '12 at 16:22
2  
+1: Anything more detailed will end up being a crash course in regex as a comment. –  Matt Dec 5 '12 at 19:11
    
This answer and the @zzzzBov comments make sense. –  m0nhawk Dec 8 '12 at 12:44
    
Not only does it save the hassle of tedious examination of the regular expression to understand it, but it makes the intent of the original programmer clear, especially given the distinct possibility that the original programmer got the regular expression itself wrong the firs time 'round. Having said that, in a lot of cases assigning the regex to a good variable name can count a long way toward providing adequate documentation of intent. –  Craig Apr 22 at 16:44

Typically, I will write a regex and not explain the individual pieces of the regex, but rather what it's purpose is. That is that what and why. This is a bit like asking "What should my comments look like?" to which one would say "Don't write what the code is doing, write why the code is doing what it does"

// Strip the leading "?" and remove the query parameters "offset=<integer>" & "count=<integer> so we have a pattern of the request"          
var search = location.search.substring(1).replace(/offset=[0-9]+?&/g, "").replace(/count=[0-9]+?&/g, "");

Unless you are trying to teach someone about regexes via comments in code, I don't think explaining what each individual piece will do. When working with other programmers, you can safely assume that one would know something as global regular expressions.

share|improve this answer
3  
you would be surprised... –  Matt Dec 5 '12 at 18:55

I guess it really depends on how you're putting the regex together. Generally speaking I think it would be a bad idea to put comments within the actual regex string itself (not possible in most scenarios, as far as I know). If you really need to comment specific portions of a regular expression (are you trying to teach someone?), then break each chunk into separate strings on their own lines, and comment each line using the normal commenting process for your programming language. Otherwise, pleinolijf's answer is pretty good.

example:

string myregex = "\s" // Match any whitespace once
+ "\n"  // Match one newline character
+ "[a-zA-Z]";  // Match any letter
share|improve this answer

This is somewhat a language specific answer, but no language is stated in the question.

The book "Dive Into Python" suggests implementing comments using Verbose Regular Expressions:

Python allows you to do this with something called verbose regular expressions. A verbose regular expression is different from a compact regular expression in two ways:

  • Whitespace is ignored. Spaces, tabs, and carriage returns are not matched as spaces, tabs, and carriage returns. They're not matched at all. (If you want to match a space in a verbose regular expression, you'll need to escape it by putting a backslash in front of it.)
  • Comments are ignored. A comment in a verbose regular expression is just like a comment in Python code: it starts with a # character and goes until the end of the line. In this case it's a comment within a multi-line string instead of within your source code, but it works the same way.

Example:

>>> pattern = """
^                   # beginning of string
M{0,4}              # thousands - 0 to 4 M's
(CM|CD|D?C{0,3})    # hundreds - 900 (CM), 400 (CD), 0-300 (0 to 3 C's),
                    #            or 500-800 (D, followed by 0 to 3 C's)
(XC|XL|L?X{0,3})    # tens - 90 (XC), 40 (XL), 0-30 (0 to 3 X's),
                    #        or 50-80 (L, followed by 0 to 3 X's)
(IX|IV|V?I{0,3})    # ones - 9 (IX), 4 (IV), 0-3 (0 to 3 I's),
                    #        or 5-8 (V, followed by 0 to 3 I's)
$                   # end of string
"""
>>> re.search(pattern, 'M', re.VERBOSE)                1

Source and further details here

This method has a slight disadvantage that the caller must know that the pattern is written in a verbose format and call it accordingly.

share|improve this answer

I usually define a string constant whose name describes the overall purpose of the regular expression.

For example:

const string FloatingPointNumberPattern = @"[-+]?[0-9]*\.?[0-9]+";

You could add a comment above this constant to give it a description, but usually the constant name itself should be enough.

share|improve this answer
1  
One extra thing I like about this answer is that if it gets used in more than one spot, the intent has to be carried around too - no forgetting to comment it. –  J Trana Apr 24 at 4:28

Comments should add useful information that is not obvious from the code.

  1. Make it easy to understand what the expression is supposed to do at a requirements level, either in the code itself or in a comment. What is the intent behind the expression, is it to validate email addresses or pick out Canadian phone numbers.
  2. Make it easy to understand what the expression is actually doing, i.e. what the expression evaluates to. First try to make it clear by splitting up the expression, if you first check for all hyphens then remove all numbers then make that a two part expression with variables holding the intermediary values, it will make it much easier to read and the reader will be able to step through your logic one step at a time. (There is a famous answer to a question on SE where someone is trying to decipher some old code which involves bit manipulation '>>' and finding out if certain flags are set where the answer lays out not only what the code really does but how the question's authour should go about deconstructing this kind of code in the future which is exactly what I am trying to describe but I can't seem to find the question to link to)

There are few applications that need every last cycle, if you are pattern matching massive data sets then maybe there is a better way, maybe not, but for most things the extra execution time is not that big a deal.

And remember the next person to come across your code and fix a bug might be you in six months time and there is no way you are going to remember what it was supposed to do.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.