|
Can your (human) clients differentiate between 0 (zero) an O? A l and 1?
|
|
|
|
|
In every accounting system I've ever used, your assumption would be wrong. 
Will Rogers never met me.
|
|
|
|
|
Roger Wright wrote: In every accounting system I've ever used, your assumption would be wrong.
Then perhaps, I'd rename that to accountIdentifier or accountId.
|
|
|
|
|
So far, no matter what, a great potential for confusion arose between CP members, imagine in between non-hamsters.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
"Our heads are round so our thoughts can change direction." ― Francis Picabia
|
|
|
|
|
Hungarian notation or not, just leave out the damn underscores!!!
Randy
|
|
|
|
|
I'd say that symbol vs meaning is philosophically always going to make that perfect symbol an impossibility. Code should be self-documenting, but any project should also document beyond the code!
My rule of thumb is to use Hu for distinguishing type details (zero-termed, length-specified, pointer or value, etc.) especially in COM, say; and for module-level designation. For me, I think it's fair to make a person look into what a variable is/means, but its symbol should let them know where to look. What bugs me are magic symbols that just appear in a tight context, like a function.
JonShops -- Fun really begins with the words, "So what in the World do I do now?"
|
|
|
|
|
Are you going to add accountNumber's together? Are you going to divide on accountNumber by another one? An ex-coworker of mine use to make anything called a number (SSN, phone, account) a numeric type and it would drive me crazy.
|
|
|
|
|
gritter55 wrote: Are you going to add accountNumber's together? Are you going to divide on accountNumber by another one? An ex-coworker of mine use to make anything called a number (SSN, phone, account) a numeric type and it would drive me crazy.
Are you going to concatenate, substring, replace, index any accountNumber?? For that matter, are you going to apply any methods of any type??
That make for a bad argument for why not to use a type. Anything called a Number being expressed as a numeric type would allow for the best space efficiency. Number quantities expressed as strings would result in faster display routines--still slower transfer between function calls or network protocols.
Simple answer: Use the type that allows for readability.
|
|
|
|
|
AccountID....
Guid? Uuid?
|
|
|
|
|
Then you would be wrong if you were using data from my Database. I only use numeric data types for data on which you can do math. You would never want to "add" two account numbers - maybe some sort of concatenation, but never add.
"You can't do today's job with yesterday's methods and be in business tomorrow." -- Anonymous
So,
"Never interrupt someone doing what you said couldn't be done." -- Amelia Earhart
|
|
|
|
|
|
accountNumber in some cases would be a string. Just because it says "Number" doesn't mean it is an integer or a double.
|
|
|
|
|
Is accountNumber a decimal (1234) or a string ("1234")?
lAccNum, lAccountNumber, sAccountNumber, pcAccountNumber are more descriptive.
|
|
|
|
|
I've never liked it from the first time I saw it (it was in the standard at one place I worked -- using C) and I never use it in my own code. It's silly and you would have to change the variable name if you change the datatype.
Having said that; here's the right way:
http://www.joelonsoftware.com/articles/Wrong.html[^]
|
|
|
|
|
This has always bee my point of view on Hungarian.
If you're using Hungarian to show you type info (i.e. compiler types, not semantic types), then you're using Hungarian wrong. Wrong Hungarian = bad. Right Hungarian = good. I currently don't trust anyone on my team to write "right Hungarian", though, so we outlaw it altogether at my workplace.
|
|
|
|
|
Right vs. Wrong: it's just not that simple. A lot of the things in the world of development are personal preferences. The starter of this thread likes Hungarian; you guys don't. No big deal. Personally, I find Hungarian to be very handy *a lot of the time*. Not always. I maintain that it's a bad idea to be hard and fast on topics that are really just "programmer prerogative".
(I don't use notepad to read code any more but, jeez, if you're stuck with that ... Hungarian would be great! 
|
|
|
|
|
|
Same answer as NagyV
Regards.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Having re-read the article, there is a distinction between App Hungarian and the loathed System Hungarian. In the original, the notation denoted the usage type rather than the data type. This means the data type may change, but the notation does not.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
|
I worked on a project where one of the data types changed. Then you have to go through the code and change the notation everywhere that variable is used. Pretty easy with search and replace, but doesn't need to be done if you just use proper naming.
|
|
|
|
|
That also has a pretty negative impact on source code control, resulting in changes across multiple files that would otherwise be unnecessary.
|
|
|
|
|
I read 'nation' to start with and I was ready with  , but I'll forgive you. This once.
Hungarian notation works, as you say, well and you always know what the data type is.
If you don't use it then you need to go back to the point in the code at which the variable was defined. This was indeed a problem using old fashioned non-contextual editors. With the use of modern IDE's, you can easily see the data type because of IntelliSense.
I personally do not use Hungarian notation anymor, but I understand and appreciate its usefulness.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Nagy Vilmos wrote: I personally do not use Hungarian notation anymor
Nagy Vilmos?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
It's far too easy to get really anal over naming conventions. Whilst I no longer use Hungarian I can't condemn anyone that does. Why? Because there is nothing wrong with it as long as its use is applied consistently throughout the project. Yes, it might look a little weird to me, but my code might look weird to you; doesn't mean it's bad code; just means we have differing naming convention preferences.
Do what you want as long as it does no harm.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
oh_AndHereIsAnExceptionColumnForYouBuddetteGals_JustInCase 
