Naming Conventions

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”

 

Moved to here…

A little about the development environment at Passporthealth:

The company was founded in 1996 – around the time Mr Gore invented the internet.  I believe I was the 9th developer hired, 7 of us still work here.  It started off as a Microsoft, VB6 shop and has remained on the MS, VB path ever since.

Our users connect to us via our website portal to verify patient data and eligibility for services via a number of our products.  We have products that allow single web based interactions, file batch transactions and EDI socket transactions.  Each of these various types of requests usually result in a connection to a 3rd party to lookup or validate various patient information.  We store, analyze and embellish all this data and serve it back to the requesting users.  Sometimes this is an immediate response via the web browser, and sometimes we script or post the data back directly into the client’s HIS systems.

Last year we processed over a 100 million such transactions.  This transaction volume and workflow creates tremendous architectural challenges for our IT team.  We have vast quantities of data that are written to, searched, and re-written to.  Our array of products crosses over from data-warehouse driven type applicaitons, to real time transaction processing functions. 

We have tight relationships with our clients where we are intimately involved in their daily work flow;  they depend on our availability and performance to effectively do their jobs.  Delays, or errors caused by our vendors and partners, are our errors.  We’ve successfully (imo) coded and architected around these challenges and this has allowed us to become a dependable supplier of information and utiltiy to our clients.

We have some extremely bright, dedicated and devoted developers.  We solve these complex problems in unique and interesting ways every day, and our company rewards us with a great environment to work in.

My plan for this blog is to talk about those challenges and explore some of the specific solutions.  Perhaps you’d like to read and comment…