C#: Hungarian Notation et problem?

[HDSoftware]

Folkens

Jeg kjørte en "Code analyzer" i Visual Studio på prosjektet mitt og den kom med et mylder av warnings med helt klar tale: "Ordet bnt er ukjent. Hvis dette er Hungarian notation så ta det vekk". Ikke helt orrett i sitatet her, men siste del som sier "Ta det vekk" kunne helt uten tvil oppfattes som en ordre.

 

Jeg sjekket litt på Wikipedia og det står en del interresant om temaet der, men jeg fant absolutt ingen ting som tillsier at dette kan skape noen problemer med koden i det hele tatt. Det var referert fra kjente personer som Linus Torvalds og Bjarne Sostrup (eller hvordan det skrives) med flere som hadde delte meninger om dette. Det er også uttalt der at Visual Studio er et utviklingsværktøy som helst ikke bør ha dette.

 

Så er mitt spørsmål: Hvorfor i alle dager er dette et tema i det hele tatt?

 

En kompilator leser vel ikke teksten i koden? Er det ikke en gjennkjennbar tekst så blir vel koden behandlet der efter. Er vel kunn reserverte ord som ikke kan brukes i koden.

 

Jeg klarer ikke se noen grunn til at dette skal være et problem i det hele tatt, snarere tvert i mot!

"btnSendFaktura" er da et like godt kontrollnavn som "SendFakturaKnapp"

 

Hva er deres mening om dette temaet?

Er du for eller imot å bruke hungarian Notation og hvorfor?

[GeirGrusom]

Du kan kikke litt på Windows Platform SDK så ser du fort hvorfor hungarian er en dårlig idé. Hvis en ser bort ifra hvor unødvendig det egentlig er, så fikk faktisk MS et stort problem fordi de brukte hungarian notation i Platform SDK.

 

Sjekk for eksempel WndProc definisjonen

 

HRESULT WndProc(int msg, WPARAM wParam, LPARAM lParam);

 

En skulle tro at wParam er definert som en WORD, siden navnet starter med w? vel, den er ikke det, de ombestemte seg i ettertid, og wParam er nå en DWORD.

 

De kan ikke endre dette i ettertid, så hele Platform SDK er FULL av slike ting.

 

Hungarian notation er en dårlig idé.

 

Selv pleier jeg å kalle for eksempel btnOk for OkButton, eller en form for eksempel ImportRawFileDialog. Feltnavn i strukturer eller variabler forteller aldri noe om datatypen.

[Manfred]

hungarian notation er vel ofte sett på som "litt 1990" Det er slikt man gjør i vbscript, siden det ikke er forskjellige typer og slikt. Ikke i C#...

[kaffenils]

Selv pleier jeg å kalle for eksempel btnOk for OkButton, eller en form for eksempel ImportRawFileDialog.

 

For å kverulere litt: Det blir jo ikke noe bedre om du kaller det btnOk eller OkButton. Begge navnene prøver å fortelle hvilken type det er. Om navnet er OkButton, ButtonOk eller btnOk blir det uansett like galt.

[GeirGrusom]

Jeg gjør det fordi "Ok" alene ikke er et bra beskrivende navn, og egentlig gjør jeg det ikke for å fortelle om datatypen, men funksjonen til objektet. For eksempel så gjør jeg forskjell på Dialog og Form.

 

For eksempel MainForm og ImportRawFileDialog. Begge er forms, men oppfører seg på forskjellig måte.

[kaffenils]

<kverulere>

Så du navngir kontroller fordi det skal være lett å lese i koden hvilken type det dreier seg om. Jeg sier ikke at det er noe galt i det, og gjør det selv også, men for winforms/webforms kontroller så sier vi egentlig at det er greit å bruke en litt mutert hungarian notation.

 

Hva om Ok endres fra en knapp til en CheckBox (ok, dårlig eksempel)?

Hvordan navngir du en TextBox? Og hva om du endrer fra TextBox til ComboBox?

</kverulere>

[GeirGrusom]

Tja, hvis en bare sier at det går på funksjonen, og ikke datatypen, så er det ikke så stor forskjell i funksjon fra textbox til combobox?

 

FileNameText

Hvis denne gjøres om til enn combobox istedet vil den fortsatt fungere som før, med combobox.

 

Dersom det er en såpass annerledes kontroll at funksjonen ikke lenger er lik, vil jeg påstå at det er en helt annen kontroll og vil derfor kunne få et helt annet navn.

Endret 17. november 2008 av GeirGrusom

[kaffenils]

Jeg er selvfølgelig helt enig i at hungarian notation for variabler, properties etc et helt tullete, men jeg påpeker bare at vi har en tendens til å bruke det på UI-kontroller, nettopp for at det skal være mer mennesklig lesbart å skjønne hvilken type kontroll vi arbeider med.

 

Ser flere som anbefaler å prefixe med ux (User eXpreience) for å kunne skille brukerkontroller fra andre variabler.

[GeirGrusom]

Synes prefiks ser teit ut også jeg

[Gjest Slettet-aNZFa3]

Jeg syns det er greit å navngi kontrollere med f.eks:

btnOK

txtNavn osv, syns koden blir lettere å lese da jeg.

 

istedet for:

OK

Navn (Navn kunne heller vært navnet på variablen som henter ut verdien til textboxen)

[Manfred]

Og så skal du plutselig endre tekstboksen med noe til f.eks en drop-down... Skal den fortsatt være prefixet "txt" eller skal du da skrive om hele koden din?

[Gjest Slettet-aNZFa3]

Da blir det et annet problem, hmm, må tenke litt på den. Kommer tilbake med svar imorra.

[HDSoftware]

Hungarian Notation er delt opp i to emner:

System Notation og Apps Notation, der System Notation omhandler datatyper og Apps Notation er mere som en beskrivelse på bruken.

 

Selv har jeg aldri brukt system notation fordi for jeg nesten uten unntak har beskrivende navn på variabler og det er derfor uinterresant å slenge på en i for å anngi INT eller s for streng.

Apps Notation derimot bruker jeg absolutt hele tiden

 

Eneste jeg kan tenke meg der jeg nærmer meg System Notation må være at jeg alltid slenger på en p (liten P) foran på alle parametere, nettop for å anngi at det er en parameter det er snakk om

 

private void summer(int pTall1, int pTall2)
{
 int Tall1;
 int Tall2;
 Tall1 = pTall1;
  etc.....
}

og dermed muliggjør man som eksemplet viser at man kan ha variabler inen i koden som ikek kan forveksles med parametere.

 

Jeg er veldig enig at man ikek skal bruke System Notation på variabler, spesiellt i Visual Studio som veldig enkelt fortelelr gjennom intellicensen hva slags datatype det dreier seg om.

 

<Kverulere>

Til dere som sier man ikke skal bruke System Notation fordi datatypen kan endre seg:

Det spiller jo ingen rolle i Visual Studio. Det er jo bare å rename så sørger Visual Studio for å rename i resten av prosjektet

</Kverulere>

[GeirGrusom]

<Kverulere>

Til dere som sier man ikke skal bruke System Notation fordi datatypen kan endre seg:

Det spiller jo ingen rolle i Visual Studio. Det er jo bare å rename så sørger Visual Studio for å rename i resten av prosjektet

</Kverulere>

 

Men det funker dårlig dersom det er en dll du har laget, da vil en oppdatering av dll-en føre til at alle prosjekter som bruker den må endres og kompileres på nytt

[Velena]

Jeg var under det intrykk av at C# ikke kunne eksportere funksjoner slik at de kan brukes av andre programmer. Er dette feil?

Edit: Skjedde noe rart med posten o.0.

Endret 18. november 2008 av Velena

[GeirGrusom]

Du kan lage dll filer, og dessuten kan du jo prøve å legge til en .exe fil du har laget i C# som en referanse til et annet prosjekt

 

En kan også bruke COM programmer sammen med .NET programmer på en eller annen måte.

[HDSoftware]

Du kan lage dll filer, og dessuten kan du jo prøve å legge til en .exe fil du har laget i C# som en referanse til et annet prosjekt

 

En kan også bruke COM programmer sammen med .NET programmer på en eller annen måte.

Ikke bare kan du det, du kan bruke andre DLL'er også ved å "dekorere" funksjonene. Pussig navn spør du meg. Er selv vant til å kalle det prototype, men det spiller jo ingen rolle.

 

Jeg har gjort flere prosjekter der jeg benytter Clarion DLL'er i C# programmene. Dette fordi C# ikek støtter andre database format enn SQL og XML out of the box. Jeg har masse programmer som har TPS (topspeed) filer og når jeg trenger å lese/skrive i disse så lager jeg bare dette i Clarion og kompilerer en DLL, importerer denne under Resources og vips så kan jeg lese TPS filer gjennom Interop. Funker som ein drøym

 

Desverre er den omvendte ikke så enkel fordi Clarion selvsagt ikke støtter .NET, i hvertfall ikke enda helt da Clarion# fortsatt er i beta. Skal jeg gjøre det den andre veien så må jeg lage COM objekter av C# programmet mitt og det medfører bruk av regsvr32, noe som er helt utelukket (min personlige mening altså)

[Glenn F. Henriksen]

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 ;-) )

[HDSoftware]

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 ;-) )

Vet det. Var en trykkfeil/brainfart

[Glenn F. Henriksen]

Skal jeg gjøre det den andre veien så må jeg lage COM objekter av C# programmet mitt og det medfører bruk av regsvr32, noe som er helt utelukket (min personlige mening altså)

Jeg er litt nysgjerrig, hvorfor er det helt utelukket å registrere komponenten din som en COM-komponent?