Go Down

Topic: Making coding easier with Hungarian notation  (Read 1 time) previous topic - next topic

Robin2

This is (as expected) degenerating into a re-run of the OP's earlier Thread on the same subject. I suggest that this Thread be merged with the other one.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Robin2

Think the community is too large for having consensus,
If you tell me that there is a consensus among the Moderators in favour of leaving this Thread here I will, of course, accept that.

However it has not seemed to me that there has been a collective discussion among the Moderators about the appropriateness of anything in this Introductory Tutorials section, or whether the section should exist at all.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

boylesg

https://softwareengineering.stackexchange.com/questions/14789/what-is-the-appeal-of-systems-hungarian/15045

Quote
At the moment I still use Hungarian for exactly three reasons, judiciously avoiding it for everything else:

    To be consistent with an existing code base when doing maintenance.
    For controls, eg. "txtFirstName". We often need to distinguish between (say) "firstName" the value and "firstName" the control. Hungarian provides a convenient way to do this. Of course, I could type "firstNameTextBox", but "txtFirstName" is just as easy to understand and is less characters. Moreover, using Hungarian means that controls of the same type are easy to find, and are often grouped by name in the IDE.
    When two variables hold the same value but differ by type. For example, "strValue" for the value actually typed by the user and "intValue" for the same value once it has been parsed as in integer.

I certainly wouldn't want to set up my ideas as best practice, but I follow these rules because experience tells me that it occasional use of Hungarian benefits code maintainability but costs little. That said, I constantly review my own practice, so may well do something different as my ideas develop.

Update:

I've just read an insightful article by Eric Lippert, explaining how Hungarian can help make wrong code look wrong. Well worth reading.

GrooveFlotilla

But, as I've already said, newbies (which is who this section of the forum is aimed at) can't always tell what they can do and what they have to do.
("I want to append a digit to this variable" aka "I don't know what an array is")

It's simpler not to confuse them at this stage, otherwise they'll tie themselves (and others) in knots trying to explain their code, when one party will read one interpretation into their code, which may well not be the one they intended.
Some people are like Slinkies.

Not really good for anything, but they bring a smile to your face when pushed down the stairs.

wilfredmedlin

#19
Jan 26, 2018, 01:49 pm Last Edit: Jan 26, 2018, 01:55 pm by wilfredmedlin
What is it with the coding nazis in here?




Keep Calm and call 0118 999 88199 9119725...... 3

boylesg

#20
Jan 26, 2018, 01:50 pm Last Edit: Jan 26, 2018, 01:57 pm by boylesg
If you tell me that there is a consensus among the Moderators in favour of leaving this Thread here I will, of course, accept that.

However it has not seemed to me that there has been a collective discussion among the Moderators about the appropriateness of anything in this Introductory Tutorials section, or whether the section should exist at all.

...R
Well if they remove it then I won't lose sleep over it.

I thought it would be helpful to newbies so I made my contribution.

Like I said, if you don't like it then don't use it.

But that is no reason to prevent others from reading it.

GrooveFlotilla

I looked at the other thread, and found this.
What does "Arduino size_t" mean?
Some people are like Slinkies.

Not really good for anything, but they bring a smile to your face when pushed down the stairs.

boylesg

I looked at the other thread, and found this.
What does "Arduino size_t" mean?
size_t is an Arduino typedef.

I assume typefef size_t uint16_t (or is it typefef uint16_t size_t....I never seem to remember)

I have never bothered to grep the declaration to find out.

GrooveFlotilla

Some people are like Slinkies.

Not really good for anything, but they bring a smile to your face when pushed down the stairs.

flounder

#24
Feb 05, 2018, 01:13 pm Last Edit: Feb 05, 2018, 01:29 pm by flounder
What most people do not understand about HN is that as used in Microsoft Windows it is a complete perversion of the original intent of its designer.

The Windows group chose to add the letter of the data type because they were, at that point, programming in C.  Original C, with no function prototypes, no type checking, and a primitive compiler.

Charles Simonyi, the Hungarian inventor of the notation, used it not coupled to base datatype but to purpose.

Even Microsoft gets it wrong: the type of one of the parameters to a message handler was originally WORD so people used  wParam.  But when Win32 came along, the type was changed to 32-bit, and everyone still used the name wParam.  In Win64, the type was changed to 64-bit, and everyone still used the name wParam.  There are several dozen instances I have found in the header files, along the lines of

void * lOption
void * lpszOption
long wOption
void * dwOption
ULONG iCount
int wCount

I don't have my list available right now (as I type this) but I have a slide with 30 of the most egregious errors I have found (I wrote a simple program to search for them).  Bottom line: there is no reason to encode the underlying datatype in the name.  The compiler deals with this.  There is a good reason to consider encoding the purpose, for example, any variable that encodes horizontal position being called xSomething, and one that encodes vertical position being called ySomething.  I could care less about what the underlying representation is; looking for the declaration is somewhere between easy and trivial. 

The number of times I saw code of this form in the Microsoft Windows forum (I was a Microsoft MVP for 15 years in the C/C++/MFC/Windows area) was horrifyingly large:

void SomeFunc(int n) {
     int m_Count = 0;
...
}

As Simonyi designed it, the prefix indicated the nature of the usage, since C lacks any good way of doing type-checking based on purpose.  So there might be charCount, the count of characters, or pixCount, the count of pixels, or lineCount, the count of lines.  All counts were simply int values, but if you saw someone write
    charCount += pixTemp;
you knew the answer was wrong.  Or, what killed a Mars lander, if the code had said lbsThrust, the place where a value in Newtons was used, e.g.,
    lbsThrust *= newtForce;
would be trivial to spot, whereas
    dThrust *= dForce;
tells you nothing useful.

In another case, when a 15" gun turret was told to rotate 5 degrees, and the value the subroutine got was expected to be in radians.  If you saw someone passing in a degMotion to sin you would immediately see a pretty obvious failure, because sin would expect radMotion (the story goes that since the servo was a second-order servo, controlling acceleration as well, and it was told to spin the gun 5 radians, the gun turret was still accelerating when the gun barrel struck the superstructure of the ship, causing a few million dollars in damage.  Story from Nancy Levison, one of the founders of the field of Software Safety [the other being Dave Parnas, one of my professors back in 1968]).

My information on the history of HN comes from a former Microsoft employee, who worked with Simonyi, in the Microsoft Word group.  He sent me the message asking to remain a "confidential informant", but said that when used properly, i.e., disconnected from representation and associated with purpose, it was highly effective.  But tied to base representation, it is actually useless, and even destructive, to understanding code.  As was observed, if you change the type, you must change the name to be HN-compliant.  But if the name is part of a shared interface, you break the code of everyone using that interface.  If you decide someday to change lineCount from WORD to DWORD or LONGLONG, the name does not have to change, because its purpose has not changed (although you might wonder about the need to represent a document containing more than 4.2 billion lines, there are some counts that need more than 32 bits to represent when larger address spaces allow for larger problem sets).

I have had to maintain code written by people who either did not understand HN, and got it wrong, or used it as it is used in the Microsoft Windows API, and, as the program evolved, the representation changed but, because it would break existing client software, the name remained unchanged.  Both of these are total disasters.  I have learned that HN, in its bad form, cannot be trusted.  It simply must be divorced from base datatype.

     joseph m. newcomer

Go Up