I've already spoken about programming Emacs to create C++ files in a standard format. We can compare this technique to a couple of common alternatives:
The first option is tough on the fingers and few of us would fail to introduce a typo or two. The second is better but all too often is executed without due care – maybe because a programmer prefers to concentrate on what he wants to add rather than on what he ought to remove – and all too often leads to a new file which is already slightly broken: perhaps a comment remains which only applies to the original file, perhaps there's an incorrect date stamp.
The elisp solution is an improvement. It addresses the concerns described above and can be tailored to fit our needs most exactly. All decent editors have a macro language, so the technique is portable.
Of course, there is a downside. You have to be comfortable customising your editor. (Or you have to know someone who can do it for you.)
By batch editing I mean the process of creating a program to edit a
collection of source files without user intervention. This is closely related
to editor metaprogramming – indeed,
I often execute simple batch edits without leaving my editor (though the
editor itself may shell-out instructions to tools such as
Very early on in my career (we're talking early 80's) I worked with a programmer who preferred to edit source files in batch mode. His desk did not have a computer terminal on it. Instead, he would study printouts, perhaps marking them up in pencil, perhaps using a rubber to undo these edits, before finally writing – by hand – an editor batch file to apply his changes. He then visited a computer terminal to enter and execute this batch file.
Even then, this was an old-fashioned way of working, yet he was clear about its advantages:
These days, builds are quicker and batch editing is more immediate. With a few
regular expressions and a script you can alter every file in the system in
less time than it takes to check your email. As an example, in
I describe the development of a simple Python script to relocate
source files into a new directory structure, taking care to adjust internal
The benefits of using a script to perform this sort of operation are a superset of those listed above. In addition, a scripted solution beats hand hacking since it is:
Again, there is a downside. You have to invest time in writing the script, which may well require a larger investment in learning a new language. Many of us would regard proficiency in other languages as an upside but it may be difficult to make that initial investment under the usual project pressures.
So, once again, it may end up being a team-mate who ends writes the script for you. Indeed, many software organisations have a dedicated Tools Group which specialises in writing and customising tools for internal use during the development of core products. Perhaps this team could equally well be named a Metaprogramming Group?
|Copyright © 2005 Thomas Guest|