views:

336

answers:

3

I know that there is so many standards for writing code. and some policy tools (like FxCop) to check your writing statements.

What's the best hungarian notation or any other snippets for writing codes?

Like:

  • lbl in start of naming a Label

  • txt in start of naming a TextBox

, etc.


Update : So based on the answers, Is it a good Idea to use Hungerian notation or not ?

Also, I marked it as a community wiki

+5  A: 

"Hungarian notation" has been the subject of many zealous debates in the programming community. Joel Spolsky has a well-noted article defending smartly used hungarian notation I find worth reading.

As for a list of prefixes to use in hungarian notation: I don't think a general list of such prefixes exist, as they would differ from programming language to programming language. The Wikipedia article lists a few; otherwise, I think you would have to refer to coding standards manuals of platforms / frameworks in your area that use hungarian notation.

Pekka
I disagree with Joel. If you need (or want) that much safety, define a type to hold each type of variable and disallow implicit casting between it and anything else. Using variable names is just seems a bad way to do it especially as the compiler still lets you implicitly cast between the "types" defined by variable name.
Yacoby
@Yacoby depends on language. I mainly work in PHP-based web development these days (which does not support type declaration of variables, and is not type safe), and clever use of the notation can be a godsend there, e.g. to distinguish between sanitized/unsanitized input, HTML snippets, pixel / colour values, and so on. You get direct visual feedback on what operations you can do between what variables or functions. I'm playing around with it at the moment and not sure whether I'll adopt it long term, but it is worth considering.
Pekka
@Yacoby - Joel is referring to being able to look at code and spot errors. Apps Hungarian doesn't have anything to do with enforcing type safety so much as providing a visual signal that something is wrong. The examples Pekka gives are excellent uses of what Apps Hungarian is for. I had always thought that using actual `type` identifiers in a variable declaration was useless (i.e. the Systems Hungarian).
dboarman
@dboarman I have no problem with people trying to reinvent type safety, but it will never be as good as when it is inbuilt. For example, Joel said he that it allows him to visually *see* if something unsafe is being done. Using two different types my compiler doesn't allow me to do that, irrespective of variable names. In other words I cannot compile an application that is wrong.
Yacoby
@Yacoby this is about more than simple type safety. Consider a variable containing a pixel width; a variable containing a counter; and a variable containing a relative width in percent. All three are perfectly valid integers - and yet you mustn't combine them with each other. A smartly applied hungarian notation with prefixes like `px`, `count` and `rel` (or whatever) make wrong couplings immediately visible - especially when also applied to functions ("did getWidth()" return a relative or a pixel value?") This - and not the silly prefixing of types - is the real benefit IMO.
Pekka
+1 Pekka: that is exactly Joel's point.
dboarman
@Pekka I think you missed my point a bit, taking your example the class should return different types depending on if it is a pixel width or a relative percentage width (It makes the API far harder to misuse). I do understand that it is hard/impossible to in dynamic languages and if you are using a dynamic language for whatever reason I don't really have a major issue issue with it.
Yacoby
In summary, it seems to me that using apps hungarian notation is making up for a failing in the language design and a far better solution is to use a "better" language (Although ofc a lot of the time this isn't possible). I wouldn't have an issue with Joel's article if he added a line on how it would be much better to use language features rather than variable names where possible.
Yacoby
@Pekka: the solution is to create a type for Pixel and another type for width - you will then not be able to mix them inappropriately, yet you won't have to change how you name your variables - the language will prevent the incorrect access.
John Saunders
@John @Yacoby True, good point when you work in a compiled language that 1.) can do that, 2.) won't accept mixed assignments and 3.) Has an IDE that is able to provide real-time information about the variable you are currently working with. Makes me think... But then, switching languages isn't easy in many, many lines of work for various reasons.
Pekka
+4  A: 

With respect to your example with lbl and txt: this is not hungarian notation in the classical Charles Petzold sense, just prefixes/naming conventions.

Microsoft has a list of these. Excerpt:

    Prefix    Object Type                           Example
    -------------------------------------------------------
    ani       Animation button                      aniMailBox
    cbo       Combo box and drop down list box      cboEnglish
    chk       Checkbox                              chkReadOnly
    clp       Picture clip                          clpToolbar
    cmd (3d)  Command button (3D)                   cmdOk (cmd3dOk)
    dat       Data control                          datBiblio
    dir       Directory list box                    dirSource
    dlg       Common dialog control                 dlgFileOpen
    drv       Drive list box                        drvTarget
    fil       File list box                         filSource
    frm       Form                                  frmEntry
    gau       Gauge                                 gauStatus
    gpb       Group push button                     gpbChannel
    gra       Graph                                 graRevenue
    grd       Grid                                  grdPrices
    hsb       Horizontal scroll bar                 hsbVolume
    img       Image                                 imgIcon
    ink       Pen Ink                               inkMap
    key       Keyboard key status                   keyCaps
    lbl       Label                                 lblHelpMessage
    lin       Line                                  linVertical
    lst       List box                              lstPolicyCodes
    mdi       MDI child form                        mdiNote
    mnu       Menu                                  mnuFileOpen
    opt (3d)  Option Button (3d)                    optRed (opt3dRed)
    pic       Picture                               picVGA
    pnl3d     3d Panel                              pnl3d
    shp       Shape controls                        shpCircle
    spn       Spin control                          spnPages
    txt       Text Box                              txtLastName
    tmr       Timer                                 tmrAlarm
    vsb       Vertical scroll bar                   vsbRate
Peter Mortensen
Your link is broken.
John Saunders
@John Saunders: thanks for the notification. The Microsoft link is not broken for me. I just checked it again. Including opening it in two other browsers (Opera and Chrome). Do you get a 404? The link: http://support.microsoft.com/default.aspx?scid=KB;en-us;q110264
Peter Mortensen
@Peter: it took me to their "smart error" page. Now it works for me too. In fact, I saw http://support.microsoft.com/default.aspx?scid=KB;en-us;q110264#rtDisclaimer, which I think you should include in your answer.
John Saunders
@John Saunders: as far as I can see the only difference between the two URLs is the reference into the page, "#rtDisclaimer". Should that make a difference?
Peter Mortensen
This is the only time I use any sort of prefix - any object that inherits or derives from `Control` or `Form`.
dboarman
@Peter: I meant that whatever was broken is now fixed. It's fixed enough that I found the disclaimer yhat you will read if you follow the link I posted. This is old information. You haven't found a murder victim - you've found a fossil.
John Saunders
@dboarman: why even do it with controls or forms? What if you change the control type, from a ComboBox to a ListView?
John Saunders
@John - so I can remember what control it is. Note, though, that I didn't say I left them named like that. Anyone who looks at my UI code will know what the control is that is being coded. Once it is finalized and fully implemented, we may change the name to something more meaningful to the control's purpose. Until then, we like to know what the type of control it is. Might seem kind of weird to do it that way, but it works out - makes more sense than using prefixes for int, double, string, etc.
dboarman
@dboarman: well, to each his own. I prefer to name controls based on what the represent, then maybe apply a suffix: "OkButton" rather than "btnOk".
John Saunders
+2  A: 

The Microsoft Framework Design Guidelines, under General Naming Conventions says:

Word Choice

Do choose easily readable identifier names. For example, a property named HorizontalAlignment is more readable in English than AlignmentHorizontal.

Do favor readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).

Do not use underscores, hyphens, or any other nonalphanumeric characters.

Do not use Hungarian notation.

Hungarian notation is the practice of including a prefix in identifiers to encode some metadata about the parameter, such as the data type of the identifier.

John Saunders
Apps Hungarian seems like it should have been perfectly fine. If the documentation writers had just asked for some clarification from Simonyi, I think Apps Hungarian would have a better reputation and more widely accepted. Of course Microsoft could have given Apps Hungarian a little more support and clarified the differences - instead Simonyi is left looking like he'd just re-invented the Edsel.
dboarman