Fog Creek Software
Discussion Board




Hungerian standard+Java standard=UML ClassDiagram

I assume that UML class diagram should be generic for all the available object oriented language and should not be language dependent. If we follow pure java naming conventions in UML class diagram, which make the UML class diagram Java language dependent not generic.

I am trying to combine Hungarian Naming Contentions with Java Naming Convention so variable name will follow x_y schema where x_ is according to Hungarian notation attached with class attribute, which is named according to java naming standard. This naming standard satisfies UML naming convention and will also help in java programming.

For an example,

i_userNumber 

Here ‘i_’ is a Hungarian notation representing type of variable attached with class attribute . This indicates that “i_’ is integer datatype attached with class attribute, which is named according to java naming standard.

( Feedback please)....

Hemang
Monday, July 05, 2004

Read this about Hungarian Notation
http://c2.com/cgi/wiki?HungarianNotation

Matthew Lock
Monday, July 05, 2004

Must you use underscores? To me, they're annoying -- anyone else?

DEBEDb
Monday, July 05, 2004

I hate underscores and I hate Hungerian notation!

Almost Anonymous
Monday, July 05, 2004

I gave up all hope of ever using Hungarian notation profitably when I saw, in the Programming Visual Basic 6 book, about ten pages of Hungarian-style abbreviations for all the different types you might store in a VB variable ('frm' for form, etc.)  Every trip through the Win32 documentation confirms this when I'm looking at a string declaration that starts LPCZ.

The whole point of Hungarian notation is to improve programmer productivity by making the type a part of the variable name so that the programmer no longer has to remember it or ever look it up.  But every place I've ever seen it used has used so many different possible type encodings as to render it useless.  You can't possible remember them all, and reading a variable name becomes a decoding exercise.

Justin Johnson
Monday, July 05, 2004

In other words, don't bother.

Justin Johnson
Monday, July 05, 2004

m_strWhatYouTalkinBoutWillis

GuyIncognito
Tuesday, July 06, 2004

Hungarian notation is used to provide type information in an essentially typeless language: c.

Withing hungarian the standard is i_userNumber.  In UML the type is decaled explicitly as userNumber : Integer.  The prefixed 'i_' is redundant as there is a much better way of expressing that this value is of type integer.

If you want to generate c code that uses hungarian notation, then shouldn't this be done in the code generater.  Each type is giving a shortened hungarian identifier and the names converted.  You can do any convention conversion you want.

You code generator could take userNumber : Integer and then  (1) prepend the 'i_' hungarian identifer, (2) parse the capitals and replace with underscores to make i_User_Number, (3) anything else that takes your fancy.

Ged Byrne
Tuesday, July 06, 2004

>Hungarian notation is used to provide type information in an >essentially typeless language: c.

I would argue that using typedefs, you can convey type information in C just fine.

Hungarian Notation is an archaic remnant of a time when the average terminal had 20 green or amber colored lines while the minimum size of a compilation unit was 5000 lines,  you could only compile once a day on the mainframe and got your error messages back the next week and neither procedures nor IDEs had been invented yet, which meant you'd have to look through a 5 inch stack of dotmatrix green-bar paper to figure out how 'x' was declared. So you'd call it 'ix' because of the 2 character limit on the length of variable names.

That said, Hungarian Notation is annoying, difficult to type and doesn't offer any information that you don't have at your disposal in even the most rudimentary editing environment anyway.

Apart from that, it's possible to use Hungarian Notation with Java and noone forces you to use Hungarian variable names with Cobol or whatever the other language you're using is. Does UML really specify that you have to use HN for variable naming?

  -tim

a2800276
Tuesday, July 06, 2004

Hungarian is evil, and must die.

Mr Jack
Tuesday, July 06, 2004

At a recent gig, the coding style guidelines (which, it was reiterated several times, we were to absolutely adhere to) specified Hungarian notation to use (p for parameters to methods, iv for instance variables, cv for static variables, m for locals). After some time I have found that I was one of about 3-4 other developers (on a project involving, in total, over a hundred -- they kept letting contractors go and hiring new ones, an idiocy in itself) that ever used that. So much for the convention.

DEBEDb
Tuesday, July 06, 2004

Underscores are hideous. Java code is pretty. Apart from some CORBA bindings which have underscores. Which are hideous. Grrr.

Thom Lawrence
Tuesday, July 06, 2004


Actually, I prefer underscores to mixed cap (eg. read_this vs. readThis). I find it somewhat difficult to read mixed cap because the regular cue for word separation, whitespace, is lost and the usual indicator for sentence separation, capitalization, is used for a different purpose.

Now, of course, I *can* read mixed cap. I'm just saying that I find is a tiny bit harder because it breaks the usual rules.

But, I seem to be on the losing side of this argument, so I'll adapt toOurNewMixedCapOverlords.

Bill Tomlinson
Tuesday, July 06, 2004

My problem with Hungarian notation is that it tightly couples the 'type' of a variable with its purpose.  What happens when you want/need to change the 'type' of a variable so that it better fits its purpose?

For example, you have an 'int' variable, which later turns out to need to be a 'long'.  Now you have to change every 'i_xxx' instance into an 'l_xxx' instance.  And is that leading 'l' an upper case 'i' or a lower case 'L'?  Did we use pointers 'p' to it?  or not?

And what about 'created' types -- typedef things.  Do we generate 'new' Hungarian prefixes for each one?

And, as others have pointed out, Hungarian was 'supposed' to be consistent -- yet there are so many possible starting prefixes it becomes impossible to keep them all straight.  It increases ambiguity, instead of reducing it.

In the early days of 'C', MAYBE it was needed.  Even then, I didn't like it.  Nowadays, I really don't think it adds anything other than confusion and supporting the 'software priesthood'.

AllanL5
Tuesday, July 06, 2004

"My problem with Hungarian notation is that it tightly couples the 'type' of a variable with its purpose.  What happens when you want/need to change the 'type' of a variable so that it better fits its purpose?"

This is called refactoring.  It's a new development technique recently discovered to enable people to sell more books and seminars about refactoring.

free(malloc(-1))
Tuesday, July 06, 2004

If you have variables that are widely accessable then you may need to have an aid in remembering the precise type of a variable, but you're more urgently in need of aid in reducing the coupling between your modules.

Local variables are declared near where they're used so it should be easy to see what type it is, small classes don't have large numbers of members so you don't need to spend all week searching for a specific member, loosely coupled classes don't need to know the datatypes of all members of 83 other classes, globals are often not considered ideal, and so on.

Oh, and using a decent development environment (a good IDE, emacs with lots of extensions, whatever else actually works) will mean that you can find out the type of a variable with no effort, so why not take advantage of the ability? I'm always amazed by programmers who build amazing data manipulation systems for their customers but can not cope with the idea of using anything but the most minimal text editor and plain ASCII text files for writing the code.

an IDE is my friend
Tuesday, July 06, 2004

--"I gave up all hope of ever using Hungarian notation profitably when I saw, in the Programming Visual Basic 6 book, about ten pages of Hungarian-style abbreviations for all the different types you might store in a VB variable ('frm' for form, etc.)"-----

VB is probably where you find most of the present supporters of Hungarian. frm.... is a pretty important prefix in database design.

Hungarian allows you to have a frmCustomers and a tblCustomers and a qryCustomers and be able to clearly see the relationship between them. Also it is useful to have a control labelled cboCustomerName and a label labelled lblCustomerName.

Stephen Jones
Wednesday, July 07, 2004

*  Recent Topics

*  Fog Creek Home