Clarkson Energy Homes

In general, subroutines should receive data, process that data, and then output something. There are some exceptions. In void context, we have no output. In the case of information retrieval from a fixed source there may not be any input. An error logging routine might have input and output but no processing.

Good subroutines only affect and are affected by their own environment. If events exterior to the subroutine affect it, you have probably done something wrong. Here's an example of a poorly written subroutine. foo() is using $bar. $bar has not been passed to it. Remember that a well written subroutine has data passed to it. Good subroutines only affect and are affected by their own environment. Deleting the $bar variable outside this subroutine affects the subroutine.

(more...)

CGI.pm is a module included in the standard perl distribution. It is the most commonly used module for writing perl scripts that interact with the web.

I run across these mistakes a lot when reviewing beginner perl code. The first mistake has to do with the dual nature of perl modules. A perl module can be accessed either as a function-oriented module or as a object-oriented module or by both methods.

CGI.pm allows both. Under the hood, that makes for some messy looking code. In practice, we find a lot of bloated code. Normally, we would use either the function oriented or the OO version, not both.Here are a few of the most common errors I see.

(more...)

The author of this module chose to use some file scoped variables in a module. This effectively created some global variables used outside the sub. This is not the recommended way to write a subroutine, but I needed an example and this one was handy.

(more...)

Opening files in perl is a fairly easy task. Here are the basic file opens. Do not use them in production code.

(more...)

There is an old saying amongst carpenters. Measure twice, cut once. This cuts down on materials. The same is true of typing for Perl programmers. Read more, type less. Okay, that doesn't have the same ring, but reading the documentation before writing your script does make sense.

I came across a script recently where a beginner programmer had obviously decided that typing was easier than reading. Here's an excerpt. The author needs to start a really wide table, but won't end it for a while yet.

(more...)

This is an excerpt of an answer I gave on an Excel VBA mailing list. The original poster asked if I could explain my solution.

Let's look at a single solution not involving a sub routine call. We'll use the Combo Box control named CboMonth. Here's the submitted method with some white space added for us poor human readers.

(more...)

Many times when writing code, a beginner will ask the language to perform an operation and receive an unusual result. While possible, it is highly unlikely that a beginner will find a bug in perl, JavaScript, etc. Programmers must be humble. The fault ususally lies with us.

Chances are we are asking the programming language to do what we mean instead of telling it what we really want to do. Some languages have logic builin that will try to guess when something might go either way, but we shouldn't depend on this.

Here's an example

No web programming language will return 40 seconds as the answer without extra work.

The programming language does what I want (DWIW), when I was hoping it would do what I mean (DWIM). The next time you don't get a desired result, make certain you are using DWIW.

Sometimes you just have to peek. Whether it's baking brownies, an overheated engine, or a data structure, sometimes you just have to look under the hood. When programming in perl you need to dump the contents of your data structure to see what's there.

(more...)

This may seem trivial, but I believe how we organize programs is directly influenced by how we think. Perhaps learning to better organize code will lead to better organized, more efficient thinking.

(more...)