In my blog post, My programming setup, I stressed how important regular expressions are to my programming activities.
Regular expressions can look intimidating and outright ugly. However, they should not be underestimated.
Someone asked for examples of regular expressions that I rely upon. Here a few.
- It is commonly considered a faux pas to include ‘trailing white space’ in code. That is, your lines should end with the line-return control characters and nothing else. In a regular expression, the end of the string (or line) is marked by the ‘$’ symbol, and a white-space can be indicated with ‘\s’, and a sequence of one or more white space is ‘\s+’. Thus if I search for ‘\s+$‘, I will locate all offending lines.
- It is often best to avoid non-ASCII characters in source code. Indeed, in some cases, there is no standard way to tell the compiler about your character encoding, so non-ASCII might trigger problems. To check all non-ASCII characters, you may do [^\x00-\x7F].
- Sometimes you insert too many spaces between a variable or an operator. Multiple spaces are fine at the start of a line, since they can be used for indentation, but other repeated spaces are usually in error. You can check for them with the expression \b\s{2,}. The \b indicate a word boundary.
- I use spaces to indent my code, but I always use an even number of spaces (2, 4, 8, etc.). Yet I might get it wrong and insert an odd number of spaces in some places. To detect these cases, I use the expression ^(\s\s)*\s[^\s]. To delete the extra space, I can select it with look-ahead and look-behind expressions such as (?<=^(\s\s)*)\s(?=[^\s]).
- I do not want a space after the opening parenthesis nor before the closing parenthesis. I can check for such a case with (\(\s|\s\)). If I want to remove the spaces, I can detect them with a look-behind expression such as (?<=\()\s.
- Suppose that I want to identify all instances of a variable, I can search for \bmyname\b. By using word boundaries, I ensure that I do not catch instances of the string inside other functions or variable names. Similarly, if I want to select all variable that end with some expression, I can do it with an expression like \b\w*myname\b.
The great thing with regular expressions is how widely applicable they are.
Many of my examples have to do with code reformatting. Some people wonder why I do not simply use code reformatters. I do use such tools all of the time, but they are not always a good option. If you are going to work with other people who have other preferences regarding code formatting, you do not want to trigger hundreds of formatting changes just to contribute a new function. It is a major faux pas to do so. Hence you often need to keep your reformatting in check.
You might like prettier: https://prettier.io.
It handles all this and more automatically for you, for almost every language. It’s like magic.
As I understand the idea of the article is to helps and teach useful regular expressions and uses code formatting as an example.
Assuming that most of your research is done in C or C++, I wonder why you’re not considering using clang-format for these tasks as regular expressions will only get you so far?
I program using a wide range of programming languages, including C and C++. I do use clang-format and other code reformatters.
Nice tips. You can use
\Sinstead of[^\s]to shorten some of these.I think you’ve got an extra
<in there, unless that’s some sort of new metacharacter.This is probably the desired behaviour, but just to note,
\swill also match newlines. If you wanted to preserve those, you could use[ \t]instead.Your use of lookbehind & lookahead is interesting. When I’m doing search-and-replace on code, I always include the prefix and suffix in capturing groups and account for those in the replacement.
…on further consideration, that’s probably because I’m doing it in Emacs, whose native regex engine is rather primitive.
It depends on whether the regular expression is applied to the whole documents or to lines. Many editors match regular expressions on a line-by-line basis by default.
Oh, my mistake! I don’t think I’ve ever used one like that. Thanks, learnt something new. 😊
Your habit to use capture groups instead of lookarounds is good. A lot of regex engines don’t support variable-length lookarounds.
These are some really useful regular expressions. I use some all the time, but I used your blog as an opportunity to delete all the annoying trailing spaces in our code base (like really, who does that?).