Put the Mouse Down and Step Away from the Keyboard

From WikiContent

(Difference between revisions)
Jump to: navigation, search
m
Line 21: Line 21:
If the preceding code seems wordy and difficult to follow, don’t worry. Even an experienced Java developer might think the same; which meant I’d found something worth cleaning up. I refactored it and wrote a few unit tests - just to make sure it still worked.
If the preceding code seems wordy and difficult to follow, don’t worry. Even an experienced Java developer might think the same; which meant I’d found something worth cleaning up. I refactored it and wrote a few unit tests - just to make sure it still worked.
-
I felt pleased. The new version was easier to read, half the size, and more accurate because the original code only tested the upper bounds for the hour, minutes, and seconds. Not bad for half an hour’s work.
+
I felt pleased with the rsults. The new version was easier to read, half the size, and more accurate because the original code had only tested the upper bounds for the hour, minutes, and seconds. Not bad for half an hour’s work.
While getting ready for work the next day, an idea popped in my head; use a regular expression to validate the string. After a few minutes typing, I had a new implementation that only needed one line of code. It worked, but it felt too complicated so I split it in two to make it more readable. Here it is:
While getting ready for work the next day, an idea popped in my head; use a regular expression to validate the string. After a few minutes typing, I had a new implementation that only needed one line of code. It worked, but it felt too complicated so I split it in two to make it more readable. Here it is:
Line 33: Line 33:
If you’re an experienced programmer, you’ve probably had similar experiences. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. You get up for a bio-break, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.
If you’re an experienced programmer, you’ve probably had similar experiences. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. You get up for a bio-break, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.
-
The trick is that while you’re coding, the logical part of your brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break. So put the mouse down and step away from the keyboard. The insights you get may surprise you.
+
The trick is that while you’re coding, the logical part of your brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break. So put the mouse down and step away from the keyboard. The insights you gain may surprise you.
By [[BurkHufnagel]]
By [[BurkHufnagel]]

Revision as of 02:45, 7 March 2009

While cleaning up some legacy code, I found a method designed to verify that a formatted string contained a valid time. The expected format was “hh:mm:ss xx”, where ‘hh’ represents the hour, ‘mm’ represents minutes, ‘ss’ represents seconds, and ‘xx’ is either ‘AM’ or ‘PM’. It seemed fairly long so I took a closer look.

The method used the following code to convert two characters (representing the hour) into a number, and verify that it was in the proper range:

try {
    Integer.parseInt( time.substring(0, 2) );
} catch ( Exception x ) {
    return false;
}
if ( Integer.parseInt(time.substring(0, 2) ) > 12) {
    return false;
}

The same basic code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to test for ‘AM’ or ‘PM’:

if ( !time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM") ) {
    return false;
}

If none of the previous code found a problem and returned “false” then the method returned “true”.

If the preceding code seems wordy and difficult to follow, don’t worry. Even an experienced Java developer might think the same; which meant I’d found something worth cleaning up. I refactored it and wrote a few unit tests - just to make sure it still worked.

I felt pleased with the rsults. The new version was easier to read, half the size, and more accurate because the original code had only tested the upper bounds for the hour, minutes, and seconds. Not bad for half an hour’s work.

While getting ready for work the next day, an idea popped in my head; use a regular expression to validate the string. After a few minutes typing, I had a new implementation that only needed one line of code. It worked, but it felt too complicated so I split it in two to make it more readable. Here it is:

public static boolean validateTime( String time ) {
    String REGEX_PATTERN = "(0[1-9]|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)";
    return time.matches( REGEX_PATTERN );
}

The point of this story is not that I eventually wrote one line of code that did what the original didn’t quite accomplish with over thirty. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.

If you’re an experienced programmer, you’ve probably had similar experiences. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. You get up for a bio-break, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.

The trick is that while you’re coding, the logical part of your brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break. So put the mouse down and step away from the keyboard. The insights you gain may surprise you.

By BurkHufnagel


This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools