• Norman Diamond (unregistered) in reply to Bulb
    Bulb:
    Steve The Cynic:
    AHN, on the other hand, encodes useful information about what a variable is contaminated with rather than what its programming language type is.
    This is poor man's variant of what should better be done by actually using the type system.
    TRWTF is a language with poor man's variant as a datatype.
  • Herwig (unregistered)

    never seen any vb code that looks different...

  • (cs) in reply to chubertdev
    chubertdev:
    Tractor:
    Why use some sad movable thing with generally less than 5 buttons when you got another thing with about 100 buttons that you don't have to move around?

    I think that I'm misunderstanding you. Is the "sad movable thing" the stupid person that I'm talking about?

    No, if you can only find 5 buttons on people you're not searching rigorously enough. I was referring to a species of rodent, much smaller than humans and therefore with less buttons.

  • GlitchMr (unregistered)

    C in CVS stands for Complete. Complete Versioning System, that is.

  • Guest (unregistered) in reply to Iago

    I'll see your VBA and raise you the specific Office app it was written for: Access, which resets all variables in response to common errors - not all of which crash the database in an obvious way. If you failed to test for the exact error condition (before the error flag was cleared), you would miss it, and could go on testing code in the development environment without understanding that the reason it failed was due to established variables suddenly forgetting what their value was. This included internal Access/VBA features that were explicitly added (by Microsoft) for the purpose of (semi)permanent variable storage. You can identify experienced Access developers by their compulsive habit of refreshing the form (to re-run OnLoad events) with each cycle of testing, and quitting/relaunching the entire application for forms referencing variables set when the database first opens. Keeping variables in fields on the form is actually recommended, being not only a safer way of keeping their values intact but also a faster way of storing/retrieving them when an SQL query would have to reach across the network to a backend and the GUI elements are on the local terminal.

  • JJ (unregistered) in reply to Anon
    Anon:
    bjolling:
    Remy Porter:
    warlaan:
    There was a time when IDEs were not able to use colors to mark keywords and when it was not possible to display tooltips when you hovered over a variable name with the mouse.

    Here's the thing: I never use the IDE to check the type of a variable. I generally just look at the code, because the variable declaration is someplace convenient, like a few lines above where I'm using it. Or the variable is named something that semantically implies its type. "DueDate" is how we say it in English. "dteDue" or "dteDueDate" is not.

    Didn't read until the end so maybe somebody already replied.

    Hungarian notation is NOT about writing "dteDueDate" to indicate that your date really is a date, or writing intOffsetX to indicate that this is really an int.

    Hungarian is about encoding useful information into a variable name. For example you could have distances expressed in centimeters and in inches.

    "cmTotalDistance = cmFirstPart + inchSecondPart" is immediately understood to be wrong. Your compiler won't help you there.

    What you describe is possibly helpful, but it ain't Hungarian notation. You are redefining the term.

    Congratulations on getting it 100% backwards. What most people (yourself included, obviously) think of as Hungarian Notation today is actually the redefinition of the term. What bjolling described was the original and arguably useful Hungarian Notation.

  • (cs) in reply to chubertdev
    chubertdev:

    I think that I'm misunderstanding you. Is the "sad movable thing" the stupid person that I'm talking about?

    No, he's saying "I'm better than you because you use a mouse and I don't."

  • (cs) in reply to nasch
    nasch:
    chubertdev:

    I think that I'm misunderstanding you. Is the "sad movable thing" the stupid person that I'm talking about?

    No, he's saying "I'm better than you because you use a mouse and I don't."

    And I'm being sarcastic right back. :)

    (tab + space)

  • chris (unregistered) in reply to Bring Back TopCod3r
    Bring Back TopCod3r:
    Remy Porter:
    Yes. Hungarian Notation is, and always has been, a WTF.

    Yes, it always was, although at one time I dare not speak out. I feel the same way about XML today (although I think the tide is finally changing).

    Remy Porter:
    What makes Hungarian Notation TRWTF, however, is popular it was. "

    Microsoft heavily promoted it, in all documentation, sample codes etc. If you were working for a Microsoft shop, you would almost certainly be using it.

    There are two common flavors of hungarian notation. I'll leave it to you to find them. One MS group promoted a certain version. A number of groups misunderstood and used the really bad one. From that point forward people using the MS Windows API's decided that the jacked version was what they should be doing too. It just cascaded from there.

    Simply put, enough programmers, including ones in house, didn't know WTF they were doing so MS decided a blanket "Don't use Hungarian" statement was the easiest to get away from this crap.

  • prism (unregistered) in reply to jay
    jay:
    dim strCustomerName as String = tbCustomerName.text

    HN is ok when used with suppression. Also, do not prefix, suffix like this:

    dim customerName as String = customerNameTB.text customerNameLA.text="Full Name:"

    When getting into MVC and Mediators for a control:

    class CustomerNameTBmed: Mediator{

    and struct CustomerVO{ //Value Object class Customer: Person{

    then German Inverseing... class CustomerNewFO: Form{

    Suffixing makes intellisense shine.

Leave a comment on “Do Not Remove Complete!”

Log In or post as a guest

Replying to comment #:

« Return to Article