Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Hungarian UIs

Hungarian UIs

Scheduled Pinned Locked Moved The Lounge
questionwpfdesigntutorial
67 Posts 39 Posters 10 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C c2423

    I think we can all agree that for the most part nobody uses Hungarian notation for variables any more... but it still seems prevalent in UI programming - for example I might have lblSomething next to txtSomething. On one hand I feel a bit uneasy that there must be some way to avoid this horrible practice, but on the other hand lblSomething is clearly meant to be a label which is next to txtSomething, and I need a way to differentiate between them without ending up with two controls with the same name. What say you? Disclaimer: I don't consider this to be a programming question, more a question of what styles people like to use.

    N Offline
    N Offline
    Naoya Yamaguchi
    wrote on last edited by
    #61

    Don't use the system Hungarian. IDEs and compilers see types. If you declare variable like "int X;" in a statically typed language, X is an int. You won't make it float or double by mistake. On the other hand, the application Hungarian notation is still a good practice. In neural network programming, an input-to-hidden weight is double, and so is a hidden-to-output weight. Compilers cannot detect an input-to-hidden variable holding a hidden-to-output weight by mistake. Therefore, anything that has to do with an input-to-hidden weight should be marked with "ih", and anything, with an output-to-hidden, should be marked with "ho". A mistake like "ihWeights[i][j] += alpha * hoPrevWeights[i][j];" cannot be detected by your compiler, but reading just that line, you see your mistake. You should not be adding hoSomething to ihSomething.

    1 Reply Last reply
    0
    • M mad god

      Just like those few people not afraid of expressing their opinion (against popular dogma) and actually using it for good, I say Hungarian notation is not bad, but good. But just like everything, it is only good when you not overuse it. I'm using it in many cases with some exceptions (when the name actually conveys the type already or when it is a number and I don't really care how many bytes it is or if it signed, etc.). EDIT: Oh, yes, forgot to mention that I'm not using the 'pure Hungarian' prefixes, I just use the principle, making sure the prefixes are unambiguous. What I believe happened, is the Hungarian notation (similar to goto operator) are being witch-hunted, which is triggered by some incompetent and overconfident tongue (or hand/pen, rather) of some wanna-be computer science study book writer (and I'm implying a bunch of quite well-known authors here if you wondered). Well, after that the sheep herd just follows. Please, have your own opinion, people, it is refreshing. Just use the practice you think helps creating clear, maintainable code, regardless of what 'they' say. :)

      S Offline
      S Offline
      Stephen Dycus
      wrote on last edited by
      #62

      The silliest part, of course, is the entire subject is subjective; there is no metric for wether Hungarian notation is good or bad. There is no performance difference in prefixing your variables. Each person's ideas of what's more maintainable is different. It's like the curly brace placement debate all over again. XD

      1 Reply Last reply
      0
      • OriginalGriffO OriginalGriff

        I have been trying to get away from Hungarian for a loooong time, but I still use txtPassword and butOK and labPasswordPrompt. The original idea of HN was good - and I think it does help to distinguish UI controls with a prefix. If only to make it easier to find in intellisense! :laugh:

        The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)

        F Offline
        F Offline
        Fabio Franco
        wrote on last edited by
        #63

        Yeah, I particularly find it useful... specially when you have lots of fields to fill... Typing txt and seing them all filtered in a neat intellisense list just makes it much easier to manipulate and avoids forgetting one of them.

        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

        1 Reply Last reply
        0
        • C c2423

          I think there's general agreement these days that it's not a good style, particularly if you want to change the underlying type of something without having to do a lot of renaming, aside from the aesthetics of it. However, everybody has seen the arguments for and against ad nauseum but I was curious as to what people do in the UI. One other exception that springs to mind is IInterface, which I don't have any problems with.

          M Offline
          M Offline
          Member 4608898
          wrote on last edited by
          #64

          There are two types of Hungarian notation. One, the original, which describes purpose and the other which many use, data types. The former has as use because it helps you understand the code and how it is used. The latter, which many people use is a waste of time, unless you are using a typeless language like BCPL, vbscript or javascript.

          C 1 Reply Last reply
          0
          • M Member 4608898

            There are two types of Hungarian notation. One, the original, which describes purpose and the other which many use, data types. The former has as use because it helps you understand the code and how it is used. The latter, which many people use is a waste of time, unless you are using a typeless language like BCPL, vbscript or javascript.

            C Offline
            C Offline
            c2423
            wrote on last edited by
            #65

            I already know that - the point was a discussion of Hungarian in the context of the UI, which seems to have a split opinion. And in a typeless language, you don't have types, so you shouldn't really be adding type prefixes anyway.

            1 Reply Last reply
            0
            • G gggustafson

              But if you are serious about UI programming (in WinForms, WebForms, and Mobile Apps) you want to imply a TextBox (WinForms).

              Gus Gustafson

              M Offline
              M Offline
              Member 3156407
              wrote on last edited by
              #66

              If you drag a control from teh Data Sources , Microsoft will call it firstNameTextBox -- who am I to argue if you have camel humps in R# who really cares , verbose maybe but self explanatory

              Mike

              1 Reply Last reply
              0
              • C c2423

                Maybe I should have thought of that. I'll know for next time :)

                A Offline
                A Offline
                AdamPL
                wrote on last edited by
                #67

                In XAML no need to give names to controls

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups