Jamie Zawinski, also known simply as jwz, is famous for his quote: “Some people, when confronted with a problem, think \u2018I know, I’ll use regular expressions.\u2019 Now they have two problems.” It’s a very amusing line, and I can totally see why people all over the world are using it in their .sig files: It makes them feel better about not being able to understand regexes. And it looks more erudite than just saying, “Some dude who used to work for Netscape thinks they’re a bad idea, so I don’t have to worry about the difference between \\w and \\S.”<\/p>\n
(It turns out the “now they have two problems” construction didn’t even originate with Jamie; it can be found \u2014 slamming awk instead of regexes \u2014 in the .sig line of a Usenet post in comp.sys.ibm.pc.rt in 1988, and perhaps even further. Maybe this is just another instance of how, as Jamie puts it, people only remember the stupid stuff<\/a> he says?)<\/p>\n Anyway, as witty as this line is, it’s wrong. Like any other tool, regular expressions are designed to solve a particular class of problems. And, like every other tool, there is a class of problems that they’re just not so good at handling.<\/p>\n Regexes are excellent for doing pattern matching. If you need to ensure that a text string is, for example, a standard ISBN, or a postal code from a particular nation, or a valid username for a given spec. In any of these (fairly standard and common) validation scenarios, regexes will save you a lot of time and trouble.<\/p>\n To take a fairly trivial case, suppose you want to know if a given string is a valid US ZIP code<\/span>. If you don’t have regexes available (either because you’re working in a language that doesn’t support them, or because you haven’t learned them), your first thought might be:<\/p>\n But this doesn’t work, because “2134” is not a valid ZIP code \u2014 although “02134” is, and can be found in Boston. Plus, this conditional won’t handle 9-digit ZIP codes. What you really need to test for is: “This string has 5 digits in a row. Then, optionally, it has a dash, and then 4 more digits.”<\/p>\n If you don’t have regexes, this is where you wind up writing something painful like:<\/p>\n In fact, this isn’t some contrived example I whipped up to make the process seem more awkward than it has to be. This is the best<\/em> solution I can find without regexes, and it relies on the fact that “the digits from 0-9” is a contiguous range of ASCII characters and values. If I’d instead wanted to allow \u201cupper- and lower-case letters, but not<\/em> the characters ` [ \\ ] or ^\u201d (a fairly reasonable restriction), I’d have to use two non-contiguous<\/em> ranges, with a corresponding increase in complexity.<\/p>\n Now suppose you’ve decided usernames must be 4-20 characters long, and may contain letters, numbers, hyphens, underscores, and periods. If you look at this from a user’s perspective (where details of implementation are irrelevant, and all that matters is the actual functionality), this makes perfect sense: it lets users use all the characters they’re most likely to want. They can have names like John.Doe, mary_roe, curly-moe and b_hills90210.<\/p>\nif (strlen(input) != 5 && strlen(input) != 10) {\n return false;\n}\nfor (int i = 0; i < strlen(input); i++) {\n int ascii = chr(substr(input, i, 1));\n if (i = 5 && ascii != 45) {\n return false;\n } else if (ascii < 48 || ascii > 57) {\n return false;\n }\n}\nreturn true;<\/pre>\n