Are you a prefixer? And by that I mean a developer – or DBA – who uses prefixes on object names? [DISCLAIMER: I’m a reformed prefixer – ok, almost reformed…]

Long ago and far away, I began my career writing Windows applications in C. Most of the coding was done in a text editor, and Hungarian notation (as we called it commonly) was sort of useful, as it would remind you that iCounter was an integer long after the declaration of iCounter had disappeared into the upper reaches of the scroll bar. But even then, there were naysayers among us. Was i the best prefix for an integer, or n? And what size integer are we talking about? Sure, you could use l (is that a lowercase L or an uppercase I?), or maybe d (but did that mean double or decimal?), but how much information were you really imparting with that prefix? And then there were more complicated schemes where i or n was replaced with int, and then came arr_int for an integer array, and so on. After a while, the whole thing just gave me a headache.

When I moved over to database development, I found the same arguments raging there. The use of “tbl” to designate a table had been pretty well pounded out of everyone, but “sp”, “ix”, “fn”, and their ilk still prevailed. And lo and behold, here was @iCounter once again. Damn.

The longer I thought about it – and talked about it with colleagues – the more I came to the conclusion that prefixes are now just useless anachronisms, at least in the database world. Perhaps it’s still a necessary evil in C# or Java or whatever the language of the month is, but I can’t see why. Modern IDE’s will tell you everything you ever wanted to know about an object just by hovering the mouse pointer over it, and right-clicking will let you drill into details deeply enough to numb the most inquiring of minds. But for a database? Methinks not.

After all, why on earth do you need IX (or IDX or whatever) to tell you an object is an index? It’s under a folder named INDEXES – what the hell else would it be? Unless you think Microsoft evil enough to slip a stored procedure in now and again, just to see if you’re paying attention. And why do you need “sp” to tell you a stored procedure is a stored procedure?

I do make an exception for constraints, because they all get lumped together in one folder, defaults and foreign keys and unique alike, with nothing to discern one from another at a glance. So FK and DF and CK and UN I will tolerate, but grudgingly, because I think MS ought to provide the same information for constraints as it does for indexes (clustered, or non-clustered, unique or non-, etc.), and really, it can’t be that hard to do. And I have occasion to write stored procedures requiring “sp_” (which if you’ll recall doesn’t mean “stored procedure” but “special”) just so I don’t have to type “master” in front of it every time I invoke it.

I don’t see any use for them on variables, though, because they just don’t impart enough information. OK, @sFirstName is a string, but is it variable length or fixed? And how many characters does it allow? ASCII or Unicode? Oh, here, put the mouse over it, and there you have it: varchar(20). Much better than a prefix, right?

I haven’t banned them outright – we have too many application developers writing stored procedures. Their standard requires them to use prefixes, and it would be cruel and unreasonable to insist that you can use them here but not here. So I let them name their variables thusly, but draw the line at objects. No “IX” in front of the indexes, please, and your stored procedure will run just as well without “sp” in front of it. And no, no one is going to get confused if you have a table named Customer and a user-defined table type of the same name.

Are you a prefixer? Do you find them useful, or a nuisance? Let me know – I’d love to hear the arguments in favor of them.