Programming Tip: Open and Close at the Same Time

One useful programming habit I picked up at some point is: if you open or start something, immediately close it or end it. If you open a bracket, immediately write its closing bracket. If you open a file, immediately write the code to close it.

These days, development environments take care of the niggling little details like matching parentheses and brackets for you. That’s great, but that’s just syntax. The same principle extends further, and automatic tools can’t guess what it is you want to do.

There’s a problem in a lot of code called a resource leak. The classic example is memory leaks in C: the code asks for, and gets, a chunk of memory. But if you don’t free the memory when you’re done with it, then your program will get larger and larger — like a coffee table where a new magazine is added every month but none are ever taken away — until eventually the machine runs out of memory.

These days, languages keep track of memory for you, so it’s easier to avoid memory leaks than it used to be. But the best way I’ve found to manage them is: when you allocate memory (or some other resource), plan to release it when you’re done.

The same principle applies to any resource: if you read or write a file, you’ll need a file handle. If you never close them, they’ll keep lying around, and you’ll eventually run out. So plan ahead, and free the resource as soon as you’ve alocated it:

Once you’ve written

open INFILE, "<", "/path/to/myfile";

go ahead and immediately write the code to close that file:

open INFILE, "<", "/path/to/myfile";
close INFILE;

and only then write the code to do stuff with the file:

open INFILE, "<", "/path/to/myfile";
while ()
{
	print "hello\n" if /foo/;
}
close INFILE;

The corollary of this is, if you’ve written the open but aren’t sure where to put the close, then you may want to take a look at the structure of your code, and refactor it.

This same principle applies in many situations: when you open a connection to a remote web server, database server, etc., immediately write the code to close the connection. If you’re writing HTML, and you’ve written <foo>, immediately write the corresponding </foo>. If you’ve sent off an asynchronous AJAX request, figure out where you’re going to receive the reply. When you throw an exception, decide where you’re going to catch it.

And only then write the meat of the code, the stuff that goes between the opening and closing code.

As I said, I originally came across this as a tip for avoiding memory leaks. But I’ve found that doing things this way forces me to be mindful of the structure of my code, and avoid costly surprises down the line.

Advertisements
This entry was posted in Hacking, Things I've Learned and tagged , , . Bookmark the permalink.

3 Responses to Programming Tip: Open and Close at the Same Time

  1. Steve Watson says:

    Good advice, though I’ll confess to letting emacs keep track of open/close delimiters for me. However: third-last paragraph: is the supposed to be a pair of HTML tags in there? That you neglected to escape? 😉

    Like

    • arensb says:

      By all means, let Emacs close your parens and braces for you. Or close open tags, if you’re writing plain HTML or XML. But if you’re using Emacs to write a PHP script that generates an HTML list, and you’ve just written

      echo "<ol>\n";

      then Emacs can’t tell you where to put the corresponding

      echo "</ol>\n";

      That’s something only you know. And it’s best to write that part immediately.

      And yes, thanks for pointing out the problem. Apparently WordPress has a problem with escaped HTML.

      Like

      • Steve Watson says:

        Keeping track of parens and braces was what I had in mind (and it seems to do OK on open/close quotes as well). For actual program semantics, though, you’re right, no editor is going to do that thinking for you.

        I have one project in which I use PHP to read spreadsheet data and write out Javascript, some of which is literal strings, some of which contain HTML tags which contain their own quoted parameters, and other strings which contain apostrophes (e.g. French words). It was *loads* of fun managing double quotes, single quotes, and escapes. Emacs colour-coding helped, but couldn’t keep track of everything.

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s