Skill and Quirks

As with any profession, programming is a split of skill and quirks. Quirks come in many forms and can be quite useful or a bane. In JavaScript, for instance, you can reference a function as an object, which itself can be referenced as a hash. Thusly, window.foo[bar](baz) is perfectly valid(!). In PHP, an Array can be accessed by square or curly braces; $a['b'] and $a{'b'} are equivalent(!!). These idiosyncrasies facilitate flexible code, yes, but can also be dangerous for maintenance. A person new to JavaScript, (who probably doesn’t quite grasp closures just yet), will most likely have less than a clue as to why the snipped is valid. The PHP programmer who has a background in C would expect the curly braces to define a new scope, not act as a hash lookup.

I am going to argue against myself here. I realize that in a prior post I praised PHP dereferencing, longing for the direct pointer manipulation of Perl, by using $value=true; $name='value'; ${$name}==true. However, for the next developer, he or she must understand prior to inheriting the code, how PHP handles inline eval() statements.

In situations where the use of these is unavoidable – usually in dynamically-created variables, LISP anyone? – a detailed comment is assuredly in order. Even if it is simple, an example, the next programmer to stumble across your code should be able to reasonably expect an outcome from the procedure.

In JavaScript I’ve been writing lately, I’ve become very cautious about the nature of functions and closures. Frequently, I’ve adopted the practice of namespacing everything I write. Because of that, grouping functions down to the program area can be tedious. No programmer wants to see com.acme.financial.payment.forms.construct(). With JavaScript, we can fake a with() statement. var pay_form = com.acme.financial.payment.forms; additionally com.acme.financial[params['object_type']].forms[action](params_hash) can save a lot of code later in the process.

As an engineer, we should always be looking for ways to perfect our trade. Often this means coding cleanly, and using conventions. Sometimes this means using quirks to their biggest advantage: shrinking the codebase. Remember, one bug for every ten lines.