October 1, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Search and Replace with Regular Expressions

  • March 17, 2008
  • By Paul Kimmel
  • Send Email »
  • More Articles »

The code in Listing 1 uses an F prefix for fields to differentiate fields from properties as little as possible, but no other prefix convention is needed in a strongly typed language.

Now, I have seen people respond in several various ways to code that doesn't meet the "standard," including:

  1. The person who wrote this code is a nitwit and they don't know what they are doing (because they aren't following our standard).
  2. We better have coding standards meetings and (figure out the perfect standard).
  3. Fire that idiot (because he doesn't know what he is doing).

All three responses are pointless. There is no perfect standard and uniformity is only possible in herd animals (and McDonald's employees). Even people in the military have personality quirks bubbling to the surface. In response to number 2, coding standards meetings are stupid too. It all comes down to who has the loudest mouth, the most forceful personality, or the most clout. In the end, the person with the power gets to choose, so why have the meeting in the first place?! Finally, firing someone who doesn't conform is stupid. Software requires smart creative people, not mutant, borg-like conformists. Anyone who doesn't know that is a numbskull.

The right solution is quite simple: Let people code however they code. Don't judge, don't fuss, don't fret, and for god sakes don't meet on the subject. If, and only if the literal code-text is a deliverable, decide what you want it to look like after the application is deployed and pay some toolsmith, hobbyist, or intern to repaginate it. Violà!

The "intern will fix it" approach will be a lot cheaper than having highly compensated (I hope) developers arguing over semnatics like how many spaces to tab. No one really cares. And, if the intern breaks the code, again so what, you have it under version control, right? You are only paying the intern $10 per hour. Let him take another stab at it. (Better still, paginating in formatting source code is something that can be done reliably and cheaply; outsource it.)

Finally, give the intern a copy of this article so he doesn't take forever to clean up that sloppy code. (But only give him the part of this article that follows this part, so he doesn't learn that you are giving them grunt work.)

Test Your Regular Expressions with Search-Only First

Regular Expressions in search and replace mode can quickly become search and destroy mode. (But, hey, you are using version control right?!) Regular expressions are powerful and can do a lot with a very little bit of code, so unless you want to be checking things in and out all day long, test you expressions in search-only mode first.

In your scenario, you want to replace all of the elements in Listing 1 that have an F prefix. The first thing to do is to ensure that the dialog will be using regular expressions. In the Find and Replace dialog, expand the Find options section and make sure the options are configured as shown in Figure 1.

Figure 1: Select search in hidden text to check those pesky collapsible regions and check use regular expressions.

The next thing you will need is a location containing the definitive source (or at least most of the information you'll need) for regular expressions in Visual Studio. See the help topic "Regular Expressions (Visual Studio)" at http://msdn2.microsoft.com/en-us/library/2k3te2cs.aspx.

Tip: Quick Find supports a Bookmark All operation. You can use this button to add a bookmark to everything that matches your regular expression as a means of testing the expressions correctness prior to replacing text.

The next step is to identify everything you want to replace and to figure out the regular expression for the find and replace pieces of the puzzle. The fields are using the F prefix. The property setters and getters are using the F prefix and the Storage named parameter of the ColumnAttribute is using the field names as strings.

Now, you could replace the fields by searching on "Private F" and replacing it with "Private m_", but what if you weren't sure how the whitespace had been added or whether the whitespace between Private and F were even uniform? Well, you can use the regular expression. Here is an example for the find part:

Private:WhF{:c+}

Private is a literal. :Wh means whitespaces, including tabs or literal spaces. F is a literal, and :c+ means any one or more characters after the F. Placing the :c+ in the brackets {:c+} treats the characters after the F as a separate group. This is important because you want to re-use those characters. You can refer to the group with the \# sequence as in \0 for group 0, \1 for group 1, and so on. The following sequence

Private m_\1

replaces the F prefix as in

Private FCustomerID As String

with an m_ yielding

Private m_CustomerID As String




Page 2 of 4



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel