We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

15

If they need it they will remember it and use it. The last thing we need is a bunch of programmers with a Regex hammer looking for an HTML parsing nail.
–
JohnFxNov 18 '11 at 4:43

Very true. The problem is more fundamental. I have noticed that they go with doing things by manual repetition, than considering automation or regex. This is where I thought they want to make them excited about the possibilities of regex.
–
ragu.pattabiNov 18 '11 at 4:58

7

If you can't think of a time you use it at work then it's not necessarily a bad thing if they don't know them. Half the time I see regular expressions they're doing something they shouldn't be (checking that a date looks like mm/dd/yyyy). If you want an inspiring example xkcd.com/208.
–
WuHoUnitedNov 18 '11 at 5:13

search and replace... now there is one awesome use for regex. Some of us sometimes have to deal with big data-set that are not always very clean. Knowing and using reg-ex in this case is the equivalent of safe sex for data import. in a CSV file Which lines contain phone numbers that are not formatted as expected ? Names come in a single field with last, first middle but I want them in separate fields, write a reg-ex for that. Small, quick, efficient.
–
NewtopianNov 18 '11 at 7:17

The killer application for regular expressions for programmers today (as I see it) is in mining log files. Typical examples:

All lines containing "Frobozz finished"

All lines containing "Failure" but not "Frobozz finished"

All lines containing "Took number seconds" (where number is one or more digits)

This is a typical grep job. For multiple logfiles the advantage of prepending with the file name is really nice.

For more advanced stuff, you need a programming language supporting regular expressions which can be easily started from the command line. This is where Unix tools truly shine. The default standard Unix program fitting this description is awk but these days perl is a more powerful tool which is installed by default on most systems.

This allows you to do stuff like:

All lines containing "Frobozz finished" with a timestamp after 22:00.

All lines containing "Failure" but not "Frobozz finished" where the previous line contained "Frobozz started".

All lines containing "Took number seconds" (where number is one or more digits) where number is more than 10.

Being able to ask such questions allow you to ask questions which quickly dig out those log entries which indicate trouble. Besides being helpful in your daily work, it can be a life-saver in a situation you have a production server with problems that needs to be fixed as soon as possible.

+1 I was about to add this example. Additionally, regex + sed makes it very easy to strip unnecessary stuff from logs, e.g. timestamps when you want to compare two logs created by the same app at different times.
–
Péter TörökNov 18 '11 at 8:13

For more advanced stuff you can also (in addition to knowing regexs) use more specific tools such as logstash.
–
AlbNov 18 '11 at 17:55

A real life example: in order to achieve PCI compliance, we need to ensure that no credit card numbers are published by our system in any way, including log files. So we implemented a log filter to identify and mask out anything in our log messages which looks like a credit card number.

Once we had to migrate all our strcpy statements to strncpy_s. Most of them were in the format strcpy(dest, src) and we wanted to them to basically look like strncpy_s(dest, sizeof(dest), src, _TRUNCATE). There were hundreds of these calls, and after setting off bravely to change them manually I began to explore the options in Search and Replace in Visual Studio. The RegEx codes in VS seem to be quite different from other RegEx engines, but I had a lot of fun working out step by step how to move things around and make them look like I wanted. I even gave a short presentation on Regular Expressions to my co-workers, and after that became the go-to guy for regex.

I don't know how inspiring it is, but it is a practical one: formatting my code. I often will copy/paste stuff from the web and then run a series of regular expressions doing replace to format it to my standards. This way I can strip out unnecessary white-space after a }, or numerous other things like enforcing that there be exactly one space between a function name and the opening {.

How much code does one need to copy exactly as is from the web?
–
Daniel LittleNov 18 '11 at 4:39

When I am an active answerer on StackOverflow? A lot. I usually hate their syntax, so you can darn well bet that I am going to clean it up.
–
Levi MorrisonNov 18 '11 at 4:43

hmmm, while I was reading the answer the following thoughts emerged "When a bit of metal is sticking out I invented this awesome usefull thing. Basically a metal flat head on top of a short metal rod. Grab the rod, give a good whack and boom, all even now". Code formatting is indeed a problem but it's been a long time since I had to do more that 5 minutes googling to find a working formatter to do the job. Most times it comes embedded right in my IDE... spend time and energy create a reg-ex or... ctrf-shift-f, which is faster ?
–
NewtopianNov 18 '11 at 7:13

2

@Levi, why don't you use an editor that can format code to your taste with a simple key command?
–
user1249Nov 18 '11 at 7:19

@THorbjornRavnAndersen Well, mainly because I use VIM but haven't bothered to look into it. Aren't regular expressions so much cooler, anyway?
–
Levi MorrisonNov 18 '11 at 18:00

About a year or two ago, I wrote a piece of code that made heavy use of regular expressions to parse free-form text fields that represented street addresses into structured data (separate fields for street number, suite number, street direction, street type (avenue, road, street, etc...), street names (with multiple words, some of which could have also been part of the direction or street type)). It was a bit of a nightmare but mostly worked on > 80% of the input fields.

Databases that support regular expressions are extremely useful when you're searching for data that is just a bit too complex for LIKE 'something%somethingelse'.

These days I don't do a lot of coding with regular expressions, but I do use text editors that allow searching with regular expressions, which makes searching through large error logs much easier. You can search for all lines containing FoobarFramework(Fatal)?(Exception|Error)(123|456) to search for a few different classes of errors, which otherwise would take 3 or 4 searches through the file.

And then there's input validation... SOO much can be done there with regular expressions. Postal codes and phone numbers seem to be the canonical examples, but there are others, but it will probably depend on your input.

If I weren't so tired, I'd probably have even better examples... maybe tomorrow I'll come up with some more.

Postal codes and phone numbers are also canonical examples of things which most people validate really badly because they don't take into account things like the world containing more than just the country they live in.
–
Peter TaylorNov 18 '11 at 10:01

@PeterTaylor: True, though if your application is intended for use in a specific region where there are well-accepted standards, regular expressions can make the validation much easier. If the application lets users choose a country, there is usually one postal code regex for the postal code patterns of different postal systems.
–
FrustratedWithFormsDesignerNov 18 '11 at 14:24

Following tdammers answer: I program in Visual Studio but when I need to do some complex editing I open vi(m) to use regular expressions. Besides removing / adding leading comments (Python, bash, C++, etc), removing trailing spaces, I can transform and reuse pieces of codes in complex ways.

With vi(m), I can copy / paste section 1 and produce section 3 by using a regular expression like

s/T[0-9][0-9]* \(temp[0-9][0-9]*\) = \(a.x[0-9][0-9]*\);/\2 = \1;/

I type one line instead of going through all lines and adapting each of them. Even if this example is a bit artificial (normally, there are no types numbered from 1 to n in real code), I think you should get the idea that regular expressions are good at matching sub-strings and moving them around. I use this very often.

Granted, making a selector engine is lot more than just regular expressions, but the application of regexes is indispensable for such a system. There's a parser (or lexer) that converts the CSS selector expression into something intermediate that can be easier to select DOM elements with. And you just can't make a non-trivial parser without regexes.

Also, since it's just plain JavaScript, your young programmers can wrestle with regexes without having to build/compile anything. (I guess it helps when you're trying some new language or API, not to be bothered by anything that can be avoided.)

It is also very exciting, because they can just extend the selector syntax in their own arbitrary (but meaningful) ways, and then implement them. (jQuery has a lot of custom selector facilities).

Instead of coming up with "fake" but real-world example. If I were you, I'd go back to your own source repository. If you show people how 200 lines of their own code is reduced down to 5, even if you don't convince everyone, it is very likely you'll convince the author of that code. Then you have 2 people on the team advocating good practices.

Even if you find good examples, I don't think anything will inspire more than seeing your own product's code being simplified, made cleaner and reduced in size by 90%. Better yet, bring a laptop to the meeting and do it in front of the team to illustrate how something that probably took a full day to write could've been reduced to 15 minutes.

And as WuHoUnited noted, if you can't find such examples, you might be doing premature optimization :)