Programming

Don’t blink.

lubkin0 comment
Blinking is notorious as the least justifiable behavior on a web page. (But don’t blame Lou Montulli, who came up with the idea.)

It’s also British slang for annoying.

I just looked up something in the online documentation for PHP. Pages are generally clean and usable as they appear in the browser, although there are a few poor practices if you look at the underlying HTML.

However. Take a look at a typical page. Below each formal section are (often useful) comments. Try moving the focus down the page different ways—scrolling, moving the mouse, page down. One comment at a time appears in dark colors. The other comments are pale and washed out until you move the focus to them. Then, over 0.4 seconds, they become opaque and readable.

And most of the goodwill from how well thought-out the rest is is squandered.

There is no reason to make text unreadable. And less still to waste the user’s time as they’re made readable.

Since transitions are new to CSS3, my guess is that programmers were playing. As they had in 1994 with <blink>.

Playing is fine.

Then someone in the room has to say it’s great to know we can do this if we ever need it. But we don’t now. So take it out.

Programming without coercion

lubkin0 comment
One of my core values is clarity. Clarity in what you think, what you write, what you say. In programming, this means clarity in your code. What you write should equally make sense to compilers and people.

I remember one program. What they used to call dusty deck, after the deck of punched cards they were on. Dusty from years sitting on a shelf. It had one constant for two very different purposes. The equivalent of using foo for both the range of values for the month and for the hour in a date-time because they both happen to be 12. Lots of luck in Israel, where the Hebrew calendar (1..13) and military time (0..23) are often used.

Continue reading →

Check the price tag

lubkin0 comment
On The West Wing, in “Guns Not Butter,” Charlie—who I see as the series’ protagonist—tries to reach a pal to ask him a simple question and triggers a memo from the Secretary of Defense, CC’ed to the Joint Chiefs and the Secretary of State.

Delegation is a basic principle of engineering. Do what you need and don’t tell you the details.

But sometimes you need the details.

Would you like me to arrange for someone to pick you up? It would be my pleasure. Did I not mention that we’ll charge your account $2,500 for the service? I’m sorry, but you should have asked. Continue reading →

Emacs, also a way of life

lubkin0 comment
If you’ve programmed or been a sysadmin on UNIX or Linux, you’ve undoubtedly already taken sides in emacs versus vi. You won’t be convinced to switch to the other text editor. It’s like trying to persuade someone to flip allegiance between the Red Sox and the Yankees.

If you haven’t, be aware that GNU Emacs is a very powerful text editor that probably runs on any computer you’ve ever edited a file on or ever will. Although calling it a text editor is a profound understatement. It could as easily be considered a software development environment (IDE), an office suite, or a personal information manager (PIM).

Learning GNU Emacs, 3rd Edition is an excellent way to get started. Yes, the book was last revised in 2004. But even the 1991 first edition is still useful—one of the strengths of Emacs is that the basics are stable. Continue reading →

Beware of strange faces in dark dingy places

lubkin1 comment

I’ve been on job interviews where the interviewer writes the equivalent of char *(*(*a[])())() on the whiteboard and asks what it declares.

I usually answer that I could probably figure it out but I’m not going to try.

If we, smart as we are, have to scrunch forehead to decipher a line of code, it’s probably a mistake to have written it that way.

If it’s unclear to you now, it will probably be less clear when you look at it again in six months. Less clear to the engineer who has to fix it after you’ve moved on. That way lies bugs.

Further, if the code relies on an advanced or obscure feature, who says that feature works correctly? It’s probably also a confusing facet of the language for whoever wrote the compiler code. And their interpretation might not match what the standard actually requires. Or how the authors of another compiler interpret it.

Let alone whether you can readily translate your approach into another language. Which is handy.

Sometimes a complicated construct really is the best solution. When it is, write as clear a comment as you can that explains what it does, why it’s correct, and why apparent alternatives wouldn’t have worked.