Varför regioner fortsättning...

Jag använder regioner för att jag ser en otrolig nytta med dem precis som Gladh beskrev så slipper jag hålla på och leta. Absolut de "förorenar" koden men samtidigt blir det förbannat mycket enklare att hitta det jag letar efter. Det blir grupperat, sorterat och går väldigt snabbt att hitta.

Anledningen till att jag började med regioner var för att jag fick ett projekt på händerna där den som skapat det blandat svenska och engelska, haft helt meningslös namngivning och inte haft en susning om vad OOP innebär. Då är det rätt skönt att dela in det hela i lite regioner så att man inte behöver leta särskilt länge. Tänk dig själv att du har 5000 rader kod i en fil. En funktion (metod) kunde innehålla 200-300 rader kod några var ännu längre.

Det är inte roligt att scrolla reda på rätt metod då..

Sedan går det av bara farten av precis den anledningen som Gladh angav i tråden som du trollade till ;)

Jag tycker att regioner är bra när jag letar i kod. Har jag en rejäl klass kan det vara skönt att (1) veta var jag ska leta, (2) slippa scrolla jättelångt, eftersom alla regioner ska vara kollapsade, och därmed bara uppta en rad. Me like!

CatZ skrev:

Jag använder regioner för att jag ser en otrolig nytta med dem precis som Gladh beskrev så slipper jag hålla på och leta. Absolut de "förorenar" koden men samtidigt blir det förbannat mycket enklare att hitta det jag letar efter. Det blir grupperat, sorterat och går väldigt snabbt att hitta.

Anledningen till att jag började med regioner var för att jag fick ett projekt på händerna där den som skapat det blandat svenska och engelska, haft helt meningslös namngivning och inte haft en susning om vad OOP innebär. Då är det rätt skönt att dela in det hela i lite regioner så att man inte behöver leta särskilt länge. Tänk dig själv att du har 5000 rader kod i en fil. En funktion (metod) kunde innehålla 200-300 rader kod några var ännu längre.

Det är inte roligt att scrolla reda på rätt metod då..

Sedan går det av bara farten av precis den anledningen som Gladh angav i tråden som du trollade till ;)

Meningen är väl egentligen då att det är dags att börja refactorera, men har haft liknande problem :|.

Ledel skrev:

Jag tycker att regioner är bra när jag letar i kod. Har jag en rejäl klass kan det vara skönt att (1) veta var jag ska leta, (2) slippa scrolla jättelångt, eftersom alla regioner ska vara kollapsade, och därmed bara uppta en rad. Me like!

Har du en rejäl klass har du nog designat lite fel :h för lite hänsyn till sepration of concern, open closed principle, single responsability principle... då kan jag förstå att du vill ha regioner... för stora klasser är inte kul att leta i... spec inte med massa redundanta patterns av kodstycken m.m.

CatZ skrev:

Jag använder regioner för att jag ser en otrolig nytta med dem precis som Gladh beskrev så slipper jag hålla på och leta. Absolut de "förorenar" koden men samtidigt blir det förbannat mycket enklare att hitta det jag letar efter. Det blir grupperat, sorterat och går väldigt snabbt att hitta.

Anledningen till att jag började med regioner var för att jag fick ett projekt på händerna där den som skapat det blandat svenska och engelska, haft helt meningslös namngivning och inte haft en susning om vad OOP innebär. Då är det rätt skönt att dela in det hela i lite regioner så att man inte behöver leta särskilt länge. Tänk dig själv att du har 5000 rader kod i en fil. En funktion (metod) kunde innehålla 200-300 rader kod några var ännu längre.

Det är inte roligt att scrolla reda på rätt metod då..

Sedan går det av bara farten av precis den anledningen som Gladh angav i tråden som du trollade till ;)

hehe som Nicke säger... har du sådan kod är nått på tok galet och det behövs mer åtgärder än trolla till det med regioner...

regioner är ingen ursäkt för gämma dålig kod...

sorry but true...

Citat från Sean en väldigt bra kodare och fått många betyg hit o dit för sin kod m.m. av storfräsare:

Agreed. Not too long ago, I thought they were the greatest thing ever. I organized everything into neat little regions, like sorting silverware.

These days I see them hiding messes, like magic. Poof -- all that ugly code goes "away". Unfortunately it's only sweeping it under the rug. My reaction now is to remove them on sight so I can see the mess and can do the right thing via Extract Class.

johannormen skrev:

Har du en rejäl klass har du nog designat lite fel :h för lite hänsyn till sepration of concern, open closed principle, single responsability principle... då kan jag förstå att du vill ha regioner... för stora klasser är inte kul att leta i... spec inte med massa redundanta patterns av kodstycken m.m.

Riktigt så rejäla klasser tänkte jag mig nog inte, men nästan ;) Nä, men samtidigt som /// <summary>... tar sin plats överallt, så giller jag regioner, eftersom jag slipper se allt, i det ögonblicket, lull-lull.
Om det är en bra eller dåliga vana vet jag inte, men jag brukar aldrig skapa regioner innan jag kommit en bit med själva klassen, just för att inte "gömma" undan skräpkod. Jag skriver på ett tag, tills jag känner mig nöjd med den, tills den fungerar som den ska. Då skapar jag regioner för att enklare hitta när jag behöver ändra något litet. Tycker det funkar bra för mig.

Ledel skrev:

Riktigt så rejäla klasser tänkte jag mig nog inte, men nästan ;) Nä, men samtidigt som /// <summary>... tar sin plats överallt, så giller jag regioner, eftersom jag slipper se allt, i det ögonblicket, lull-lull.
Om det är en bra eller dåliga vana vet jag inte, men jag brukar aldrig skapa regioner innan jag kommit en bit med själva klassen, just för att inte "gömma" undan skräpkod. Jag skriver på ett tag, tills jag känner mig nöjd med den, tills den fungerar som den ska. Då skapar jag regioner för att enklare hitta när jag behöver ändra något litet. Tycker det funkar bra för mig.

Grejen är den att det är inte lika kul för andra som kanske kör andra standarder etc att behöva expandera en massa m.m. även om expand all finns så är det rätt onödigt att ens behöva ha det.

Det är alltid lättare att följa sitt arbetsätt men egentligen skall man koda kod för andra o inte sig själv, för en dag blir du en annan även för din kod (legazy kod du knappt minns att du skrev) eller någon annans kod... då är regioner inte kul... :h

johannormen skrev:

hehe som Nicke säger... har du sådan kod är nått på tok galet och det behövs mer åtgärder än trolla till det med regioner...

regioner är ingen ursäkt för gämma dålig kod...

sorry but true...

Ska vi slå vad om att det går fantastiskt mycket fortare att slänga in lite regioner än att försöka refactorera något på hebreiska? Vi kan slå vad om en miljon kronor, i så fall har jag precis blivit miljonär.

Om du läste vag jag skrev så var det inte för att gömma dålig kod det var för att hitta i den dåliga koden. Om du har fått en uppgift som du måste lösa Johan. Hugger du tag i massa gammal skit då när du är pressad på tid? Väljer du att hellre lägga 10 timmar i att navigera gammal dålig kod eller kan du tänka dig att underlätta för dig själv när det gäller att rota runt efter vad du behöver?

Har du blivit en mästare på bookmarks kanske? :P

CatZ skrev:

Ska vi slå vad om att det går fantastiskt mycket fortare att slänga in lite regioner än att försöka refactorera något på hebreiska? Vi kan slå vad om en miljon kronor, i så fall har jag precis blivit miljonär.

Om du läste vag jag skrev så var det inte för att gömma dålig kod det var för att hitta i den dåliga koden. Om du har fått en uppgift som du måste lösa Johan. Hugger du tag i massa gammal skit då när du är pressad på tid? Väljer du att hellre lägga 10 timmar i att navigera gammal dålig kod eller kan du tänka dig att underlätta för dig själv när det gäller att rota runt efter vad du behöver?

Har du blivit en mästare på bookmarks kanske? :P

bookmarks?

Nja... jag skulle nog städa upp i mån om tid i legazykoden, det är rätt kul faktiskt o bästa är att se de underbara framsteg man kan göra med dålig kod.
Skulle jag inte ha tid med det skulle jag absolut inte lägga tid på att lägga till regioner... bara för att visa hur dålig koden är...
Inte så pragmatiskt.

Då är det bättre att låta den vara som den är om den inte är trasig och jag måste ändra i den, måste jag ändra i den skulle jag ta mig tid att fixa till den, för det skulle oftast gå snabbare än att leta runt i kass kod...

Andreas Brink från factor 10 turnerade runt lite och pratade just om hur man enkelt faktisk med små trix kan städa upp legazy kod... Har pratat med honom om att köra ett seminarie om det för SweNug skall se igen om intresset finns kvar... Tror det kan vara matnyttigt för många... Han är en intressant talare dessutom.

johan skrev:

Det är alltid lättare att följa sitt arbetsätt men egentligen skall man koda kod för andra o inte sig själv,

Ja men johan, då skall du ju använda regioner i din kod om du skall programmera för oss andra :)...

För det mesta så tror jag det handlar om gammal vana. Och egentligen inget som jag bryr mig om hur någon gör. Om någon vill använda regioner och någon inte, spelar inte mig någon roll om jag får den koden, jag är mer intresserad av hur själva koden ser ut, inte hur den är uppdelad. Läste att du tycket att man skulle inte gruppera typ variabler högst upp utan att man skall deklarerar dem när de behövs och att metoderna skall komma i den ordning som de anropas och inte grupperas ihop som public/private...

Personligen så tycker jag det är extremt störande att deklarera en variable mitt i ett kodstycke, tycker det förstör flytet i koden, och om nu en metod inte är mer än 10-15 rader så spelar det ju verkligen ingen roll om de deklareras överst eller i koden, man lär ju se dem ändå.

Angående att skriva metoder som en uppsats, så kommer du aldrig klara det till hundra procent eftersom du vill kunna återanvända vissa metoder, vilket gör att du från en metod måste hoppa uppåt i din kod för att kunna återanvända den kod som du skrev tidigare. Även där bryr jag mig inte så mycket hur koden är skriven. Jag personligen tycker bäst om att försöka gruppera ihop de metoder som hör ihop, men skilja ut properties och eventhandlers från dessa metoder, vilket gör att jag inte får en uppsatsliknande kod, men det är bara jag. Jag tycker det är mycket enklare att hitta det jag letar efter när det blir grupperat så...

- M

Gladh skrev:

johan skrev:

Det är alltid lättare att följa sitt arbetsätt men egentligen skall man koda kod för andra o inte sig själv,

Ja men johan, då skall du ju använda regioner i din kod om du skall programmera för oss andra :)...

För det mesta så tror jag det handlar om gammal vana. Och egentligen inget som jag bryr mig om hur någon gör. Om någon vill använda regioner och någon inte, spelar inte mig någon roll om jag får den koden, jag är mer intresserad av hur själva koden ser ut, inte hur den är uppdelad. Läste att du tycket att man skulle inte gruppera typ variabler högst upp utan att man skall deklarerar dem när de behövs och att metoderna skall komma i den ordning som de anropas och inte grupperas ihop som public/private...

Personligen så tycker jag det är extremt störande att deklarera en variable mitt i ett kodstycke, tycker det förstör flytet i koden, och om nu en metod inte är mer än 10-15 rader så spelar det ju verkligen ingen roll om de deklareras överst eller i koden, man lär ju se dem ändå.

Angående att skriva metoder som en uppsats, så kommer du aldrig klara det till hundra procent eftersom du vill kunna återanvända vissa metoder, vilket gör att du från en metod måste hoppa uppåt i din kod för att kunna återanvända den kod som du skrev tidigare. Även där bryr jag mig inte så mycket hur koden är skriven. Jag personligen tycker bäst om att försöka gruppera ihop de metoder som hör ihop, men skilja ut properties och eventhandlers från dessa metoder, vilket gör att jag inte får en uppsatsliknande kod, men det är bara jag. Jag tycker det är mycket enklare att hitta det jag letar efter när det blir grupperat så...

- M

Hmm när det gäller att gruppera medlemsvariabler så håller jag med dig om att de skall grupperas högst upp ovanför konstruktionerna, däremot vet jag inte riktigt om jag håller med dig att man skall deklarera alla lokala variabler i din metod överst i metoden. Där tycker jag nog att det skall hålla sig till flödet i metoden p.g.a. olika initieringar av variabeln. t.ex. känns det dumt att ha det såhär tycker jag.

Det känns som att dom är onödiga där och att det var sådant man gjorde när man dimade saker i sin ASP kod högst upp.

private void DoSomething()
{
    string firstName;
    string lastName;

    ... senare i koden
    firstName = GetFirstNameSomeHow();
    --- mer kod
    lastName = GetLastNameSomeHow();
}

Gladh skrev:

johan skrev:

Det är alltid lättare att följa sitt arbetsätt men egentligen skall man koda kod för andra o inte sig själv,

Ja men johan, då skall du ju använda regioner i din kod om du skall programmera för oss andra :)...

För det mesta så tror jag det handlar om gammal vana. Och egentligen inget som jag bryr mig om hur någon gör. Om någon vill använda regioner och någon inte, spelar inte mig någon roll om jag får den koden, jag är mer intresserad av hur själva koden ser ut, inte hur den är uppdelad. Läste att du tycket att man skulle inte gruppera typ variabler högst upp utan att man skall deklarerar dem när de behövs och att metoderna skall komma i den ordning som de anropas och inte grupperas ihop som public/private...

Personligen så tycker jag det är extremt störande att deklarera en variable mitt i ett kodstycke, tycker det förstör flytet i koden, och om nu en metod inte är mer än 10-15 rader så spelar det ju verkligen ingen roll om de deklareras överst eller i koden, man lär ju se dem ändå.

Angående att skriva metoder som en uppsats, så kommer du aldrig klara det till hundra procent eftersom du vill kunna återanvända vissa metoder, vilket gör att du från en metod måste hoppa uppåt i din kod för att kunna återanvända den kod som du skrev tidigare. Även där bryr jag mig inte så mycket hur koden är skriven. Jag personligen tycker bäst om att försöka gruppera ihop de metoder som hör ihop, men skilja ut properties och eventhandlers från dessa metoder, vilket gör att jag inte får en uppsatsliknande kod, men det är bara jag. Jag tycker det är mycket enklare att hitta det jag letar efter när det blir grupperat så...

- M

Stämmer bra det med members. Jag lägger dem där de hör hemma för att man skall behöva leta upp o ner i koden. Massa research som gjort ang detta.
Sjukt nog gilla jag idén o tyckte personligen så som många andra att det blev sjukt mkt snyggare kod.

Några anledningar:

Först vill man som ex code reviewer eller programmerare av annans kod snabbt läsa koden, slippe se flera rader med variabler som man ändå längre ner kommer ha glömt av.

Sen så vill man gärna se all den kod en prop eller metod använder sig av på en och samma vy, för att slippa hoppa runt i koden för att undra vad eller vart membersarna sätts o kommer från.

ex:

int number = 0;
puplic int Number
{
    get { return number; }
    set { number = value; }
}
[/kode]

[kod]
var hasBeenExecutedOnce = false;
public void DoFoo()
{
     if(!hasBeenExecutedOnce)
     {
           Execute();
           hasBeenExecutedOnce = true;
     }
}

Ovan ser man en propp, Proppen är det enda man skall använda i hela sin kod till 99,9% kan finnas något undantag någon gång fär man vill använda dess fält, men vilken man inte bör. Detta tar även en rad guidelines upp varför.
Design By COntract och Defensive Programming är två skäl.
Där av är det helt menlingslöst att lägga alla proppar members i toppen då man gärna vill se vem de tillhör med en gång. För du kommer aldrig kunna memmorera dina members ändå.

Metodens kod.
I detta fall ligger kanske denna metoden på rad 100 det är bara denna metod som har members hasBeenExecutedOnce och som läsare av kod vill man gärna veta hur denna variabel lever i din kod. Här ser man med en gång, aha den hör till denna metod, ingen annan delar på den. Man vet direkt dess default värde och kan köra koden i sitt huvud utan större problem. Du slippe alltså scrolla o lämna den kod du läser för få infomration av den. Det blir såååå sjukt mkt lättare dör hjärnan att koncentrera sig då, detta mkt pga närminnet som inte klarar av så mkt saker samtidigt. Gjorts resaerch på detta.

MEN skulle det vara så att flera metoder delar på en member då lägger man dem i toppen för att visa tidigt, här är nått som delas av andra.

Mvh Johan

johan skrev:

MEN skulle det vara så att flera metoder delar på en member då lägger man dem i toppen för att visa tidigt, här är nått som delas av andra.

Tycker det verkar mer omständigt att ha membervariabler på 2 olika ställen. Ibland ligger de högst upp och ibland ligger de vid metoden. Du har ju fortfarande nackdelen att du i din metod så fall måste gå hela vägen upp för att hitta variablen, plus att du lagt in momentet med att ha variabler på 2 olika ställen. Själv så skulle jag nog bli mer förvirrad var någonstan variablerna finns någonstans än att vet att det alla finns på ett ställe, och jag kan gå dit och hitta informationen där...

Men återigen det är olika från person till person och alla fungerar ju som tur väl inte likadant.

Men iprincip så skulle din kod kunna se ut så här:

public class Test{

  private int _Age;

  public int CalculateAge(int age)
  {
    ...
    return age;
  }

  private string _Firstnamn;
  public string Firstname{
    get{return _FirstName;}
    set{_FirstName = CheckFirstName(value);}
  }
  public string CheckFirstName(string firstname)
  {
     ...
  }

  private string _LastName;
  public string LastName{
   get{return _LastName;}
   set{_LastName = CheckLastName(value);
  }
  private string CheckLastName(string lastName)
  {
     ...
     return lastName;
  }

  public bool CheckAgeOverYear(int year)
  {
     return year > _Age;
  }
}

Här skulle jag ha svårt att snabbt hitta den property som jag skulle vilja ha tag i eftersom jag inte vet var i klassen den ligger, och ju längre klassen blir ju längre tid tar det för mig att scrolla fram rätt positon. Men det är ju som sagt bara jag, du tycker säkert inte det...

- M

Ett hett tips för att navigera i kod är att använda incremental search (Ctrl + i). Mycket smidigt!

Men återigen det är olika från person till person och alla fungerar ju som tur väl inte likadant.

Hur löser man sett sådant här problem när en kodkonvention skall spikas för projekt när man har en som tycker att de skall grupperas och en tvärtom. Vems kör man på?

Det hade ju blivit katastrof om man i vissa klasser hade allt samlat och i andra inte bara för att det är olika personer som skrivit den.

Gladh skrev:

johan skrev:

MEN skulle det vara så att flera metoder delar på en member då lägger man dem i toppen för att visa tidigt, här är nått som delas av andra.

Tycker det verkar mer omständigt att ha membervariabler på 2 olika ställen. Ibland ligger de högst upp och ibland ligger de vid metoden. Du har ju fortfarande nackdelen att du i din metod så fall måste gå hela vägen upp för att hitta variablen, plus att du lagt in momentet med att ha variabler på 2 olika ställen. Själv så skulle jag nog bli mer förvirrad var någonstan variablerna finns någonstans än att vet att det alla finns på ett ställe, och jag kan gå dit och hitta informationen där...

Men återigen det är olika från person till person och alla fungerar ju som tur väl inte likadant.

Men iprincip så skulle din kod kunna se ut så här:

public class Test{

  private int _Age;

  public int CalculateAge(int age)
  {
    ...
    return age;
  }

  private string _Firstnamn;
  public string Firstname{
    get{return _FirstName;}
    set{_FirstName = CheckFirstName(value);}
  }
  public string CheckFirstName(string firstname)
  {
     ...
  }

  private string _LastName;
  public string LastName{
   get{return _LastName;}
   set{_LastName = CheckLastName(value);
  }
  private string CheckLastName(string lastName)
  {
     ...
     return lastName;
  }

  public bool CheckAgeOverYear(int year)
  {
     return year > _Age;
  }
}

Här skulle jag ha svårt att snabbt hitta den property som jag skulle vilja ha tag i eftersom jag inte vet var i klassen den ligger, och ju längre klassen blir ju längre tid tar det för mig att scrolla fram rätt positon. Men det är ju som sagt bara jag, du tycker säkert inte det...

- M

Tja.

Grejen är den att för ex proppar måste du inte veta dess members. Proppar lägger jag alltid i toppen. fast först konstruktor... Eller de members som delas av konstruktorn eller andra metoder.

Proppar använder du inte dess members och du vet ändå att propparna är i toppen pga att du vill exponera ditt contract tydligt, ditt publika state.

Sen har du ju intellisense som snabbt ger dig svar på propparna, så helst skall du inte ens behöva scrolla för att veta om dina proppar, då har du nog rät mkt kod och din klass gör mer än vad den är till för att göra. Ett annat problem. Single responsavbility principle.

Ex en User skall inte ha kod rörande skriva en fil på disk. (kass exempel men villa visa två tydliga fall då User inte gör det en user skall) Här skulle man istället ha två klasser en user och en writer som user använder sig av.

Sen är det inte så störigt om du tänker efter att ha din member sosm bara JUST den metoden använder sig av då du tydligt ser det när du läser och ev to m debuggar koden i minnet vid ex code review.

I mitt fall vet du att denna hasBeenExecuted är false, tappar du bort vad den var satt till så ser du den snabbt och behöver inte tappa bort dig helt i vad du höll på med. Närminnet kan inte minnas för mkt och en scrollning för att se vad members var satt till kan göra att du glömmer av vart du var i koden etc... Du vet oxå med säkerhet att denna member delar ingen på... medans members i toppen kan du aldrig vara säker på.

public void DoFoo()
{
    if(!hasBeenExecutedOnce)
...

När du ser denna rad hur tänker du då?

Jag försöker inte övertyga någon här... utan vill mer förklara varför många kod-forskare anser man skall koda på detta sätt...

Phorpher skrev:

Ett hett tips för att navigera i kod är att använda incremental search (Ctrl + i). Mycket smidigt!

True... men när du gör detta så tappar du bort dig från den kod du var på och måste göra mer än vad nöden kräver... Tid är pengar.

"En pragmatisk programmerare kan vara hundra gånger effektivare än medelutvecklaren."

GÖr så lite som möjligt för att förstå sin kod.

Ex säger många som inte kan hantera enhetstestning att man kan lika gärna debbugga än ha enhetstest... Det är sant, men har man tid till det? Eller har man en deadline man vill nå raskt?

Det jag brukar använda regioner till är:
- Dela upp klassen i privata och publika metoder, metoder som är "Not Implemented" så att säga.

Inte så mycket annat.. har inte grunnat så mycket på vad dess funktionalitet är egentligen.

johannormen skrev:

Varför använder ni dem?

För att Visual Studio inte är lika bra på att presentera kod som t.ex. Eclipse. #regions har sina poänger tycker jag, men när jag hamnade i Java/Eclipse efter att ha suttit med C#/VS nåt år insåg jag att det inte var regions man ville ha egentligen, utan ett bättre sätt att navigera genom koden.