link[rel='developer']

I was reading the Pickaxe book today, brushing up on my Ruby skills and came across a passage that had me thinking about how our approach to programming affects our job and career. It started simply enough, explaining Ruby boolean expressions

Ruby has a simple definition of truth. Any value that is not nil or the constant false is true.

But then it got worse:

However, C, C++ and Perl programmers sometimes fall into a trap. The number zero is not interpreted as a false value. Neither is a zero-length string. This can be a tough habit to break.

I had to think about that for a bit…why would someone assume that zero means false? Ah, right… in C and C++, my daily language, any non-zero value is true while zero is equivalent to false. This bit of cruft is due to C starting out without a true boolean type and lead to code like:

void do_something (data_type *p) {
  // make sure we have a valid pointer
  if (!p)
    return;
  // do something with p
  ...
}

There’s a couple of things going on with the if !p test. First, the value of p is being converted from a pointer-type to an integer-type, then it is being coerced to a boolean-type (or not, depending on how old your C/C++ is) and then negated. If the result of the negation is zero, the whole expression is considered false; otherwise it is true. Crufty.

Algorithmically, this is distracting and unrelated. It is baggage of the language being used and a detriment to readability, maintainability and your skill set. Let’s fix the issue so we can discuss why thinking in code is a bad habit:

void do_something (data_type *p) {
  // make sure we have a valid pointer
  if (p == NULL)
    return;
  // do something with p
  ...
}

Note the change? Now p is compared directly to the language’s null pointer construct (in ruby, it would be nil). Admittedly, this is a contrived example, but the point is that polluting your algorithm with language-specific brittleness is a bad thing. It is a habit of programmers; not just programmers but language-specific programmers. For clarity, code must state exactly what it means.

As we grow in our careers and our skill set, we need to change our mind set. The rate of change in the computer industry is staggering. The number of languages used in just one product is almost always greater than one, and for large applications can be five or more (count them: C, C++, Java, JavaScript, SQL, Installer scripts, shell scripts, perl — and yes, this is an actual shipping product).

As an engineer, your value is your skill turning algorithms into code, in the appropriate language and in a clean, efficient and maintainable representation. Freeing your thought process of language specific cruft — except when needed, of course — will make you a better engineer, and thus more valuable.

Filed under: General