Type Prefixes
(Programming)

There was a period of time, back in the day, when variable prefixes which represented the type of the variable were all the rage. I remember seeing these all through code in a variety of languages, particularly C and C++. I don’t know if this practice continues, as I haven’t particularly examined a lot of other people’s code lately. But my opinion of it at the time and now is that it is a silly idea.

This is particularly true in scripting languages like PHP, where the value of a variable may be changed by the language, depending on the circumstances. PHP will convert a text string to a number under a variety of circumstances, and now your “type prefix” is useless. This may be true of any language where typing is fluid. And this includes most scripting languages. And a lot of software today is written in scripting languages.

One reason for using this convention is that, with the advent of “object oriented programming”, new types can be fabricated on the fly. You can create a class call “Triangle” and trot around a whole bunch of objects which can be operated on using methods from that class, and possibly even native operators from the host language.

If you have so many variables floating around that you can’t keep track of their types, you might want to reconsider your coding practices and paradigms.

There is only one case where I’ve thought it might be useful to use type prefixes: dates. In my code, I may have a date as a date object, or a string which represents the ISO 8601 representation of a date. In fact, with my date class, it is designed to work with strings formatted in any number of ways, but all representing dates in one way or another. So I could use the “d” prefix for actual date objects, and the “s” prefix for strings which represent date strings. But this is why I try to make my functions (or class methods) short, and document my code extensively, so that I explain that a variable is a date or a string. If you’re going back to debug or alter the code later (particularly if you didn’t write it), you’re well advised to read the docs along the way. And curse programmers who just write bare functions with generic names and expect you to figure out what’s going on later.

So that’s my story and I’m sticking to it. ;-)