johan skrev:
public SomeThingToHandle CreateSomeThingToHandle()
{
var someThingtoHandle = new SomeThingToHandle();
someThingtoHandle.Number = GetNextValidNumber();
...
return someThingToHandle;
}
private int GetNextValidNumber()
{
return GetNumA * GetNumB - GetNumC + NumberA;
}
Nu vet jag att detta är ett enkelt exempel och förstår precis vad du menar med det (så har vi klarat av det). Men det sagt så skall jag lägga in mina 2 cent här.
I ett sådant enkelt exempel som detta, där vi antar att GetNextValidNumber() inte kan återanvändas till något annat än just till den raden där ursprungskoden fanns, och det dessutom är gansaka intetsägande med en rad som bara lägger ihop 4 tal, så ser jag ingen som helst anledning att bryta ut detta och lägga i en egen funktion. Och det av 2 anledningar.
1. Det kommer krävas flerkod rader för mig att skriva eftersom jag behöver skapa en ny funktion.
2. Eftersom själva uträkningen är intetsägande (och inte hör hemma någonstans förutom i ursprungskoden) så måste jag kommenterar metoden ordentligt så när jag sedan kollar igenom min kod och ser denna metod 6 månader senare, så skall jag kunna förstå vad den gör och till vem den är relaterad till.
Själv så ser jag ingen anledning till att hålla funktioner nere till ett max ANTAL rader, utan funktionen skall istället vara så liten och optimerad till det den gör, kod som kan återanvändas av andra funktioner skall givetviss flyttas ut, så det inte finns redundant kod. Att flytta ut kod för att få ner antalet rader är helt meningslöst, det är samma mängdkod som skrivs (till och med mer) alltså så minskar du inte risken med att införa buggar i metoderna.
Det jag kan tänka mig är om jag har if-satser där kodmängden inom dessa ifsatser blir för stora så kan jag flytta ut dessa till egna metoder för att öka läsförståelsen i den första metoden. Men om jag har 2 rader i min if-sats som är välavgränsade för just den metoden, så skulle jag aldrig skapa en ny metod för att lägga dessa 2 rader kod där i. Koden blir inte enklare att förstå för att man måste hoppa till 10 olika metoder för att kunna hantera 20 rader kod, bara för att man skall kunna skapa kod enlig SrR...
Dessutom så kan man ju fråga sig vad är Singel i sammanhanget, om dess uppgift är att skapa ett nytt objekt av någonting, så kan det ju även innebärar att det skall instasieras av data, och inte bara skapa ett objekt och sedan returnera tillbaka det. Hur bestämer man var gränsen går.. är det enda nere så att man har en metod för varje property som man sätter. Eller låter man en metod sätta alla property och en annan skapa objektet, eller har man en metod som skapar objektet och sätter alla property...
Att skriva program handlar inte om att följa vissa patterns så strikt som möjligt, patterns är till för att underlätta för utvecklaren och de finns där av en anledningen, men man skall inte glömma bort att i slutet av dagen så är det utvecklaren som skall stå bakom sin kod, och kunna underhålla den.
På förra stället som jag jobbade på hade man tagit fram riktlinjer för hur varje projekt skulle delas upp i olika lager och vad som skulle finnas i dessa lager, i teorin såg det riktig bra ut, men i verkligheten så hade man alldeles för mycket overhead för ungefär 85% av alla projekt som skrevs, de sista 15% var de som verkligen hade något att vinna på att följa dessa riktlinjer. De andra 85% var helt enkelt för små projekt (och för unka) för att ha någon nytta av att skapa services av alla affärslogik, och hade heller inte någon nytta av att man snabbt kunde skifta mellan ett WebUI och WinUI. Där var väldigt mycket YAGNI i dessa riktlinjer...
Alla patterns och riktlinjer skall appliceras med sunt förnuft och inte ut i sista beståndsdelen, då slutar det med att man lägger 80% av sin tid på att följa riktlinjer och 20% på att lösa problemet och inte tvärtom.
Angående felhantering så har jag nästan samma ståndpunkt som johan. Egentligen skall man inte kasta fel om felet inte är oväntat (där av namnet exception) utan man skall hantera det på ett annat sätt, just med true/false eller felkoder. Tyvärr är det inte speciellt praktiskt och därför skulle jag även kasta exceptions i de flesta fallen. Fall där man inte bör göra det är om man utvecklar för websiter och där felet kommer att vara vanligt förekommande (typ att man glömt fylla i något värde eller så), detta eftersom en exceptions suger prestanda, och i en win-applikation där du sitter själv så kommer man inte märka det, men helt plötsligt 200 besökare skulle börja kasta en massa exceptions i en web-appplikation så kommer det märkas tydligt...
Håller även med om att namnen på metoder och variabler skall vara tydliga och självförklarande, med intellisens (nej jag använder inte Resharper) så hittar man ju namet snabbt ändå, och tydliga namn som är självbeskrivande är underbara när man tittar på sin kod 6 månader senare...
Glömde bort kommentarerna...
Jag ser faktiskt inte kommentare i koden som en styggelse om de mer beskriver varför jag gör något än snarare hur jag gör det. Har många exempel på kod som är väldigt självförklarande vad den gör, men där man undrar varför den gör som den gör, och där ramlar det in en kommentar på varför denna kod ligger där den gör. Oftas blir det så i slutfasen av projekten när beställaren kommer på att den glömt några viktiga krav. Och då kommer fulhacken fram :). Eller när man måste koda sig runt konstiga implementationer av MS...
- M
