Comments for Hungarian peanut butter

Hungarian peanut butter

2004-08-11T13:42:31-07:00

(PT-BR)Inicialmente parece complicado escrever código preocupado com tantos prefixos, mas esta prática é ótima para grupos colaborativos.

Chinese cookies

2003-01-08T04:58:18-08:00

I have even worse. I have just joined a company and none of the people before me (it's just a one-man programming section) actually had any standardisations! I'm not 100% with Hungarian notation for Delphi either, but even that would have been better than the nothing i got.

2002-02-21T02:20:19-08:00

2002-02-21T02:19:47-08:00

re: Hungarian peanut butter

2002-02-03T10:48:09-08:00

Good point on hints & warnings!In a good IDE (such as Delphi) hungarian notation is less than worthless, its problematic. It significantly increases code maintenance rather than reduce it.Based off a company I worked for recetly (for a very short duration) I think I understand this a bit better, however. The manager there was a strict Hungarian user and required all of his staff to use it as well. When I finally got everything setup, installed and configured and compiled their source for the 1st time I literally freaked out. Over 400+ warnings and 150+ hints!!!! And this was a SUBSET of their code base. They insisted on Hungarian but never bothered to even look at the compiler Warnings. You know, little things like "Instantiating a class with abstract methods".This was the most backwards development group I have ever worked with. Their code was a disaster. This was a BANK, the application was tracking loans and they didn't use database transactions at all. Four weeks after my first day I had my last day at that company, and I won't miss it a bit. Every shop that uses Hungarian may not be like this, but I'd bet many are.James Higgins

re: Hungarian peanut butter - teamwork for beginners

2002-02-03T10:33:45-08:00

Ouch. It must be a nightmare anytime you change anything! You must use search & replace alot.Honestly, I would refuse to work for a company with this policy. My 1st day would be my last (assuming I didn't find out in the interview).James Higgins

re: Hungarian peanut butter

2002-02-03T10:30:45-08:00

Actually, I partially diagree with this. There is no need for the "edt" in the variable names and, in fact, this can become a problem.Until recently I named my components like that too, but why? Honestly, I don't know, it is just something I picked up. Well, I spent some time analyzing why I did this and actually found it to be detremental.For instance, by "edt" I'm assuming you mean TEditBox. What happens if you later change this to a TComboBox to provide quick access to the most common choices? TComboBox can still work like an edit box, but adds a drop down. Then later you may change this to a TFancyComboBox 3rd party component you find that works like the Quicken style or whatever. Every time you change the component you need to rename it and modify every piece of code that refrences it! This can be a lot of work and can cause problems if you make a mistake during a find & replace. If you don't rename the component you just made things worse, because someone looking at the code would assume that it is a TEditBox, which it is not.So, I suggest dropping off the Hungarian portion of the name and just naming components for what they are used for. So, in your example why not name them TakeoffPoint and LandingPoint? This is extremely clear. Plus, if you have similiar components you could name them like TakeoffDate, TakeoffTime, LandingDate & LandingTime. At this point their purpose & association become clear, which really help in making the code clear.James Higgins

Hungarian peanut butter

2001-12-28T12:26:30-08:00

Adorning a variable name with the type it is represented by is a Bad Thing. HN, and therefore, SCIPI do this. Keeping the type info in HN and SCIPI up to date with the actual type of the variable is a maintenance nightmare. Apart from that, current compilers and IDE's are perfectly capable of checking wether the correct type is used. Turning on all warnings and religiously fixing errors AND warnings makes the use of HN and similar naming schemes unnecessary.

Hungarian peanut butter, simplified and expanded to cover unit naming.

2001-12-24T08:05:25-08:00

Too much, most of the time. I'd agree with usage in very long procedures, but they shouldn't be that long. On the other hand, keeping the multitude of visual elements straight on a busy form can be a real pain.I propose:c for constants,g for global variablescg for global constantsf for private variablesa for arguments inside a declarationf_ for forms, e.g. f_mainf for the unit that contains the form, e.g. fMain.pas(f_ means it won't be confused with local private field variables, and also means it'll be the one you find when you type "f" in the object inspector box)u for units that do not contain forms, where a T will give you the main class in that unit. e.g. uNavigator.pas contains TNavigator.dm_ and rdm_ for datamodules and remote datamodules, with the unit having the same prefix but no underscore.The word glue or header as a suffix for units that are shared by many other units.Visual components need only be hinted at. Full and explicit abbreviations are too much. An underscore helps highlight it. As a general rule, though, I wouldn't bother with special naming of components that are not used in code. For example, I'd only change label1 to L_status if code in the unit references this label.b_ for all kinds of buttonsp_ for panels of all kindse_ for edit boxes d_ for dataaware controlslb_ for listboxestv_ for treeviewsm_ for memos cb_ for check boxes and combo boxes. If there are several of each kind on a form, and if there are code references to them, then we might want to expand that to ckb_ and cmb_. Somewhere around three letters in the prefix, however, and we begin to overload.

Hungarian peanut butter

2001-12-23T17:43:12-08:00

These are ideals, and we live in a real imperfect world - so when you have delivered your program to a customer and he says 'Oh - didn't I say that variable iWidth should accept fractional values', do you go through your whole code base changing the variable name - I think not!And then the whole system falls over.Better to leave Hungarian notation to those who need it (C programmers who are always having to type cast). I find that strongly typed languages simply do not need it.Kerin