The Art of Code

Going through an entire compile / debug cycle only to find that a Regex is not behaving as intended is not a good use of a developer’s time (well, it’s not a good use of my time anyway). There is a better way.

The Problems with Regex

Regex, or regular expressions, represents a formal language that provides an extremely concise way to parse strings of text. To be honest, there are no problems with Regex itself. The problem is you need a Ph.D. to understand it. Ok, maybe it’s not quite that difficult, but the syntax can be annoying to say the least. It may appeal to some, but I imagine these as diehard coders who would prefer to write novels in assembler. I would, however, hazard to guess that the conciseness of a Regex is very appealing to almost anyone whose alternative is to write lines and lines of string parsing code.

Test Regex Outside of Debug Cycle

Since Regex can be interpreted by any regular expression processor,  regular expressions in your code can be tested outside of your code, and before you ever compile. It’s ideal, in my opinion, to test and validate specific regular expressions as part of the development process, as opposed to relying on the (unit) testing process. Don’t get me wrong, my regular expressions would still be tested indirectly as past of my unit tests, but I don’t want to endure multiple compile cycles as I debug the regular expressions themselves. Here are a couple of alternatives:

1. Testing Online: JavaScript 1.2 and later has built-in support for regular expressions. There are a number of excellent expression processors that take advantage of this support. For example, this Regular Expression Tester.
2. Testing within the IDE: If online is not your sort of thing, maybe something built into your IDE would work better. For Visual Studio, you can use the Regular Expression Explorer addin.