Cell Phones Are Still a Compromise

I have a cellphone but it's off most of the time. I've given out the number to very few people, and they know that I keep the phone off most of the time. Since I don't have call blocking enabled (that I know of!) anyone I call can grab my number. Since I don't, however, call that many people, I don't worry about who they are.

A number of months ago I interviewed at Google. I didn't get the job (sigh) but that's bits into the bucket. One of the pieces of information that came across in one of the emails (from their recruiter) was that they preferred that their interviewees NOT use cell phones during the phone screens.

This intrigued me. I'm not sure whether this is because cell phone networks in some countries aren't up to snuff or for some other reason(s). I do know from my own personal experience that about half the cell phone calls I make have dropouts or clarity problems, even in "civilized" places like the San Francisco Bay Area. Which actually is the primary reason I don't turn my cell phone on unless absolutely necessary.

JavaScript Strikes Again

In a recent job interview, I was asked how does one detect (in a JavaScript function) whether a parameter actually had a value passed to it. It's been a long time since I've done any JavaScript, so I answered that I assumed there was a way to test for "null". The interviewer said that I had the appropriate concept, but the actual language keyword to test against was "undefined". We then had a brief discussion about null versus undefined, but I wanted to find out more.

Google turned up this page which has some very concise and useful examples. I was not amused, however, to read that testing for null will return true regardless of whether the value is actually null or undefined. I would hope that testing for undefined doesn't return true for null, and I hope to have time to test this sometime in the future. This brought me back to the first time I realized that JavaScript didn't (in previous incarnations, anyway) syntax check code that was never executed. I'm used to that happening for shell script, but it brought me up short for a language that actually seemed to be used in many shipping products.

I guess one works with what one is given, but it doesn't make me any more confident in JavaScript as a robust language.

Today's Formatting Hobgoblin

One of the little things that bothers me about some of the code I work with is the variation in handling of the "if" statement. In this code an "if" with a single statement in the "if" block (and no "else" block) will end up on one line:

if (condition) do_something_else();

I find this interrupts my reading of the code. I realize that putting brackets around the statement in the "if" block and putting the statement on its own line will add two lines to the code. I find, however, the consistency of formatting makes the code easier to read (for me, anyway).

This may be a foolish consistency or not. I looked back to my favorite coding standard for support. The Linux kernel coding style says "Don't put multiple statements on a single line unless you have something to hide." This doesn't mention brackets, but that follows from other standards.

At least I'm not the only voice crying in the wilderness...