How do you feel about regex?

I like it but I tend to tell people to avoid it if possible just because it makes code hard to read.

If people on the team do use regex I ask them to include a link to regexper.com/ in a comment.

It generates a flow chart like this one.

// https://regexper.com/#%2F%5E%5Cw%2B%28%5B-%2B.'%5D%5Cw%2B%29*%40%5Cw%2B%28%5B-.%5D%5Cw%2B%29*%5C.%5Cw%2B%28%5B-.%5D%5Cw%2B%29*%24%2F
const emailReg = new RegExp(/^\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$/);
console.log(emailReg.test('user@place.com'))

I don't write regex. I look up what I need to when I need it and I never think about it again. 🤣

I've found that the specificity of what I need when I do need it can vary so vastly, and that the library for it is so large, that the best use of my time is figuring out what I need at that specific moment and moving on.

It's not needed often enough to warrant full deep dive into it, for me at least.

You write a regex and don't write a comment next to it describing what it does, you and I gonna have a lil' chat ;)

I love using regular expressions. And try to adopt the following pattern:

1. Write a method for evaluating the regular expression.
2. Bombard that method with tests, both matching and non-matching cases.
3. Profit!

Regular expressions can be quite dense to read, so I want to use the tests to highlight my expectations around what I wrote.

I am what you might call an ocassional developer. As an author, I created an app that helps me convert my work to ePub format.

One of the requirements with ePub is that you output all your files to xHTML. However, the output from my word processing software (Microsoft Word) outputs to some very haphazardly developed HTML that is not xHTML compliant.

I found a whole bunch of libraries that allow me to manipulate the output to xHTML, but in fact they did not do many of the things required to pass basic specifications. Specifically, in xHTML, tags must be lowercase. All of the libraries I worked with at the time made broad assumptions about the HTML structure and worse, did not do the basic conversion from uppercase tags to lowercase tags.

After spending way too much time dealing with this, I paid a developer to figure out the problem. One day later, he delivered three lines of regex code that handled the uppercase to lowercase issue and two other problems I was dealing with. Nearly a month of work and me trying to understand how all these libraries work and sudenly I had working code. My books are thousands of pages long and broken up into dozens of files. The regex code worked great everytime.

Having not known about regex until that moment, I went about using it everywhere. I used it when my XML output was not correct. I used it to fix the file output where special characters should be renamed with escape codes and much more.

I am willing to bet that while my code technically works, all that regex is probably a bad idea. Also, regex is not easy to read, so you really have to document it well.

Overall, I really do not like the structure because of it being hard to read, but will say that without it, I probably would have just tossed my app into the trash bin had I spent two more weeks on something as simple as fixing uppercase and lowercase letters along with a few edge case issues.

The drive to complete my app drove me to use regex in areas I probably should not have used it. For example, I used regex to modify some XML files and since I did not really know XML that well, I simply gave up learning it. Instead, I used the XML output from a library and then modified the file with REGEX. Really, I should have sat down and learned XML a little more.

Regex feels like one of those things we all refer to as monolith applications. It seems like you can do anything and everything with it, but the complexities in how you write proper regex and then create test cases all feels very convoluted. At the same time, there is something very tantalizing about 1-3 lines of regex code that would otherwise require customizing libraries, creating a custom API, or doing something else to solve some basic problems.

I am curious, do we know if there are alternatives that are easier to understand and use?

Works great in my terminal and editor. I can search for something till it looks right, then replace it with what i want.

It production code its so hard to see all the edge cases. As a Data Engineer performance is about last on my list of metrics, as most of what I do is run on a schedule, not when someone clicks it, so an extra 5s on a 10 minute run is no big deal. With that said every time I see a regex in a code review I ask can we do this without a regex, even with a huge performance hit, or write tests for every possible edge case we can brainstorm.

I haven't used the x modifier before, and just did some looking and I found it initially harder to read. But I could see it as a boon for other folks, and could acclimate to reading regex with comments.

What's the alternative? Just curious. I use REs when I need REs, and when I need one it's because the alternative seems to be to write a whole string parser or some clunky seriously code-verbose combination for finds, splits, replaces, etc that is even harder to read that an regex.

But then I guess I grew up with REs and have no real issue with them. Be nice if advanced RE syntax had evolved a little more standardly and didn't diverge into flavours, which it did but hey.

I think they are great. They don't work in all situations.

ultrapico.com/expresso.htm is for .Net and a great tool for creating regex expressions, it doesn't support all elements of regex. Am not a super genius on them but they are an essential element of development for me when handling information.

Here is an example of configuration from a translation file from my application which is an awesome DevOps Deployment application am hoping to market in future.

The configuration below is to either find a value or a regex expression in an input file (typically itself an application configuration file) to clean a development configuration file. Sounds complex, but a great way of translating source configuration into something generic for different environmental deployment.

Regexes provides more control, but aren't always the best approach.

inforhino.co.uk/beta/automation-an...

                        {"IsRegex": false, "FindValue" : "C:\\\\InfoRhino\\\\cms\\\\IRWebsite\\\\IRWebsiteCMS\\\\wwwroot\\\\ClientConfiguration\\\\TConfigType.json", "ReplacementValue" : "{TargetServerRoot}\\\\ClientConfiguration\\\\TConfigType.json"}
                        ,
                        {"IsRegex": false, "FindValue" : "C:\\\\InfoRhino\\\\cms\\\\Adverts", "ReplacementValue" : "{TargetServerRoot}\\\\Store\\\\Adverts"}
                        ,
                        {"IsRegex": false, "FindValue" : "C:\\\\InfoRhino\\\\cms\\\\IRWebsite\\\\IRWebsiteCMS\\\\wwwroot", "ReplacementValue" : "{TargetServerRoot}\\\\wwwroot"}
                        ,
                        {"IsRegex": false, "FindValue" : "content\\\\Cards", "ReplacementValue" : "Cards"}
                        ,
                        {"IsRegex": true, "FindValue" : "(?is-nx:(?<=\"CardDomainHeaderCaption\"\\:(\\s{0,1})\")([a-z0-9\\s\\,\\.]+))", "ReplacementValue" : "{CardDomainHeaderCaption}"}
                        ,
                        {"IsRegex": true, "FindValue" : "(?is-nx:(?<=\"CardDescription\"\\:(\\s{0,1})\")([a-z0-9\\s\\,\\.]+))", "ReplacementValue" : "{CardDescription}"}
                        ,                       
                        {"IsRegex": true, "FindValue" : "(?is-nx:(?<=\"CompanyName\"\\:(\\s{0,1})\")([a-z0-9\\s\\,\\.]+))", "ReplacementValue" : "{CompanyName}"}

If there's a problem where it makes sense, I love it.
Regular expressions can be written in a clear and easy-to-read way, across multiple lines and with comments. They can condense a lot of logic into something easy to parse by humans, even though their reputation says otherwise. Trying to replicate what they do with a bunch of separate if contains(..) and startsWith(..) and not contains(..) methods is a hack, imo.

Using them for anything where a simple single, named method would suffice is a bad idea.

A few years ago I bought a book (I can't find right now) about the theory of computation, and it started with finite deterministic automata (FDA), moving on to non-deterministic finite automata (NDA) and how FDA and NDA are mathematically equivalent, then it showed how to turn NDA into regular expressions.

The explanation opened my mind to a new way to look at regex, so I found it a lot easier to understand and write them, and also understand their limitations.

The main issue I'm left with is that regex engines these days have added look-ahead and look-behind which means they are no longer mathematically equivalent to NDAs.

How do you feel about it?

Good. It's a useful tool.

Do you seek to use or avoid it as a problem solver

I treat it similarly to SQL or CSS – use it where appropriate, but try to keep it behind an abstraction if possible. E.g. I would wrap a phone number RegEx in a function such as isValidPhoneNumber.

If it's simple to solve the problem without a RegEx then I'll solve it without the RegEx. But sometimes a RegEx is simpler, e.g. the above example.

how much do you understand it

RegEx language generally – I know the basic concepts well enough, but I always check reference materials and/or use a RegEx tool when implementing one.

Specific RegExs – I almost never re-use a RegEx without first taking it apart and making sure I understand what's going on (same with any code snippet really).

If I can avoid it in my code, I will. They can grow like crazy overtime, and they become difficult to read and understand.

I love them in my editor (I use Vim btw) or to perform operations in the shell, however. It's super powerful for everything plain text: search, search and replace, repeating an action on specific lines... the list goes on.

I admit, when I first became really fluent in RegExp, I tended to overuse them for some time. Even now, I have the impulse to solve string-based issues with RegExp, but I have learned to stop and think about if they really are an improvement over other solutions. So you could say I seek to use it and try to avoid it at the same time, mostly because I understand it.

I love working with Regular Expressions.

I use them frequently in VS Code and have a few articles out here on implementing them for Search-and-Replace.

I had a project where I had to replace an AS400 Custom Script Search Language with a JavaScript version. I quickly learned how slow they are when running hundreds of them per line. It also prompted me to create a new tool for documenting Regular Expressions (github.com/bob-fornal/reggie-docs).