Hungarian notation?

Peter S skrev:

Men som tidigare påpekats gör ju prefixet this det än mer självklart att det är en instansvariabel. Det går inte att ta miste på.

Underscore som prefix är precis lika redundant som "str", "int", "cb" eller något annat, och är verkligen något som "kladdar ned koden" (till skillnad från this).

Men det är ju såklart bara min åsikt (och lite OT).

Jo, jag förstår det resonemanget, men det känns aningen teoretiskt för mig.

Är du inte konsekvent med att alltid använda "this" funkar det ju utan också, så det är säkert att "this" innebär att det är en instansvaribel men inte säkert att det inte är det om "this" saknas. Så inte heller det är ett tvärsäkert sätt att skilja på instansvariabler...och det är väl inte så vanligt att man vill komma åt en lokal variabel men råkar blanda ihop den med en instansvariabel och har glädje av att kompilatorn fångar det om man kör med "this".

Då jag använde "this" var syftet helt enkelt att göra det enklare att överblicka koden och för det ändamålet är underscore smidigare att både läsa och skriva. Så även om det från ett teoretiskt perspektiv är "kladdigare" innebär det i praktiken att koden blir mer lättläst och lättskriven tycker jag i.a.f.

Detta är väl allt aningen OT, men jag kan hålla med om att själva principen är densamma som med Hungarian notation, det är kladd som kan anses som överflödig med ett bra IDE. Men Hungarian är i mitt tycke rätt jobbigt att läsa och skriva och kostar mer än det smakar i moderna utvecklingsmiljöer medans ett underscore är tillräckligt transparent för att vara värt sitt pris.

Peter skrev:

Men som tidigare påpekats gör ju prefixet this det än mer självklart att det är en instansvariabel. Det går inte att ta miste på.

this.FirstName = "Magnus";

Du är helt säker på att "Magnus" sätt till en instansvariabel här?

- M

Gladh skrev:

Peter skrev:

Men som tidigare påpekats gör ju prefixet this det än mer självklart att det är en instansvariabel. Det går inte att ta miste på.

this.FirstName = "Magnus";

Du är helt säker på att "Magnus" sätt till en instansvariabel här?

- M

Vad är alternativet då menar du?

public void MyMethod(string firstName)
{
   this.FirstName = firstName;
}

public string FirstName{
  get{return "No nothing here, keep on walking";}
  set{return;}
}

Inte så kreativ exempel, utan visar mer att bara för att man sätter this framför så behöver det inte vara en instansvariable och framför allt om det är en properties som i exemplet ovan så vet man faktistk inte vad som händer.

Så det jag reagerade på vara Peters syn på att det inte gick att ta miste på att det var en instansvariabel som man använde bara för att man sätter this framför, det kan ju lika bra vara en property.

- M

Gladh skrev:

public void MyMethod(string firstName)
{
   this.FirstName = firstName;
}

public string FirstName{
  get{return "No nothing here, keep on walking";}
  set{return;}
}

Inte så kreativ exempel, utan visar mer att bara för att man sätter this framför så behöver det inte vara en instansvariable och framför allt om det är en properties som i exemplet ovan så vet man faktistk inte vad som händer.

Så det jag reagerade på vara Peters syn på att det inte gick att ta miste på att det var en instansvariabel som man använde bara för att man sätter this framför, det kan ju lika bra vara en property.

- M

Det där tolererar inte Java. Den kommer gnälla över att det inte finns någon instansvariabel "FirstName". Ingen referering mot metoden FirstName görs utan ().

Som sagt var så bör man också kanske ta lite hänsyn till vilket programmeringsspråk man sitter i.

Java tolererar kanske inte det, Vb tolererar inte heller att man använder Me. framför properties, dock tillåter C# this framför properties.

Jag brukar döpa UI fält med stor bokstav, ex. FirstName.
Det skulle då ge koden:

string firstName = FirstName.Text;

Är det helt fel enligt gällande standard (Camel, Pascal)?
Det ser ju i alla fall snygg ut! :)

Gladh skrev:

this.FirstName = "Magnus";

Du är helt säker på att "Magnus" sätt till en instansvariabel här?

- M

Jag visste faktiskt inte att C# tillät det, så nej, det är jag inte. Dock skulle jag gissa att du just i detta fall tilldelar en property i.o.m. det versala effet.

Men å andra sidan är jag mindre säker på att tilldelningen _FirstName = "Magnus" görs till en instansvariabel. Såvida jag inte studerat riktlinjerna för hur kod skall skrivas i det aktuella projektet, finns det ingenting i "_FirstName" som antyder att det skulle vara en klassproperty.

doggelito skrev:

Jag brukar döpa UI fält med stor bokstav, ex. FirstName.
Det skulle då ge koden:

string firstName = FirstName.Text;

Är det helt fel enligt gällande standard (Camel, Pascal)?
Det ser ju i alla fall snygg ut! :)

Jag ser det fortfarande som en medlemsvariabel oavsett typen, så jag hade satt camelCase

Peter skrev:

Jag visste faktiskt inte att C# tillät det, så nej, det är jag inte. Dock skulle jag gissa att du just i detta fall tilldelar en property i.o.m. det versala effet.

Där ser man hur tokigt det kan bli. Jag skulle också gissa på en property med tanke på versal första bokstav, men som sagt det är ju som man är van vid, och jag misstänker att iallafall 98% skriver sina properties med stor bokstav...

Peter skrev:

Såvida jag inte studerat riktlinjerna för hur kod skall skrivas i det aktuella projektet, finns det ingenting i "_FirstName" som antyder att det skulle vara en klassproperty.

Det finns inget som antyder att _FirstName är vare sig variabel eller property om man skall hårddra det. Däremot så skulle ju säkert 98% (om inte fler) av alla c# utvecklare skriva sina properties utan _ som i exemplet ovan. Men helt säkert är det ju inte.

Däremot så skulle jag vara hyfsat säker på att _FirstName är en instansvariable, precis som jag skulle vara hyfsat säker på att this.firstName skulle vara en instansvariable och att this.FirstName skulle vara en property. Mest bara för att de flesta väljer att skriva koden på det sättet. Men helt säker kan man aldrig vara och därför abrovinkerna med me, m_ och _.

- M

Jag föreslår att man kör med Microsoft's guidelines dvs camelCase. Kör man med microsoft's Source Analysis verktyg så kräver den this. på medlemsvariabler, medlemsproperties och metoder.
Personligen gillar jag this. men tycker även att _ fungerar men m_ tycker jag dock är riktigt fult. Det är mina åsikter.

Peter S skrev:

Men som tidigare påpekats gör ju prefixet this det än mer självklart att det är en instansvariabel. Det går inte att ta miste på.

Underscore som prefix är precis lika redundant som "str", "int", "cb" eller något annat, och är verkligen något som "kladdar ned koden" (till skillnad från this).

Men det är ju såklart bara min åsikt (och lite OT).

Håller inte med dig en secund här... För det först är hungarian notation där för att förklara med fula förkortningar (vilket man skall untvika allmänt) vad en variabel kan va för typ... Något som är helt onödigt om man använder tydliga namn istället som i verkligheten reflekterar vad det kan vara för typ. Så som Name aldrig är siffor och Number aldrig är bokstäver.

_ är en indikator för ett tillstånd inte för en typ... Det är stor skillnad.
Egentligen skulle _ inte ens behövas för har man ex små metoder där du ser hela metoden framför dig ser du både tydligt och enekelt att din flytande variabel knappas är en input eller deklarerad i metoden och kan snabbt på 2 röda förstå att det är en medlemdvariabel på class scopesnivå... Och varken this. eller _ eller m_ gör någon direkt nytta då...

Jag själv använder som sagt _ för att göra det extra tydligt men kan lika gärna strunta i att använda det, men this. är sååååå ottroligt extremt onödigt...

johannormen skrev:

Håller inte med dig en secund här... För det först är hungarian notation där för att förklara med fula förkortningar (vilket man skall untvika allmänt) vad en variabel kan va för typ... Något som är helt onödigt om man använder tydliga namn istället som i verkligheten reflekterar vad det kan vara för typ. Så som Name aldrig är siffor och Number aldrig är bokstäver.

_ är en indikator för ett tillstånd inte för en typ... Det är stor skillnad.
Egentligen skulle _ inte ens behövas för har man ex små metoder där du ser hela metoden framför dig ser du både tydligt och enekelt att din flytande variabel knappas är en input eller deklarerad i metoden och kan snabbt på 2 röda förstå att det är en medlemdvariabel på class scopesnivå... Och varken this. eller _ eller m_ gör någon direkt nytta då...

Jag själv använder som sagt _ för att göra det extra tydligt men kan lika gärna strunta i att använda det, men this. är sååååå ottroligt extremt onödigt...

Kan vara användbart i följande fall dock, så att dom inte krockar :)

private string firstName;

public Person(string firstName)
{
    this.firstName = firstName;
}

Nickemannen skrev:

Kan vara användbart i följande fall dock, så att dom inte krockar :)

private string firstName;

public Person(string firstName)
{
    this.firstName = firstName;
}

Givetvis, det blir användbart i det fallet. Men om vi skall vara lite si så där, så kommer denna användbarhet också in:

private string _firstName;
public Person(string firstName)
{
    _firstName = firstName;
}

Men personligen anser jag att detta är en smaksak, vilket inte skall ha så stor betydelse, men som sagt var så är ju den egentliga huvudsaken att samtliga inom organisationen skriver lika, annars kan det ju bli lite jobbigt i längden...

Jag vet åtminstone till 90% att

this.Name  är en property
this.name är en instansvariabel

Name är en property
_name är en instansvariabel

Dock har jag sett sådana här saker på en del ställen:

this._name

:)

Fredde Mannen skrev:

Dock har jag sett sådana här saker på en del ställen:

this._name

:)

HUGA HÄDELSE!!! Vik undan onda demon!!!!

Nickemannen skrev:

Kan vara användbart i följande fall dock, så att dom inte krockar :)

private string firstName;

public Person(string firstName)
{
    this.firstName = firstName;
}

Jag skulle försöka undvika att ha samma namn här som en annan member av många skäl. Vissakod gurus förespråkar notationen in och out på parametrar för att göra det tydligt hur de är tänkta att leva i ens scope.

public Person(string inFirstName)

På just proppar använder jag alltid _ för dess members. Jag tycker det är grötigt o fult att ha samma namn som din kod ovan även om this. används. Men ditt stora problem här är inte:

fristName = firstName utan att du faktiskt sätter en properties antar jag member då du i regel ALLTID skall gå via propertyn.

FirstName = firstName

CatZ skrev:

HUGA HÄDELSE!!! Vik undan onda demon!!!!

Jepp.. man har sett mycket...

johannormen skrev:

fristName = firstName utan att du faktiskt sätter en properties antar jag member då du i regel ALLTID skall gå via propertyn.

FirstName = firstName

På tal om vilket, vore det inte galet smutt om man kunde deklarera fälten som scopade till propertyn, så att det inte går att komma åt dem annat än genom settern? Inte bara pga säkrare kod men också för att man gör antalet namn i klassens namnrymd färre = autocompletion funkar bättre.

public class X
{
    public int Y
    {
        int y = 0; 
        get { return y; }
        set 
        { 
            if (value < 0) throw new ArgumentException();
            y = value; 
        }
    }

    public X(int initialValue)
    {
        Y = initialValue;
        // "y = initialValue" ger kompileringsfel pga att y är scopad till Y-propertyn
    }

}

spango skrev:

På tal om vilket, vore det inte galet smutt om man kunde deklarera fälten som scopade till propertyn, så att det inte går att komma åt dem annat än genom settern? Inte bara pga säkrare kod men också för att man gör antalet namn i klassens namnrymd färre = autocompletion funkar bättre.

public class X
{
    public int Y
    {
        int y = 0; 
        get { return y; }
        set 
        { 
            if (value < 0) throw new ArgumentException();
            y = value; 
        }
    }

    public X(int initialValue)
    {
        Y = initialValue;
        // "y = initialValue" ger kompileringsfel pga att y är scopad till Y-propertyn
    }

}

Problemet här är att det faktiskt finns det undantag där man vill sätta ett annat tillstånd på en propps member. De är få o de sker väldigt sällan... Men det kan ske. Därför bör de sättas utanför.

johannormen skrev:

De är få o de sker väldigt sällan... Men det kan ske. Därför bör de sättas utanför.

Jag menar inte att man skulle tvingas göra på det viset (finns ju även massor av fall där man vill ha privata fält som inte behöver exponeras i nån property), men att det skulle gå att göra så. Litegrann som att deklarera saker som private eller readonly - kan du så gör det, men låt bli om det inte funkar. När man har ett syntaktiskt scope där, känns det ju dumt att inte utnyttja det :)