2

I've stopped using Hungarian notation everywhere except in the UI, where often I have a username label, a user name text box, a user name local variable, a required field validator, a user name property and method parameter so on, often all in the same context.

current: lblUser, txtUser, rfvUser, _User, User, user

If I do the obvious, UserLabel, UserTextBox, UserRequiredFieldValidator, it seems like I'm just substiuting longer suffixes for shorter prefixes.

And the _ for indicating field, gets flagged by FxCop, but without a prefix, it would clash with the approved User/user convention.

Any suggestions?

MatthewMartin
  • 32,326
  • 33
  • 105
  • 164

4 Answers4

4

I still generally use Hungarian notation for UI objects as I find it makes my code more readable.

I would use things like m_firstNameTextBox or m_countryComboBox for the UI controls and then m_firstName and m_country for the string values from those controls.

At the end of the day you should use whatever you prefer. The blanket rule to avoid Hungarian notation is as bad as the one that stipulates religous use of it. It's obivous that things like intCounter, strName are overkill but in other cases it does make good sense to indicate the type of class in the variable name and in my opinion UI controls happens to be one of the cases where it does make sense.

sipsorcery
  • 30,273
  • 24
  • 104
  • 155
2

There is nothing wrong with Hungarian notation, as long as it's used to make code more readable. If you think it doesn't contribute to that, then don't use it.

Ah, and please do not use both 'User' and 'user'. It's difficult to read, use, maintain and port. If two different things have two different meanings, then Hungarian notation is a better option than encoding that piece of information by flipping characters between uppercase/lowercase.

I don't know who invented case-sensitivity in program languages, but he did more damage than anyone could've imagined at the time. I hate getting compiler errors because I typed 'ID' instead of 'Id' or 'UsbDrive' when it should've been 'USBDrive'.

Allen Luce
  • 7,859
  • 3
  • 40
  • 53
Wouter van Nifterick
  • 23,603
  • 7
  • 78
  • 122
  • 1
    I think case-sensitivity wasn't so much invented as simply done by default, since it's computationally a little cheaper (at least on an ASCII system). I have the impression that more recent and higher-level languages are more likely to be case-insensitive for identifiers. – cheduardo Jun 15 '09 at 11:50
  • Yeah, it's alightly easier to compare if characters are exactly equal. Don't even get me started about unicode source code.. It's a bitch to read, and I don't even know how to type most of the characters. – Wouter van Nifterick Jun 16 '09 at 00:10
  • Well this isn't TOTALLY true, it's possible for a textbox to be changed to a combobox and a person to forget or be unwilling to change the name of the control. Making txtWhat very misleading. – VoronoiPotato Dec 31 '12 at 15:06
  • @cheduardo: The fundamental problem is not that programming languages require that variables be typed in the proper case, but rather that it is considered acceptable to have and use multiple identifiers in the same scope which differ only only in case. Were I designing a programming language, and an outer scope defined `X` and an inner scope defined `x`, then within that inner scope I would not have `X` refer to the inner-scope variable (the VB way) nor the outer-scope variable (the C# way), but would simply have the definition of `x` shadow `X` so it didn't refer to *anything*. – supercat Feb 14 '14 at 00:07
1

I prefer Hungarian even though it leads to really long names in the UI (because of problem you mentioned in question). My only suggestion is to be consistent across the entire team.

Jeff
  • 5,913
  • 2
  • 28
  • 30
1

Use all lowercase and underscores, and the case issue goes away. SomeIdiotSomewhereDecidedThisWasAGoodWayToDoThingsAndIfIFindHimIWillKillHim.

smcameron
  • 2,547
  • 1
  • 19
  • 12
  • I would once have agreed, but three years of coding somewhere that caseing variableName and TypeName are mandated has changed my mind. – CJBrew Feb 03 '11 at 13:03