Home Accessibility Courses Twitter The Mouth Facebook Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
Efficient debugging of regular expressions

Are you a programmer? Have you ever spent *hours* looking for a very odd bug in your code that, when you find and fix it, turns out to have been so blindingly obvious that you ask "why sis it take me so LONG" ... and so does the boss! The good news is that - if the boss is a programmer - (s)he will have been there too and will at least have some understanding and sympathy.

Our Hotel Booking Script has been working well for a very long time - "robust", in fact, but when I entered a booking that came in by phone over the weekend, it went all through the process but then made an error on the confirmation email, which was generated for 2000 not 2010. Some rapid testing showed me that if I didn't enter the year on a booking, there was no problem - but if I specified 2010 it changed it. Odd one, indeed - but one that needed to be fixed.

Have a look at this regular expression, which I used on a trimmed date entry to look for a day, month, year format:
  preg_match('!^(\d+)[-/:\. ]+(\d+)[/-: ]+(\d+)$!', $input, $gotten )
It's been working fine - setting up the day in $gotten[1], the month in $gotten[2] and the year in $gotten[3] for years. To allow for year entries of the "09", "9" or "2009" format, we've taken the modulo base 100 and passed that into mktime to make a timestamp.

Can you spot the error that causes this to fail for "10" or "2010"? It took me longer than it should (and that's once I had tied the problem down to that particular line!

The code:
  preg_match('!^(\d+)[-/:\. ]+(\d+)[/-: ]+(\d+)$!', $input, $gotten )
should have been:
  preg_match('!^(\d+)[-/:\. ]+(\d+)[-/: ]+(\d+)$!', $input, $gotten )

The regular expression element [/-: ] was SUPPOSED to match any one of the four characters in the square brackets, but the minus sign within a list of characters is a special case that gives a range of characters ... / is ASCII code 47, as I recall, and : is code 58 - so that I'll matching any one of / 0 1 2 3 4 5 6 7 8 9 and : ... or in the context that I've used the match, I'm absorbing the entire year as if it was the separator between the month and year, then backtracking to get the last digit (only) of the year into $gotten[3]. Simples!

Net result ... my code as it stood worked for the first ten years of the decade ...

Regular expressions are extremely powerful - the example that I've used above copes with more or less any conventional 3 numeric element date, irrespective of the separators the user chooses (and that's exactly what you want on a web site). However, you need to understand the power and the elements behind them as I have demonstrated today, otherwise you can get caught as I did. We run a Regular Exprssion Course - it's one day - for delegates who are already familiar with a language that supports regular expressions ... that's Perl, PHP, Python, Java, Tcl, Ruby ... on which we cover topics such as greedy and sparse matching, look ahead, grouping and much more. We won't prevent you writing code that very occasionally has problems like the one I described above, but we'll helpp you reduce those problems to a bare minimum, and allow you to find and fix the few issues that you have quickly. I didn't have a big explanation to make to anyone as to why I took do long to fix the problem above - from starting to look, it took less than an hour to tie it down to being a problem with that regular expression, and then to spot what the problem was.


(written 2010-01-04)

 
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articles
Q806 - Regular Expression Cookbook
  [672] Keeping your regular expressions simple - (2006-04-05)
  [1230] Commenting a Perl Regular Expression - (2007-06-12)
  [1305] Regular expressions made easy - building from components - (2007-08-16)
  [1840] Validating Credit Card Numbers - (2008-10-14)
  [2165] Making Regular Expressions easy to read and maintain - (2009-05-10)
  [2608] Search and replace in Ruby - Ruby Regular Expressions - (2010-01-31)
  [2702] First and last match with Regular Expressions - (2010-04-02)
  [2727] Making a Lua program run more than 10 times faster - (2010-04-16)
  [2804] Regular Expression Myths - (2010-06-13)
  [3218] Matching a license plate or product code - Regular Expressions - (2011-03-28)
  [3788] Getting more than a yes / no answer from a regular expression pattern match - (2012-06-30)

Q801 - Object Orientation and General technical topics - What are Regular Expressions?
  [1195] Regular Express Primer - (2007-05-20)
  [2844] Learning about Regular Expressions in C through examples - (2010-06-30)
  [4505] Regular Expressions for the petrified - in Ruby - (2015-06-03)
  [4763] Regex Reference sheet - (2017-10-10)


Back to
Tuning the web site for sailing on through this year
Previous and next
or
Horse's mouth home
Forward to
Microblogging services - Plurk, Twitter, Jaiku and more
Some other Articles
Extra MySQL course dates (2 day course, UK)
Excellent staff make for excellent hotel
Bright day, snowy day
Microblogging services - Plurk, Twitter, Jaiku and more
Efficient debugging of regular expressions
Tuning the web site for sailing on through this year
The future of MySQL
Training comparison to QA Training, Learning Tree, GB Direct.
Moving the product forward - ours, and MySQL, Perl, PHP and Python too
Happy new decade - and course and hotel prices for 2010
4759 posts, page by page
Link to page ... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96 at 50 posts per page


This is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.

Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho

PAGE: http://www.wellho.net/mouth/2563_.html • PAGE BUILT: Sun Oct 11 16:07:41 2020 • BUILD SYSTEM: JelliaJamb