The Cafes » Programming

Last week one of my colleagues hit me with an idea that was so obvious when he pointed it out I wondered why I hadn’t realized it before:

If you’re designing for reuse, you’re doing it wrong.

In 2012 the only code you should be writing is what’s needed for the immediate task at hand. Don’t design for reuse. Don’t consider reuse. Don’t waste one minute of your day making code reusable.
(more…)

In 2011 my New Year’s resolution is to do more things the easy way, even if it takes longer the first time. I am going to stop using brute force to solve problems. In particular:

• I am finally going to memorize how one redirects both stderr and stdout to the same stream. (2>&1 |)
• I am going to learn the sed? trick my advisor showed me 20 years ago for repeating a command from the shell history while substituting one word for another, instead of just using the arrow key to backup to and erase the string. (^string1^string2^ or !!:s/string1/string2/ or for global substitution, not just the first occurrence !!:gs/string1/string2/)
• I am going to increase my regex fu and use regular expressions consistently instead of just editing 20 lines of copy and paste code. (This would be easier if every editor didn’t have subtly different syntax.)
• I am going to use Python to automate repetitive tasks.

Have you ever seen an Ant error message like this?

BUILD FAILED
/Users/elharo/Projects/XOM/build.xml:545: Problem: failed to create task or type scp
Cause: Could not load a dependent class com/jcraft/jsch/Logger
       It is not enough to have Ant's optional JARs
       you need the JAR files that the optional tasks depend upon.
       Ant's optional task dependencies are listed in the manual.
Action: Determine what extra JAR files are needed, and place them in one of:
        -/opt/ant/lib
        -/Users/elharo/.ant/lib
        -a directory added on the command line with the -lib argument

Do not panic, this is a common problem.
The commonest cause is a missing JAR.

This is not a bug; it is a configuration problem

As usual, the ant error message is completely unhelpful, though for once it’s at least technically correct. (Most of the time when ant says, “This is not a bug; it is a configuration problem”, it is in fact a bug and not a configuration problem.) Here’s what’s really happening.
(more…)

Is req a request or a requisition?

Is res a response, a reservation, a resume, or a result?

Is def a default or a definition?

Is rng a range or a random number generator?

Is v1 version 1 or value 1?

Is e an event, an entity, or an exception?

Is f a file or a float?

Is lst a list or the least value?

Is temp a temporary variable or a temperature reading?

Is rep a representation, a representative, a repetition, or a reputation?

Is tm a time or a trademark? Or even another temporary variable? And if it is a time, is it a timestamp, a time of day, or a duration? (These are three very different things.)

Is admin an administrator, an administrative assistant, or a system administrator?

In context, you can usually figure these things out, but you have to think about them. That’s inefficient. Far better to just spell out what you mean from the get go.
(more…)

Every time the subject of checked versus runtime exceptions comes up, someone cites Bruce Eckel as an argument by authority. This is unfortunate, because, as much as I like and respect Bruce, he is out to sea on this one. Nor is it merely a matter of opinion. In this case, Bruce is factually incorrect. He believes things about checked exceptions that just aren’t true; and I think it’s time to lay his misconceptions to rest once and for all.

Let’s see exactly what Bruce’s mistake is. The following is an extended selection from Thinking in Java, 4th edition, pp. 490-491:

An exception-handling system is a trapdoor that allows your program to abandon execution of the normal sequence of statements. The trapdoors used when an “exceptional condition” occurs, such that normal execution is no longer possible or desirable. Exceptions represent conditions that the current method is unable to handle. The reason exception-handling systems were developed is because the approach of dealing with each possible error condition produced by each function call was too onerous, and programmers simply weren’t doing it. As a result, they were ignoring the errors. It’s worth observing that the issue of programmer convenience in handling errors was a prime motivation for exceptions in the first place.

One of the important guidelines in exception handling is “Don’t catch an exception unless you know what to do with it.” In fact, one of the important goals of exception handling is to move the error-handling code away from the point where the errors occur. This allows you to focus on what you want to accomplish in one section of your code, and how you’re going to deal with problems in a distinct separate section of your code. As a result, your mainline code is not cluttered with error-handling logic, and it’s much easier to understand and maintain. Exception handling also tends to reduce the amount of error-handling code, by allowing one handler to deal with many error sites.

Checked exceptions complicate the scenario a bit, because they force you to add catch clauses in places where you may not be ready to handle an error. This results in the “harmful if swallowed” problem:

try {
// ... to do something useful
} catch (ObligatoryException e) {} // Gulp!

Do you see the mistake? It’s a common one. (more…)