Why the Project Is Called CodeInstances

The name is the idea, in two words. Code is the program you write. An instance is one run of it.

Programmers already use “instance” this way. An object is an instance of its class. A server is an instance of an image. A running process is an instance of a program. In each case there’s one blueprint and many concrete things made from it, each with a life of its own. A run of your code fits right in. It’s made from the code, but it also has things the code doesn’t: the answers it got from the network that day, the time on the clock, the random numbers it drew.

Most tools treat a run as something that happens and is gone. The name says this one doesn’t. Here a run is a thing, with a file, an id and a set of verbs you can apply to it. Keep it and replay it, today. Compare it, shrink it, share it, sign it, later.

Why Not a Clever Name

Shorter, cuter names tend to need explaining. This one mostly explains itself to anyone who has written a class, and the first question it raises (an instance of what?) has a one-line answer: of your code.

It also names the file. An instance file is the product. The tool that makes it is just codeinstances, and the file it writes ends in .instance. When someone sends you one, you know what you’re holding.

How to Write It

CodeInstances, one word with two capitals, for the project. codeinstances, all lower case, for the command. “A code instance”, or just “an instance”, for one kept run.