Editors and Editing

Editor Metaprogramming

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:

create an empty file then type in the standard header etc.
copy an existing file which does something similar to what we want, then adapt as required.

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.)

Batch Editing

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 find and sed).

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:

Recordable: the batch file provides a perfect record of what it has done.
Reversable: its effects can therefore be undone, if necessary.
Reflective: by working in this reflective, careful way, he was less likely to introduce errors. When system rebuilds can only be run overnight, this becomes paramount.

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 another article I describe the development of a simple Python script to relocate source files into a new directory structure, taking care to adjust internal references to #included files.

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:

Reliable: the script can be shown to work by unit tests and by system tests on small data sets. Then it can be left to do its job.
Efficient: editing dozens – perhaps hundreds – of files by hand is error prone and tedious. A script can process Megabytes of source code in minutes.

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?