{"id":613,"date":"2010-01-07T10:29:53","date_gmt":"2010-01-07T00:29:53","guid":{"rendered":"http:\/\/www.malcolmgroves.com\/blog\/?p=613"},"modified":"2015-03-13T11:02:56","modified_gmt":"2015-03-13T00:02:56","slug":"searching-in-delphi-part-1-regular-expressions","status":"publish","type":"post","link":"http:\/\/www.malcolmgroves.com\/blog\/?p=613","title":{"rendered":"Searching in Delphi Part 1 : Regular Expressions"},"content":{"rendered":"

Being able to find elements in your code quickly and easily is critical to being productive in any IDE. Spend too long looking for things and you start to lose your train of thought. Over the years Delphi has introduced lots of different ways to search your code, some of them simple text-based matching, some of them much more capable search engines that actually understand the structure of your code. However, I regularly meet developers who aren\u2019t aware of many of them, beyond doing a simple search using the Search | Find<\/a> (Ctrl-F) menu option, or the same across multiple files using Search | Find in Files<\/a> (Shift-Ctrl-F).<\/p>\n

Starting with this post I\u2019m going to try and address some of that. Each post will focus on a different way to find things in your project. I\u2019m going to assume, however, that everyone can use the basic Find and Find in Files functionality, so I won\u2019t cover that. However, I will start by covering one feature of both of those text-based searches that seems to be underused : Regular Expressions.<\/p>\n

When doing a text-based search, usually the more specific you can be with your search string, the fewer false matches (ie. matches that you are not actually looking for) you\u2019ll get. Problem is you often either don\u2019t know enough of the exact text around your match, or you\u2019re trying to match multiple lines with different text around your string. So you end up with a not very specific search string, and so many matches you waste a bunch of time trying to find the relevant ones, or worse, miss some relevant ones amongst the deluge.<\/p>\n

You\u2019re probably never going to get the perfect result of just the items you\u2019re looking for. It ends up being a trade-off between the time spent creating the search string vs the time spent wading through the results, and often a good enough balance, is, well, good enough. This is where regular expressions can help<\/p>\n

Let me give you a concrete example.<\/p>\n

The DUnit framework makes heavy use of an interface called ITest. Let\u2019s say you want to find all places in TestFramework.pas where an ITest is passed in as a parameter to a method.<\/p>\n

\"search1\"<\/a> Well, we can start by hitting Ctrl-F, type in ITest and hit enter and as you can see in the screeshot to the left, we get 143 results for just this one unit.<\/p>\n

As you should also be able to see, there are a whole bunch of results that aren\u2019t actually what we\u2019re looking for. It\u2019s matching ITestDecorator, ITestListener, even comments. Further, even where it has found ITest, it isn\u2019t just showing us where it\u2019s been used as a method parameter, it\u2019s showing us everything.<\/p>\n

So, how can we try to narrow down our search results? Well, we could try searching for \u201c: ITest\u201d and this gets us fewer results, but it still has problems. First, it misses places where there is no space between the colon and ITest. It also has false positives on field and variable declarations of type ITest. We could search on \u201c: ITest)\u201d which removes the field and variable declarations, but we\u2019ve now lost the instances where there are additional parameters in the method signature after the ITest parameter. Just to complicate matters further, what if the parameter is an array of ITest? We\u2019ve missed those too.<\/p>\n

OK, now that my strawman is suitably setup, think about how we could more accurately identify just the ITest method parameters. Perhaps if we look for a colon followed by zero or more characters, followed by ITest, followed by zero or more characters, followed by a closing bracket.<\/p>\n

I\u2019m a long, long way from being a regex expert, I can fairly easily remember 3 or 4 syntax elements without looking at a reference, beyond that I\u2019m struggling. However, even these few can be pretty powerful. In fact, in this example I only need to remember three things to construct my search:<\/p>\n