July 8, 2005 at 3:27 pm
Yes, I agree with Andy's premise about IDing the data type of a column as a naming standard and should have said so. I was just trying to make a point about the example he used, which in this case probably warrants a name change. BTW, I'd probably use "s" to ID character based columns.
July 8, 2005 at 5:15 pm
I dont personally use the Hungarian so I wouldn't end up using it on the tables anyway, but if you wanted to, I dont think its as big a pain as its made out to be to do a global find and replace. You can find every view, sp, udf, etc. that use the column name by using the syscomments table and then you can just do replaces based on that. Not that this is the ideal solution but its not all that bad.
July 8, 2005 at 6:56 pm
Don't forget to change all the calls for all those objects in tha application. Then retest the whole app to be sure you didn't forget something. Now that can take sometime.
July 9, 2005 at 4:20 am
Sure but now you are in no worse condition then if you were to use hungarian with just a regular vb app.
July 11, 2005 at 7:26 am
On other hand, if you are changing from a CHAR column to a non-textual data type, you will need to go through all your code and change the logic. Even changing from a CHAR to a TEXT column you will still need to change the business logic since the column size would have changed. (We all do add sanity checking code before adding data, don't we?)
When I access a table column from VB/C#/whatever, the variable I assign to the column is named the same as the column. Why shouldn't it be? It's the same data! I do use hungrarian notation, but only as a convenience for ensuring that all my developers are coding in the same manner. It's a disclipline that helps them ensure consistency across the development team.
Finally, one reason why I like changing the column name when the datatype changes is simply that existing code will break. There is no choice but to find all uses of that column name, review the business logic and update the code accordingly. It's harder work, but it ensures that you have covered all uses of that column.
Mike
July 22, 2005 at 8:21 am
Hungarian Notation is critical in long codes. My guess is, this should not be the case in set-oriented store procedures: fewer vars. So, as long as no one takes this as a license to forget set-oriented code, everything would be fine: a standard is always a plus.
And here it comes CLR... the code sure look nicer.
From experience: when you migrate, for example to Oracle, the included tools that re-script your stores (from TSQL to PLSQL), would generate more readable code (longer because the intense use of exceptions).
July 22, 2005 at 9:37 am
Andy, I like the topic!
I have been a DBA for almost four years and a programer for over five years. Personaly I like using HN in my code and DB design, since it makes it easier for me to "remember" my data type. I have however made some decisions with using HN when it comes to changing data types (I have enough experience now where that rarely happens anymore!). If the base data type does not change I do not change the first letter of the code, i.e.: tinyint, int, and bigint all get the first letter as "i". With proper analysis of what my end users needs are I have not had the need to go back and change my columns names.
With reguards to stored procedures, if you start a stored procedure (SP) with "sp_" the database will look to the master DB first then the user DB. This is a performance hit on the server since it is looking in two different places for the correct SP. Personaly I will name a SP after the DB where it is pulled from. I.e.: Database = HumanResources, I have a SP that looks up staff, or makes modifications to staff,then the SP name would be: hr_staff_select, hr_staff_modify, and hr_staff_delete. Someone else may have posted the samething with the master DB vs. user DB, but I do not have the time to read all of the posts.
– Albert Einstein
December 5, 2005 at 2:45 pm
Ahhh, Hungarian notation. Charles Simonyi. If you want to start a programming religious war, very little is better than a discussion of Hungarian notation. Microsoft institionalized it in the 90's, then with .NET said "No more Hungarian notation for you!". Just another reason that Microsoft drives me crazy (but it's a love/hate relationship).
John Scarborough
MCDBA, MCSA
December 5, 2005 at 3:35 pm
Andy, I agree in general with everything you wrote. Hungarian is great for coding but bad for columns. However, I've been using a naming convention for column names that isn't Hungarian that I very much like and it keeps my column names consistent. Rawheister posted a similar example earlier, but here's mine:
a column for storing the total for an invoice would likely be: total_amt (indicating a dollar amount).
or a column storing the quantity for an invoice row might be: item_qty (indicating another numeric, but this one is quantity).
Now what type of numeric I used isn't given by the naming convention, but it's very easy to tell at a glance how the column is used in relation to the business. Baring a change in how the business uses the data, renames are unlikely.
Heres a subset of the other suffixes I use:
_txt (freetext data)
_cd (validated text data)
_amt (amount of something)
_qty (quantity)
_no (unique number such as a PO number, could be either numeric or alpha, or numeric stored in an alpha field)
_id (similar to a _no, but generally system-generated, either numeric or alpha)
_sz (size, such as the height)
_val (some other type of numeric that doesn't fit in another numeric category)
Anyway, I'm sure people have their established conventions. As long as they're consistent and generally logical, I think they help a lot.
May 9, 2008 at 6:37 am
Andy, to start - thanks for these posts on BP/WP, but as a veteran software developer with over a quarter-century in the biz you've hit upon the one peeve that has always raised my ire. Hungarian notation!!! Let me first say that although your BP/WP monikers are nice - you have forgotten the middle road - CSP - Common Sense Practices. It still amazes me how I see young developers marching in lock-step to concepts without enacting any common sense.
For over 25 years I have crunched code and in virtually every editor I have used since the world went graphical, I use the Arial Narrow font to get as much code on the screen as possible. Try doing that and you will quickly see why so much Hungarian notation is totally useless. In fact, it seems the world presumes we all write code in Times Roman or Courier where Hungarian notation is very distinctive. Put it in Arial Narrow and suddenly, many prefixes are not discernable.
This is NOT to say I do not use some Hungarian notation and can see its value. Sure, when I have screen objects, its very helpful to see "txt_Name" and of course, know that this object is a textbox that has something to do with a name. Makes good sense! However, watch as I am about to list a variable without Hungarian notation - and lets see if you and your readers can tell what it is...
m_Payroll_Total
Now, I could get very sarcastic of course, but does anyone have any trouble realizing that this would be a variable having something to do with Payroll Total? And how many developers would need to be told "Payroll is a number". I have yet to meet a developer who thinks we are paid in anything but numbers (eg, dollars).
What I am saying here is that Hungarian notation is a good guideline and has a lot of common sense applicability to it. But I have also had many developers work for me who are so heck-bent on Hungarian notation that doing code reviews takes MORE time than less. Why? Simple...
These guys are "Hungarianing" their code all over the place and yet put NO comments in their code!!! My point?
Give me a developer who comments code and uses basic common sense when naming variables, objects, etc. - and he/she will blow away any devotee of Hungarian notation in an instant.
On the other hand, give me a developer who is so devoted to Hungarian notation that he/she wastes hours (!) going back over code to make sure everything is named properly, and I will quickly switch that font to Arial Narrow and watch that developer see the light.
Comments and common sense will take code and we developers a lot further, that any lock-step as to the 'best' way to write code.
May 9, 2008 at 11:18 am
I've been a developer for over 20 years: Fortran to VB3 to VB6 to C#. I've been an MCSD since 1997 and an MCDBA since 2001. And I disagree with your position on type prefixes for column names. I write a lot of C# code for web pages and WinForms, and also design their supporting databases. I find it very useful to use column name prefixes like tntCultureID, sntCustomers, intOrders, bntOrderDetails. I especially like to distinguish between strCustomerID and intCustomerID, since the vanilla name does not give a clue as to the actual type.
When a decision is made to change a type say from blnState to tntState, it is not necessary to rename the column and its references in stored procedures and in ADO.NET parameter declarations. But it is necessary to change the type declarations, so why not change the name for consistency while you're at it? Not changing the name is a worst practice! Having no prefix saves changing names, but you still have to change type declarations, any you lose the benefit of knowing the type immediately.
I agree with most of your other Worst Practices, but certainly not with the one you've chose to lead with.
May 9, 2008 at 1:27 pm
Yes! Somebody, please kill Hungarian notation! There is no appropriate place for it, IMO.
Modern development environments have made Hungarian outdated.
First, there are too many types and scopes available. Developers often switch contexts and the prefixes vary by context. The prefixes one might use in SQL differ from those used in VB, which differ from those used in MFC C++. Honestly, reading the previous post, I do not know what all those prefixes mean. Do they refer to type? Scope? Usage? All of the above?
Second, limitations on the length of names are no longer a seriously limiting factor. Many development environments have an auto-complete (Intellisense, e.g.) that means you only have to type the long name once.
Third, develpment environments are making it easier to quickly find the type of a variable or definition of a table.
There are certainly cases in which the name should reflect the type or usage of the variable. Use a full-word suffix for this! Converting a customer id from string to int? Try: CustomerIdString and CustomerId (no suffix, because int is the canonical form of the data in this example). Text box for entering a US state? StateEntry. This can be changed to a combo box without changing the name--it's still a control used for entry of a state value.
I yield on prefixes to indicate scope, but prefer non-alphabetic scope indicators. SQL does this already by using @ for variables, # for temp tables, and dot notation for columns. In C#, I use leading underscores, differences in casing and dot notation to indicate scope.
May 12, 2008 at 11:51 am
On a historical note, Stanley Leszynski and Greg Reddick came up the most used Hungarian-based naming conventions back in 1992 for MS Access VBA, which found its way into general VB usage. It is interesting to note the Leszynski and Reddick eventual split on the usage of the Hungarian notation as applied to data column names and became the Leszynski standard OR the Reddick standard.
I have always sided with Stan, who opposed usage of type notations when it came to column names. In the old Client/Server days where variables and direct access table field name where scatterred throughout one's code, it was easy to tell if name was a variable reference or a field reference by the presence or lack of a type prefix.
Today's n-tier Object coding usually require seperation of back-end access from logic and front-end code and we don't see the mixing of data and VB or C# code like we used to see. Therefore, either standard is good. In fact any standard is good as long as you have one and it is used consistently through your applications. It is the practice of a random usage of different naming conventions with no naming convention at all that is the biggest WP, which can be seen over and over again in many applications that were rushed to production.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler
Viewing 13 posts - 61 through 72 (of 72 total)
You must be logged in to reply to this topic. Login to reply