We use find-and-replace almost every day to copy a functionality from another object or when working with templates. At work, we use templates to help kick start multiple kinds of projects and we have to perform project-wide string replacements using a very useful tool appropriately called Actual Search & Replace.

However, when inside an actual project, we often duplicate classes and replace just a few strings (we're working on a code generation tool to reduce these tedious tasks). However, as good little coders, the class names start with a capital letter while the variables of that class start with a lower case letter (we use Pascal casing and Camel casing depending on the situation).

Examples:

Rectangle rectangle = new Rectangle();
PositionedRectangle positionedRectangle = new PositionedRectangle();

However, what if we want to copy this code but replace the class being used (Rectangle) with another (Circle)? In this example, it's quite trivial, but imagine a file with a few hundred lines and 30+ occurrences.

  • Find-and-replace Rectangle with Circle
  • Find-and-replace rectangle with circle

This does not sound so bad if you just consider this one replacement, but imagine doing this 50 times in a day? The time it takes to actually call the find-and-replace tool (ctrl+h), set the appropriate strings in the appropriate input boxes and let the program do the replacement adds up.

Why couldn't there be a smarter find-and-replace?

The smarter find-and-replace I'm talking about would be case insensitive in the sense that it preserves the casing of the first letter (the rest of the letters would be too complicated to figure out by the tool itself).

Example:

Rectangle => Circle
rectangle => circle

That would bring the total number of calls to the find-and-replace tool from 2 to 1, reducing by half all the replacements we have to do.

There should be a new check box under the match-case one:

Mock-up of the option

Hopefully, this feature will make its way in the various text/code editors someday, in the meantime, I'll keep working on ways to avoid having to use string replacements so often.