I hate cut-and-paste

Me, I blame the IDE's.

Coding used to be hard. Not because programming itself was overly hard, but mostly because editors absolutely sucked. How much the typical development environment in the 70's and 80's sucked is hard to convey (except for a very lucky few, and those would have likely been using DEC and WANG gear). I got in on the tail end of the punch card era. Punching your own program is lots of fun. Once. And if you drop a deck you get to play with the sorter, which is also lots of fun (ok, maybe twice, invariably, on every third usage the sorter would jam and that would be really really messy). The bank where I worked still used those in 1986!

(If you'd like to see what the punchcard equivalent of the sequence 'sort < source.cbl > sort.out ; mv sort.out source.cbl looked like back then here is a nice video:http://www.youtube.com/watch?v=2RCgIrZiC6c )

Fortunately the teletype replaced the punch card system, and then the teletype went the way of the Mastodont (they weighed about as much too), but the first crt based terminals were not much more than glass teletypes. [pause here to adjust the blanket]

Just keeping tabs on what functions went into what file (assuming your language of choice had functions, which you really couldn't take for granted) required either an eidetic memory or a very rigid order. Otherwise you'd be looking all day long for 'that function', or 'that variable declaration'. Re-entering a piece of code required line-by-line retyping. It was an absolute nuisance, so you tried to avoid that as much as you could.

Some of the ways in which you could avoid having to retype a lot of code:

- think about the program a long time before writing it so things don't move around too much

- making sure things were done once, and once only in the whole program

- abstract as much of your code as you can into re-usable libraries

Exploratory coding was a very expensive affair.

Then came the full screen editors. They were a bliss compared to line editors. Really. If you don't believe me try 'edlin' for a day or so. We'll see how you like that. Then you'll be wondering how come any software got written at all for the first 2 decades of computing.

After that you'll also be offering sacrifices to Irons and Djorup twice daily. [include picture of altar here].

The first editor that I worked with that was half decent, could scroll through text and had block mark, copy, move and delete was one I cobbled together on a 6809 micro computer. There is something really annoying about writing tools for a computer, and it is this: Tool Strapping. Whatever tool you are building, you need that tool to build the tool. In order to write an assembler you need an editor and an assember, and in order to write an editor you'll need an editor and an assembler (or a compiler). Writing an editor without an editor was tricky.

When it was done, the editor wasn't great but it worked. I called it 'e' (I really didn't like typing long command names, 'e' and its descendants were in use well into the early 2000's as my main go-to text editor, it ended up occupying a middle ground between vi and emacs, it has since been retired and now enjoys a quiet life in a subversion repository).

The edit-compile-test or edit-assemble-test cycle dropped in a couple of years from a few hours to a few seconds and it felt like the biggest productivity boost ever.

Once I could copy blocks I noticed my programs suddenly grew longer much faster. From a few thousand lines my programs suddenly bloated into 10,000+ line monsters that didn't seem to do all that much more than their svelte cousins of the time before the block goodies.

It didn't take me all that long to realize that since the cost of copying a bunch of lines had gone up from re-typing them to three keystrokes that copying a bunch of lines suddenly seemed like a very good idea where before I would have probably abstracted out the common behavior to a function, or added a parameter or create a bunch of macros that would call an existing one function.

Probably the fact that I'd already done quite a bit of programming before I discovered this latent bad habit really helped. So naturally, I quit doing that, but it is an easy trap to fall in to, the temptation is there all the time. It's only a couple of lines, right? It happened to me, and it could happen to you too. Cut-and-paste. It seemed like such a good idea at the time.

But like any sharp tool it has the ability to cut you just as easily as it cuts the wood, so you need to apply it with care.

The cost of using it indiscriminately is called bloat, and such bloat can turn even the easiest program into a bunch of indecipherable gibberish with lots of functions and other sections of code that differ in only slight detail. A while ago I worked on a project that was written in a language whose name I won't mention in this blog (but it was Java), and which had some serious problems in the functionality:linecount department. The previous programmer had quit in a huff and I inherited the code with the request to add some small features. The program was absolutely huge, but it didn't seem to do all that much. Basically each and every time a table in a database needed to be accessed, updated or had to have a record inserted a routine would be called that did just that.

And these routines all looked alike. Apart from the tablename, and maybe a parameter or two they'd be identical. Scores of them. 30 lines or so each, and that program accessed a lot of tables. Cut-paste (or rather: copy-paste).

Another program I recently worked on which was originally written by another programmer was pretty neat at first glance. But the more you looked the more you realized that it was full of 5 to 20 line idiomatic chunks. And those chunks were literally everywhere. Cut-paste.

Now, don't get me wrong. Cut-and-paste have their uses. Just like any other tool, you need to understand their impact, what they're excellent for (for instance, you can't really refactor code without the ability to move stuff around easily) and what they're terrible at (writing code).

With modern day IDEs that generate a few hundred lines of boilerplate code with a single mouseclick the problem is getting worse than it ever was before.

Of course, if you don't actually intend to understand all the code that you maintain than there is nothing wrong with this approach. I call that Fire & Forget software, alternative names include 'job security' and 'nightmare', depending on your vantage point.

But if your goal is to gain and to maintain control over the code that is keeping your company alive, small is better.

Small is better because small allows you to understand what it is that your code is doing. It is better because it reduces the scope of your focus, just as it reduces the scope of your variables. It reduces the number of lines that you have to grok in order to fully understand what makes a program tick, and once you fully grok it bugs will have a much harder time to stay hidden. Because your program will be more compact, it will likely run faster (because a larger part of it will fit in the cache), and it will be easier to maintain (because it is easier to understand). Things like reduced compile times are a nice bonus but not the main reason.

If you're from the generation of programmers that never knew a world without full screen editors then I have a message for you:

Think about that ctrl-C, ctrl-V sequence next time you are about to use it. It's not free, there is a price attached to that two-keystroke candy. I hate them... But I love them whenever I need to refactor a bunch of cut-and-paste software written by people that used them as if there is no cost attached to their use.