Re: To Hungarian or not to Hungarian

Kevin Frevert wrote:
We are re-thinking our Delphi coding standards to match closer to the standard found at:
http://www.econos.de/delphi/cs.html

A 'heated' discussion ensued over the use of Hungarian notation on components. The argument (from one person) was "Hungarian notation is no longer the recommended practice".

His recommendations were:

(Type -> Example name)
TDataSource -> DataSourceVendors
TQuery -> QueryInvoices
TADOQuery -> AdoQueryCustomers
TADODataSet -> AdoDataSetProducts
TwwDBLookUpCombo -> WwDbLookUpComboCustomerTypes

etc and so on.

My arguments were, Why all the extra typing? Why is the type more relevant than the functionality (I'm fetching data from the database, why do I care if it is a TADOQuery vs. a TADODataSet)? How does adding all the extra characters enhance readability and maintainability?

Is Hungarian notation really dead? What standards do you use?

I usually try to stay out of religious discussions, and this is certainly close enough to one for many people.....

Rule 1. Consistency in naming and coding structure is far more important than the choice of rules used.
Rule 2. I don't care what component set it comes from - any table is table. Any edit is an edit. There is no difference at this level between a TEdit, TDBEdit, and TwwDBDateTimePicker.
Rule 3. Components should always get a name - don't use the default.
Rule 4. The component prefix goes before the name. I can always figure out it is a checkbox, but I often forget just what I named it. Looking in the checkbox section is faster than looking through the whole list of components.
Rule 5. The prefix should either be 2 or 3 characters long.
Rule 6. Counter variables can be i,j,k but anything else gets a word - TempString, IsEmpty, AnimalType. I never saw the need to prefix a variable, but I wouldn't argue against it if someone else wanted to.

I generally use the prefixes shown in the link above, but I'd guess about 25% of them are different, since I came up with mine without ever having seen a list of accepted prefixes.

--
Jon Purvis
Texas Parks and Wildlife Department
Austin, TX
.

Relevant Pages

  • Re: the annoying, verbose self
    ... shorter self prefix like you propose. ... Below is my coding standard - I'm lazy, ... comutinties into strange language syntax extensions. ...
    (comp.lang.python)
  • Re: Naming dict items - "Modifiers" as prefix or suffix?
    ... recommended a standard in his book on interfacing to non Pick environments ... One can use a modifier as a prefix or a suffix. ...
    (comp.databases.pick)
  • Re: Questions about components naming convention
    ... Should I use the same prefix for components which have the ... hungarian notation is not necessary as long as you give your variables ... TeamBUG support for UK-BUG ...
    (borland.public.delphi.language.objectpascal)
  • Re: Hungarian Notation Vs Pascal Notation?
    ... standardize hungarian notation or pascal/cammel case notation. ... convention as the .NET framework itself. ... no one wants to follow any standard but their own. ... hungarian notation in part also because intellisense is so good. ...
    (microsoft.public.dotnet.framework)
  • Re: Member Variables Naming Convention
    ... references to controls a bit different than straight variables. ... Actually, in the Microsoft guidelines, it really is. ... Hungarian notation isn't completely outlawed, ... any argument for me to adopt the "_" prefix as my personal style. ...
    (microsoft.public.dotnet.languages.csharp)