Back in the pre-dawn of time (around 1999/2000), in the time of COM, we had an in-house utility DLL that was used to determine if a user had permission to a particular resource within our application. It is literally 15 lines of code and is used in many other objects.
The DLL was named “security.dll”. To repeat, it was a COM DLL.
Occasionally, nay, randomly, our applications started crashing in horrible ways. Do you see the problem? We didn’t for a long time.
It turns out that Windows NT had a “security.dll” for “Security Support Provider Interface” functions.
When we registered our “security.dll” lots of interesting things happened – especially when trying to access network resources…like the database, for example – which we do a million or more times a day.
That was the birth of our Naming Convention Standards Document which later evolved into our Coding Standards Document. We agreed to use Hungarian Notation. Trivia: I noticed in that linked article that it’s called “Hungarian” because of the way Hungarians use the reversed form of their names (Last Name, First Name, as in Data Type, Descriptive Name)).
All applications are now named with a “PHC_” prefix. “security.dll” became “PHC_Security.dll”. Our variable declarations start with a 3-letter data type prefix. (strPayerName, blnFinished, intClaimCounter etc). We do not, however, prefix our method names – not quite sure how it came about that we skipped that part of naming convention “theory”. Perhaps it was an intuitive agreement with Linus Torvalds:
Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged – the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.
(lol!)
Perhaps, if Microsoft had used the convention of prefix naming their objects, they’d have named their DLL “MS_Security.dll” and we’d not have wasted a week crashing our production servers with a poorly named 15 lines of code.
Now that we are on .Net and the VS IDE does so much to make code readable, it could be argued that it is no longer required to use a specific naming convention.
I argue otherwise. Having this standard (and others like it) in place encourages (enforces?) a kind of coding discipline, in my opinion.
I am very particular about code readability. I do care about code that works – don’t get me wrong – but I care deeply about code that looks good. I am obsessive about how the code looks. It must be pretty! My eyes bleed when I see this type of code:
<snip>....some while loop code up here
If i = Len(name) Then
If Quit = False Then
If ins + 1 = 200 Then
previous = i
i = Len(name) + 1
Else
GetParms = ""
Exit Function
End If
End If
End If
</snip>....end of the while loop down here somewhere
….somewhere, someone just killed a kitten because I posted that snippet.
The impression badly named and badly formatted code leaves me with is: “this developer has a cluttered mind, and is most likely writing code that breaks very easily. I am with illogical”.
This prejudice I have proves itself often enough to reinforce it for me (prejudices are funny that way). Sloppy code would kill our company with the number of times we refactor production code.
We have retained the tradition of specific naming standards in our .Net code. As we have grown, and have more developers interacting with each others code, the coding standards that were created from the “security.dll” incident has made a definite improvement in our productivity and in the quality of our product.
Read: A Taxonomy for “Bad Code Smells”
