C#: Hungarian Notation et problem?

[BennyXNO]

Hungarian Notation er fra en svunnen tid da det absolutt var nødvendig å skrive små nette programmer og der størrelsen på alt, til og med variabler og klasser måtte være nette. Men den største grunnen til at man brukte Hungarian Notation var at verktøy man brukte ofte var tekstbaserte editorerer som vi og emacs (kjente unix editorer med kommando basert hurtigtaster for kopiering, merking osv) Disse gav jo ikke støtte i det hele tatt for utvikleren til å finne ut hva slags type en variabel var.

 

Heldigvis har miljøene der ute funnet ut at det viktigste er å skrive informativ kode enn å bruke minst mulig plass under kjøring.

 

I tillegg så finnes det i dag det så mange verktøy samt at Visual Studio og Eclipse viser deg så mye informasjon hele tiden at det ikke er nødvendig å prefikse kontroller eller variabler med type.

 

Jeg anbefaler alle å lese Robert C. Martin sin nyeste bok som heter "Clean Code", der går han litt inn på navngiving av variabler og andre ting som folk ofte synder mot.

 

Det viktigste i dag er at man skriver forståelig kode som kan lese av mest mulig.

 

Hvorfor kalle en knapp for OkKnapp, når du ser på den i html eller formkoden så ser du jo at det er en knapp. Det er rett og slett waste av energi. Det samme gjelder for en Tekstboks, det er viktigere å fortelle hva tingen er ment å gjøre enn hva slags type den er. For typen ser du jo med en gang hvis du ser på gui definisjonen.

 

I koden håper jeg virkelig du skiller gui håndtering fra logikk slik at du får vedlikeholdbar og lettlest kode.

[Johan]

Det er et poeng at det er ikke noe særlig forskjell på ButtonSave, btnSave og SaveButton. Alle sammen har et variabelnavn knyttet til en type, noe som av forskjellige grunner (tatt opp her) er unødvendig, skaper problemer og gir "rot". Hvor mye problem dette blir er en subjektiv vurdering og avhenging av smak og behag. (En sidenote er at Hungarian Notation var egentlig oppfunnet for å løse et helt annet (men relatert) problem som HD og er inne på).

 

(forøvrig, du bruker ikke regsvr32 til å registrere .net com-komponenter, du bruker regasm ;-) )

 

Interessant artikkel.

 

Men selv om man bruker den originale versjonen av Hungarian Notation/Simonyi Notation er dette kun en notasjon, ikke et typesystem. Notasjonen vil kanskje avdekke noen bugs, men typesystemet i kompileren bryr seg mindre. Og her får man jo straks akkurat samme problem som med kommentarer som ikke reflekterer koden, nemlig at notasjonen ikke reflekterer typen(i både Hungarian og Simonyi), og da først begynner helvetet.

 

En mye bedre løsning er å la kompileren ta seg av denne typesjekken selv og lage typealias, f.eks noe a la

 

type celsius = float

type fahrenheit = float

 

Og så vil celsius2fahrenheitfunksjonen ha typen celsius -> fahrenheit. Har en dette fullverdige typesystemet er det kompileringsfeil å gjøre typefeil, også abstrakte typefeil.(Kalle celsius2fahrenheit med en fahrenheit-float som parameter) Anbefaler alle å se på språk i ML familien (særlig OCaml og Haskell) som virkelig flesker til med avanserte typesystemer.

[HDSoftware]

...Hvorfor kalle en knapp for OkKnapp, når du ser på den i html eller formkoden så ser du jo at det er en knapp. Det er rett og slett waste av energi. Det samme gjelder for en Tekstboks, det er viktigere å fortelle hva tingen er ment å gjøre enn hva slags type den er. For typen ser du jo med en gang hvis du ser på gui definisjonen...

 

Hva ville du kallt den da?

[BennyXNO]

Hva ville du kallt den da?

 

ok,

lagring,

lukk?

[HDSoftware]

hmmmm

Ser poenget ditt. Jeg har liksom ikke helt vendt meg til at C# er 100% OOP enda og dermed ligger det nok en del uvaner igjen i fingra når jeg koder. I Clarion, som er det språget jeg bruker aller mest så er OOP implementert, men ikke som den grunnleggende kode formen. Det betyr at skjerm strukturer, filbuffere og andre sentrale ting ikke er properties til noen klasser, men mere statiske ting. Dermed kan jeg ikke både ha en entry som heter Kundenavn og en variable som også heter Kundenavn. Ser jo ved nærmere ettersyn at dette ikke er noe problem i C#.

[Svish]

Hva ville du kallt den da?

 

ok,

lagring,

lukk?

må si jeg føler mer for å kalle det en OkButton og en CloseButton. Grunnen er ganske enkelt den at det er jo det det er. Hva i all verden er en Ok eller en Close liksom? Close er vel ofte mer tenkt på som en handling for eksempel, og en Form har vel til og med den metoden også. I hvert fall i mitt hode. Jeg skriver stort sett på den måten. Og jeg putter Button bak, og ikke foran, fordi det da går kjappere å finne det i den Intellisense menysaken. "Jeg skal nå ha den Ok knappen" *skrive OkBu og trykke enter.

 

Variabel navn skal etter min mening være beskrivende og lettleselige. Forsøker for eksempel å styre unna jalla forkortelser som btn eller frm eller krpt eller sånt. Ellers så pleier jeg å bruke stor forbokstav på variable som kan sees utenfra, for eksempel public variable, metoder og parametere. Og da liten forbokstav på ting som er internt i en klasse. Ender en opp med en parameter og en property som har samme navn, så tar en this til hjelp. Viktigste for meg er at det skal være enkelt og klart å bruke den klassen utenfra senere. Ikke at jeg slapp å skrive this et par ganger når jeg lagde den

[BennyXNO]

Hva ville du kallt den da?

 

ok,

lagring,

lukk?

må si jeg føler mer for å kalle det en OkButton og en CloseButton. Grunnen er ganske enkelt den at det er jo det det er. Hva i all verden er en Ok eller en Close liksom? Close er vel ofte mer tenkt på som en handling for eksempel, og en Form har vel til og med den metoden også. I hvert fall i mitt hode. Jeg skriver stort sett på den måten. Og jeg putter Button bak, og ikke foran, fordi det da går kjappere å finne det i den Intellisense menysaken. "Jeg skal nå ha den Ok knappen" *skrive OkBu og trykke enter.

 

Variabel navn skal etter min mening være beskrivende og lettleselige. Forsøker for eksempel å styre unna jalla forkortelser som btn eller frm eller krpt eller sånt. Ellers så pleier jeg å bruke stor forbokstav på variable som kan sees utenfra, for eksempel public variable, metoder og parametere. Og da liten forbokstav på ting som er internt i en klasse. Ender en opp med en parameter og en property som har samme navn, så tar en this til hjelp. Viktigste for meg er at det skal være enkelt og klart å bruke den klassen utenfra senere. Ikke at jeg slapp å skrive this et par ganger når jeg lagde den

 

Jeg er helt enig at subjekter ikke skal ha verb som navn. Men jeg står fullt og helt for at det ikke er nødvendig å postfixe en kontroll med typen, da man ser hva det er i editoren.

 

En jeg jobbet med prefikset alle metodene på usercontrolene sine med ctrl for å gjøre det lettere å finne sine egne metoder.

 

Men dette blir helt feil vinkling, for gui programmering skal man gjøre minst mulig av, og heller fokusere på å gjøre den faktiske jobben i biblioteker slik at man letter gjenbruk.

[Svish]

som hvis jeg prefixet alt jeg programmerte av klasser og variable og metoder med svish hadde jo blitt genialt. kanskje jeg sku begynne med det... er nok enig i at det blir surr ja.

 

men jeg vil nok fortsatt postfixe mine knapper med Button, så sant det er det de er. Men det er ikke fordi typen er Button, men fordi variabelen inneholder noe som i mitt program fungerer som en knapp. Om typen var Btn eller Knapp eller SuperButton eller hva som helst annet, hadde jeg nok fortsatt kalt den for Button, dersom det var det den hadde som funksjon i mitt program. Et bilde kunne jo forsåvidt også vært en Button så sant den kunne klikkes på og gjorde noe nyttig når den ble klikket.

[GeirGrusom]

I VB6 var det veldig vanlig å prefikse klasser med "cls"

Fuglene vet hva det skulle være godt for.

[HDSoftware]

I VB6 var det veldig vanlig å prefikse klasser med "cls"

Fuglene vet hva det skulle være godt for.

Vell, jeg gjør det hele tiden enda, nettop for å anngi at dette er en klasse. Ser jo unødvendigheten i C# da alt er klasser, men for meg er ikke verden så enkel. I Clarion er en klasse kun en avansert datatype på lik linje som LONG, BYTE, GROUP og FILE , ja til og med WINDOW er en datatype i Clarion. For meg er det veldig naturlig å navngi klassene av denne grunn og dette har jeg tatt med meg over i C# verdnen. Kansje er dette bortkastet, men koden blir da leselig uansett.

public class CustomerClass
{
...
}

Bruken min er stort sett uten unntak slik:

CustomerClass ThisCustomer = new CustomerClass()

Jeg tror dette kun handler om vane og hvordan man ønsker å utnytte intellisencen mest mulig. Ser jo at Intellisencen i C# gir en masse symboler som angir datatypen, men ingenting er så enkelt som et forklarende navn. Står det CustomerClass så er det en klasse og står det CustomerForm så er det, nettop, en form. Er ikke dette helt greit da?

[The Jackal]

I VB6 var det veldig vanlig å prefikse klasser med "cls"

Fuglene vet hva det skulle være godt for.

Vell, jeg gjør det hele tiden enda, nettop for å anngi at dette er en klasse. Ser jo unødvendigheten i C# da alt er klasser, men for meg er ikke verden så enkel. I Clarion er en klasse kun en avansert datatype på lik linje som LONG, BYTE, GROUP og FILE , ja til og med WINDOW er en datatype i Clarion. For meg er det veldig naturlig å navngi klassene av denne grunn og dette har jeg tatt med meg over i C# verdnen. Kansje er dette bortkastet, men koden blir da leselig uansett.

public class CustomerClass
{
...
}

Bruken min er stort sett uten unntak slik:

CustomerClass ThisCustomer = new CustomerClass()

Jeg tror dette kun handler om vane og hvordan man ønsker å utnytte intellisencen mest mulig. Ser jo at Intellisencen i C# gir en masse symboler som angir datatypen, men ingenting er så enkelt som et forklarende navn. Står det CustomerClass så er det en klasse og står det CustomerForm så er det, nettop, en form. Er ikke dette helt greit da?

 

Men CustomerForm er jo også en klasse

[Glenn F. Henriksen]

Men CustomerForm er jo også en klasse

Og det er derfor jeg prøver å unngå å gi objektene mine navn etter hva de er. Det blir fort forvirrende

[HDSoftware]

I henhold til det jeg sa: "Ser jo unødvendigheten i C# da alt er klasser,...."

Og: " I Clarion er en klasse kun en avansert datatype på lik linje som LONG, BYTE, GROUP og FILE , ja til og med WINDOW er en datatype i Clarion. "

Derfor er dette basert på vaner.

 

Når det er sagt så er jeg alikevel villig til å si at det er forskjell på en FORM klasse, en Business klasse og en FILE klasse, så kansje er jeg mere på det sporet og kaller vinduer for WND eller FORM og BIZ klasser for CLASS.

 

Tror denne tråden ender opp i at gamle vaner er vonde å vende......

 

Men takker for alle innspill. Det har vært interessant....

[dahwan]

Skjønner ikke hva problemet er. Jeg navngir alltid mine variabler/objekter med typename prefix for å gjøre ting lettere å finne i auto fullføreren. I det skjeldne tilfellet at jeg plutselig endrer type så kjører jeg en kjapp find&replace; et verktøy som er implementert til og med i NOTEPAD ffs. Pluss at i Visual Studio gjør de det så enkelt at jeg bare trenger å skrive et nytt navn til variablen, høyreklikke og trykke på "change variable name" så BAM er alle referanser til den variablen oppdatert med det nye variabelnavnet.

 

Jeg er ikke 100% på hva "hungarian notation" egentlig er med tanke på at forklaringer i f.x. wikipedia gav meg hodepine, men jeg tror jeg elsker det

[GeirGrusom]

Alle klassene du har definert ligger allerede i et eget namespace.

 

Jeg synes ikke det er så ille å prefikse kontroller, men på datatyper og variabler i klasser, strukturer eller funksjoner ser jeg ikke poenget overhode. Et variabel navn skal være beskrivende for hva variabelen brukes til, og jeg ser ikke hensikten med at datatypen også skal henge med.

 

Eksempelvis MS har jo tråkket i denne feilen tidligere i Win16, og nå er den opprinnelige hungarian notation blitt hengende igjen, og er bare til forvirring.

Dette er dog helt klart et større problem i biblioteker enn i programmer, så er det fortsatt et problem som fint kan unngåes ved å ikke prefikse variabler med datatypen.

 

Hvis du for eksempel har en struktur som inneholder en del felt, helt eksempelvis et bitfield

enum bBitField : byte 
{
  Bit1 = 0x01
  Bit2 = 0x02
  Bit3 = 0x04
  Bit4 = 0x08
  Bit5 = 0x10
  Bit6 = 0x20
  Bit7 = 0x40
  Bit8 = 0x80
}

 

Og så plutselig i neste versjon av biblioteket ditt så tenker du "OPS! dette butde vært en short, ikke en byte, jeg trenger flere verdier!"

Da sitter du plutselig litt i det, fordi på grunn av alle programmene som bruker dette biblioteket, så kan du ikke bare uten videre endre navn på enumeration når du går fra byte til short.

Hvis en ikke hadde prefikset, kunne programmet bare kompileres på nytt.

[HDSoftware]

Et variabel navn skal være beskrivende for hva variabelen brukes til, og jeg ser ikke hensikten med at datatypen også skal henge med....

Det er ikke snakk om datatype. Hungarian Notation er delt inn i to seksjoner, Apps og System. Bruker man System Hungarian Notation så har man datatypen med i navnet. Bruker man APPS Hungarian Notation så er det en beskrivelse:

iTalletMitt : System Huingarian Notation

fakturaNummer : APPS Hungarian Notation

 

btnOK er antagligvis SystemHungarian Notation, men saveButton antagligvis måtte kalles APPS Hungarian Notation