Worst Practices - Part 1 of a Very Long Series!
-
you have brought up an interesting WP, as a coder, primarily i would use this sort of notation against variables, and as my role has moved into database design etc, i now can see how this can affect table structure from your article, funnily enough i had to write a style guide for naming conventions and just implemented this style of naming convention into database structure, as such i will now be "reviewing" what ive wrote and change them !!(mind you original naming conventions were non existant and some fields were 20 chars long for a field name!!)
my only question/defence is, how many times do people change their database structure?? straight off the bat i would say not often , so how bad a wp is hungarian notation ?
Cheers
APM
------------------------------
Life is far too important to be taken seriously -
Recently while reading "Data & Databases: Concepts In Practice" by Joe Celko I came across the NCITS L8 standards. Of particular note is the following from part 4 (ISO 11179-4)
A data definition shall:
a) be stated in the singular
b) state what the concept is, not only what it is not
c) be stated as a descriptive phrase or sentence(s)
d) contain only commonly understood abbreviations
e) be expressed without embedding definitions of other data or underlying concepts
I suggest if you can get a copy on the web or order from ISO that you take a look at it to help develope your naming standards.
-
Hm, I thought the book is out of print, isn't it?
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
I am an EBay fanatic. Haven't gotten finished yet and I realy want to get to "An Introduction to Database Systems" by CJ Date I picked up not long ago.
-
I am an EBay fanatic. Haven't gotten finished yet and I realy want to get to "An Introduction to Database Systems" by CJ Date I picked up not long ago.
For some reasons our admin locked access to ebay from work. And from home with a 56k modem it's not really fun.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Andy,
I have to disagree that Hungarian is a BP. To me, a much more serious BP is inconsistency. I use the same name for a field, whether it is in a table, a view, a sproc parm, a sproc variable, whatever. It's the same field, with the same info in it, it has to have the same name! Now, I happen to use Hungarian, but as long as I use the same naming convention throughout, it doesn't really matter what that scheme is.
And if you have to change a column from a bit to a tinyint (a) you probably didn't follow BP when you designed the table, and (b) to use the new field appropriately, you are going to HAVE to change your code, declarations, etc. to take advantage of the new data! So if you have to change the name, that, to me, is a good thing - it may at least cause you to look at each line of code...
Dave
-
Andy,
Well said...
David,
While consistancy is important, it's equally important to allow variables and entities independence from their underlying type. What about the situation where a select statement is now selecting from a User Defined Function or view rather than a table? Do you prefix udf_ for UDFs or vw_ for views? At some point, the notation becomes more distracting than beneficial. I realize we're not talking about OOP here, but program against an interface, not an implementation. In other words, keep the naming conventions consistent, but allow the underlying type to change without having to change the name of the variable.
If you're creating databases that don't change, you're ahead of 100% of the rest of us. Changing the data types is necessary, but changing the name shouldn't be. What about select statements based on those fields?
Eric Theil
-
I disagree with the use of Hungarian notation of any kind (object names/primitive names/table names/field names/etc.), especially in today's age of comprehensive IDEs. First, Hungarian notation violates a key rule of software/data design -- do not duplicate information unless you absolutely must do so. Including a type indication in the name duplicates the actual formal type definition, and as has been pointed out, these can and will get out of synch over time. Second, Hungarian notation makes it more difficult to read software as if it were a book -- you have to remember to "skip" the first letter of the name to have it make sense as you're reading it. Third, today's IDEs make it very easy to identify the type of an attribute/object without having to compromise the name. I recognize that many people do not currently use IDEs, historically because of cost, but that is quickly changing with open source IDE products.
Of course, you have to do what's best for you and/or your team; however, in a large scale application, Hungarian notation quickly becomes a hindrance rather than a help.
-
I'd like to help spread the word that HUNGARIAN NOTATION IS NOT ABOUT INDICATING THE PHYSICAL DATA TYPE.
-
As far as hungarian notation goes I have 2 points to make:
1) With SQL IDEs like Imceda's SQLIDE Pro there is no need to use any Hungarian notation because the drop down tells you exactly what data type a column is. So there is no need to scroll up to the DECLARE statement. As the time passes by more and more of these tools will come up and this should alleviate many of such small problems for a DBA
2) As far as VB goes , my experience with VB .NET has shown that properly written code does NOT need Hungarian notation. Plus, the Visual Studio .NET IDE shows you what data type a specific variable is. So there is,again, no need to use Hungarian notation
Just my 2 cents
-
That, and the fact that in an object oriented world, hungarian notation no longer makes sense. Everything (pretty much) is an object. Are you going to put obj before every variable?
Besides, with casting and reassignment a variable could be a decimal at one point in a program and an integer at the next. Not the best practice of course, but it COULD happen.
-
I like using something to differentiate variables from other code, especially non SQL languages.
for iCounter = 1 to 10
instead of
for counter = 1 to 10
Of course, I'd be happy with the same prefix for all variables.
-
I've also used a convention like that Steve. In my last development group, we prefixed parameters with a "p", local variables with an "l" and member variables with an "m". This worked out fairly well for us and certainly helped separate types from variables (along with scope). Good suggestion.
-
How is having a column named "bIsComplete" vs. "IsComplete" any worst when is comes to changing the data type from bit to tinyint? So now we would rename "bIsComplete" to "iIsComplete", I don't think so. The point is a data type change probably warrants a column name change.
-
You think? What about if you want to go from a CHAR column to a VARCHAR column or a VARCHAR column to a TEXT column? Does it really seem necessary to recode all of your stored procedures with a new name when they are still just interacting with a text field? Your data logic could very well remain the same, but now you have to go through all of your code and make changes in order to comply with a naming convention. Seems like a lot of with with very little benefit.
Viewing 15 posts - 46 through 60 (of 72 total)
You must be logged in to reply to this topic. Login to reply