Programming pet peeves

First, a pet peeve: using a language's internal array types as an ad hoc structured type. This occurs most commonly in languages like Perl and PHP (which have easy to create array types) for functions which need to return "more than one value", for whatever reason. The correct thing to do is to declare a class to hold the necessary values and return that object. Instead, many lazy programmers instead pack the values to be returned into an ad hoc array. MediaWiki is full of instances of this. (I am guilty of it myself, having done so many many times in throwaway code.)

Second, a grouse about languages that allow code to manipulate the (global) symbol table. For example, PHP has a function called "extract" which instantiates new global symbols on the fly. Such techniques make for difficult to maintain code -- they cause variables to appear out of nowhere. This makes static code analysis very difficult (in many cases impossible) because there's no way to know what variables will exist without actually running the code. All great ways to make code difficult to maintain -- and even harder to convert to languages that don't allow for runtime alterations to global or local symbol tables, which is most of them. A similar, but slightly different, nasty behavior is PHP's mysql_fetch_object, which creates an anonymous object whose instance variables correspond to the fields returned by the database query, which (again) cannot be absolutely known without running the code.

Both of these are examples of convenience techniques that surely make life easier when writing quick and dirty throwaway code, but should never be used in any application intended to be maintained over time and especially by more than one or two programmers.