Regex Hero Blog

Regular expressions are powerful.  There's no doubt about it.  The .NET and Perl-derived implementations in particular are rich and capable. For the most part regular expressions are there to save you time from parsing text the hard way.  But if you're spending more time bending regular expressions to your will to accomplish something that could be done more easily and efficiently with procedural code, then that kind of defeats the purpose. I've wanted to write this article for awhile.  Then today I stumbled across this StackOverflow question  which is a prime example where the procedural solution was actually quicker & easier to write, more understandable, and more efficient.  Your ability to identify these situations will improve naturally with experience.  But I thought I'd list a few good & bad scenarios for regular expressions... Good Data validation can be done easily and concisely with regular expressions in most cases. Good Syntax highlightin

Regex Analyzer Regular expressions are one of those things that many programmers dabble with enough to understand the concept, but not enough to memorize the syntax. Code completion is a big step towards making things easier. Beyond that, sometimes an explanation written out in English is just what you need. The new "Regex Analyzer" feature actually uses my existing parsing engine that I used for code completion to step through the regular expression and build a tree which explains, in English, every construct.  When you click a line in the explanation box, it'll highlight the corresponding section of the regular expression. This feature is only available in  Regex Hero Professional . By the way, in addition to this feature, there have been a few more improvements in today's release... Added a new menu with icons underneath the existing file menu for easy one-click access to common features. Moved the spot where the open & save dialogs and all of t

The benchmarking feature has always had a couple of shortcomings. It covered up the lower-half of the application as you used it. You couldn't easily revert back to the best performing regular expression.  Or you had to rely on your memory to know what performed best. Well I think I managed to come up with a pretty good solution for both problems.  First, you'll notice that the benchmarking feature now sits in its own panel below the rest of the UI.  If your screen resolution isn't high enough there will be a vertical scroll bar so you can still scroll to see everything. And then to solve the second problem I knew I needed to make some bigger changes.  I realized that a configurable number of iterations was adding unnecessary complexity.  Instead I simply run the benchmark for one second.  And now we can rely solely on the iterations per second figure.  And then I decided to go the bar graph route.  Each time you hit "Start" to run a benchmark, a new bar is ad