Do you use Polish notation? Why or why not?

[Glenn9999]

I got to thinking about arbitrary coding standards and my prior experiences, and remembered in Visual Basic classes that we were required to use "Polish notation" within our programs to define variables, like forms, text boxes, etc.

Basically instead of defining things like:

TForm1 = class(TForm)
    Edit1: TEdit;
    Edit2: TEdit;
    Label1: TLabel;
    Button1: TButton;
var
  Form1: TForm1;

You do something like:

TForm1 = class(TForm)
    txtEdit1: TEdit;
    txtEdit2: TEdit;
    lblLabel1: TLabel;
    cmdButton1: TButton;
var
  frmForm1: TForm1;

basically the idea is prefixing all variable identifiers with the purpose of the widget.

Personally, I wasn't too impressed with this, and the instructor required it. If you really look at it, there's a rather long list of specifically defined extensions, which just add unneeded complexity to have to produce.

So what is your opinions on this?

 

[trollacious]

I've always heard and read it as Hungarian notation after the man who is considered the "father" of that style.

http://en.wikipedia.org/wiki/Charles_Simonyi

I generally name the form elements with a 3-letter prefix denoting the type of element it is, then use a descriptive term for the element's function after that, like txtFirstName, lblSearch, butExit (or cmdExit).

If I saw someone using something called Form1 or Text1, I'd figure they were still a student, or someone else who hadn't been taught to name variables appropriately. I don't know of any experienced or good programmers who would use default element names like that.

Lee

 

[Glenn9999]

I think that's the term Microsoft introduced when it comes to their initial Visual Basic examples. The page below is the best one I can come up with to describe it.

http://www.engineering.usu.edu/cee/...GradClass/GottfriedChapters/Gottfried_Ch4.htm

If I saw someone using something called Form1 or Text1, I'd figure they were still a student, or someone else who hadn't been taught to name variables appropriately. I don't know of any experienced or good programmers who would use default element names like that.

Agreed. Or lazy. I just wanted some reasonably realistic examples quick for the post I made, so I did a couple of edit boxes, a label, and a button and added numbers in the edit boxes and put it on the label.

 

[trollacious]

A realistic example would be a form with address information. Each edit/text box has a corresponding label, and I would use control names like

lblFirstName: TLabel;
txtFirstName: TEdit;
lblLastName: TLabel;
txtLastName: TEdit;

and so on. I sometimes have a form that I've named the main name of the program and a class that is the same name.

I would say that the Utah State University professor who referred to that naming convention as "Polish notation" is in error. If you do a Google search for "Polish notation" you'll find that it refers to something completely different.

Lee

 

[sggaunt]

I was taught to use meaningful variable names, prefix or not the names in the original post are not meaningful, so i dont see the point!



Steve [The sane]: Delphi a feersum engin indeed.

 

[earthandfire]

Despite that reference, I've always undertstood the term to be Hungarian as per trollacious.

The only "Polish" that I am aware of is Reverse Polish Notation

http://en.wikipedia.org/wiki/Reverse_Polish_notation

Hope this helps

 

[Griffyn]

I don't use that sort of notation - I agree with sggaunt. The type of control a variable refers to is easily seen with a mouseover.

I generally use single character variable names for local variables (with their use somewhat consistent across different methods and projects, ie 'c' as a main loop integer), I prefix all class fields with 'F', and use descriptive variable names if defined anywhere else.

 

[sggaunt]

[Off topic note on Reverse Polish notation]
I believe that early Sinclar/other calculators (c1972) used RPN.
The Sinclair Oxford (which I had some involvement in the development) was one of the first to use the method of entry we use on calculators nowadays!

Steve [The sane]: Delphi a feersum engin indeed.

 

[harebrain]

The type of control a variable refers to is easily seen with a mouseover.

That depends on your environment. If you ever had to use VB Script (in which all variables are treated as variants) to program ASP, you'd quickly see the value of the Hungarian convention.

And the longer a program module is, the more sensible it is to use this convention.

As for early electronic calculators, the two big camps were TI and HP, which used algebraic (infix) and RPN, respectively.

 

[trollacious]

And it only works if you're working in the Design view (where the control is visually displayed) rather than the Code view (where you actually type the name in the code you write). It's a real pain to switch back and forth between the 2 just to get the name of a control.

Lee

 

[Griffyn]

it only works if you're working in the Design view

I'm using D6 and the mouseovers work in the Design view, for every type of variable no matter where it is declared.

You can also Ctrl+Click with the mouse to jump to the declaration of that variable.

 

[Opieo]

Heck, I may not be a student, but even while I was I used to give components descriptive names.
However, on small forms, such as the Login form, with a whopping 2 labels that never change, 2 edit boxes, and 2 buttons, I leave the items with their default names.
For such a small form, if somebody got confused when looking at my code, they must not be a programmer.

Actually, on any form, if the labels never change, I never name them either. I just don't see it as worth my time.


~
Give a man some fire, he will be warm for a day, Set a man on fire, he will be warm for the rest of his life.

 

[3th3ridg3]

The term "Hungarian" referred to the gentleman programmer at Microsoft (I apologize that I have forgot his name) who created the style. The name refers to the effect the look of the code style had on the first participants. It was really popularized by Charles Petzold, the grandfather of all Windows programming.

Hungarian notation was critical in a language like C which had no type assignement safety. You could easily assign a string to a variable of type double and spend a day de-bugging the issue! Having the variable type encoded in the name guarded against bad assignements.

In strongly typed modern languages like Delphi and C#, Hungarian is less necessary and more a personal style choice. Modern stylists more recommend:

PasswordForm : TForm

over

frmPassword : TForm

Do what makes sense to you; just keep it clean and readable for the next poor slob who has to debug it.

Personally I stick to the Hungarian becuase it is "in my blood" and I am so used to it. But it is, after all, a programming language, not a religion.

 

[towerbase]

The programmer was Charles Simonyi (born 10 Sep 1948) and he was originally from Budapest, Hungary. That coupled with the fact that names that follow the convention looked foreign was the reason that it was called the Hungarian Naming Convention.

Andrew
Hampshire, UK

 

[BillKilgore]

I have used the "Hungarian" method for so long that I inadvertently use it in written script when I write memos and notes. It does, however, provide an excellent means of making descriptive variables much more readable without underscores.

I always thought "Polish Notation" involved two constants followed by the sign on my HP48. Now I find there's another meaning.

BillKilgore

 

[jwenting]

Hungarian notation is inherently evil.
It makes refactoring implicitly impossible and creates hard dependencies between parameters and their types which is a bad thing.

Just look at the Win32 API for some excellent examples.
Many of the 32 bit integer fields there have type names which indicate them being 16 bit fields.
The underlying types have been changed to 32 bit but the type names kept the same so as not to break code relying on those names.

That's the consequence of using Hungarian notation in a public API.

Make your names meaningful, letting them indicate business concepts rather than actual code types.
That way the type can change without the name having to change.

Using Hungarian notation also makes code a lot harder to read as it puts a lot of superfluous information into your names.
'lpfstrUsername' might sound geeky, but it tells me nothing I care about as a user that 'username' doesn't.

Even Microsoft (who initially introduced the thing into the general public) no longer uses it except for backwards compatibility in existing APIs and advises people to step away from it.

 

[Stretchwickster]

During education, I have always been taught to use Hungarian notation. With the commercial (Delphi) product I've been working on for the last 4 years, we use a convention of naming for VCL components e.g. Lab_, Cb_ and Ed_ for TLabel, TComboBox and TEdit respectively. I think the main reason for doing this is to maintain consistency with older code, which was authored way back in Delphi 2. I presume that at that time, tooltips showing data type were not built into Delphi. We now use Delphi 6, so it does make the Hungarian notation somewhat redundant due to the tooltips. Consequently, we tend not to use Hungarian notation for non-VCL components but rather give the most appropriate and meaningful name to each variable.

I think jwenting makes a very good point when referring to Win32 API as an example of the danger of tying variable name to variable type. In OOP, where information hiding is a key concept, it is important to ensure that a property, for example, can retain the same descriptive name regardless of whether its' data type changes.

I can certainly see the usefulness of Hungarian notation in weakly-typed languages, but I don't think it fits particularly well with OOP.

Clive

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096

 

[MagicFrisbee]

I, too, was educated with Hungarian notation. I use it for naming form components, but not object fields and global and local variables. Although my IDE does pop up a hint when rolling over a variable, I'd rather just read my code like a book and not have that hint cover other text. Hungarian notation makes at-a-glace reading easy. Delphi 2006's refactoring engine makes it easy to rename a variable across an entire project. And, so far as changing types go, I don't very frequently change the type of a variable without changing its name, too. The refactoring engine means I don't have to go Find-And-Replace all instances of an identifier.

Another good use of Hungarian notation is when you send code to someone else, or post it on a forum like this one. Rather than declaring all your variables, readers can infer what the types are.

GIS Programmer
City of Orem, UT

http://gis.orem.org