Kom igen johan! Det var ett exempel på hur man kan skriva kod på olika antal rader och inte hur man skriver korrekt kod... Men om du vill gnälla på sandlådenivån så är ditt exempel inte speciellt mycket bättre.
public void CheckIfNotNullOrEmpty(string inParam,string paramName)
{
if(string.IsNullOrEmpty(inParam))
throw new ArgumentNullException("Input parameter " + paramName + "cannot be null or empty string")
}
För det första så är det ett förväntat värde att inparametern kan vara både Null och tom, alltså skall inga exceptions kastas, exceptions kastas bara när man får ett oväntat fel i koden. Det har du inte i detta sammanhang.
Först vill jag påpeka att jag inte kastar sand, sen vill jag poängtera att mitt inlägg handlar om varför få rader och att man skall försöka landa runt 10 rader/metod som föregående argumenterare påpekat. Ber om ursäkt om det kändes som en näve sand. :l
Att inputparametrar är av fel typ är typiskt exempel på när exceptions skall kastas. I detta fall får utvecklarna snabbt veta om de gör fel. Dvs Du som programmerare skall se till så andra använder din kod rätt. Det är vad bla Design by Contract och Defensive programming handlar om.
private User CreateUser(int identifier, string firstname, string lastname)
{
CheckIfNotNullOrEmpty(firstName,"FirstName");
CheckIfNotNullOrEmpty(lastname,"lastName");
User user = new User(identifier,firstname,lastname);
return user;
}
I denna kodsnutt så kommer en användare aldrig att skapas om LastName eller FirstName är NULL eller tomt, eftersom du kastar ett ArgumentException när detta inträffar, vilket inte alls är vad min exempelkod visar, utan där skapas användaren ändå, men utan Displaynamnet satt, din refaktoring har alltså ändrat hela utgången av vad metoden gjorde från början... inte speciellt bra!
Precis, och det är exakt vad man skall försöka åstakomma oxå. I ditt fall har du massa halvlevande tillstånd. Dvs du har klasser där saker kan vara null, men vems uppgift är det att ta reda på sånt? de som använder koden eller de som förser användaren med informationen. I detta fall bör inte en användare kunna skapas om viktiga värden är null eller tomma. Det är ett fel. Och objekt med nullvärden är en av de största skälen till underligga buggar i ett system. Om nu null skulle vara ok och inte orsaka problem bör man istället köra med nullable patterns för att inte få systemet att kasta oväntade null refference exeptions vilket det bergigs kommer göra om en user kan skapas med null tillstånd.
public class User
{
... proppar ..
public string DisplayName
{
get { return CreateDisplayName(); }
}
private string CreateDisplayName()
{
StringBuilder displayNameBuilder = new StringBuilder();
displayNameBuilder.Append(FirstName)
displayNameBuilder.Append(", ")
displayNameBuilder.Append(Lastname);
return displayNameBuilder.ToString();
}
}
Ur en prestanda synpunkt, så borde mer rätt vara att ha en lokalvariabel på klassen User som sätts i CreateDisplayName() och CreateDisplayName() anropas varje gång som set-metoderna anropas för LastName eller FirstName.
Detta är oxå ett klassiskt fel. Prestanda vad är det? Prestanda är aldrig några problem förrän de blir problem. Idag lägger många utvecklare ca 80% av sin tid att optimera sin kod helt i onödan. Det är mkt tid att spara. I detta fall blir prestandaproblemet om Dispayname skulle anropas över flera 100 000 ggr. Om ens då. Jag kan mycket väl tänka mig att Displayname används mer sällan än de andra propparna på en user. Vilket gör att adda extra kod som inte behövs är att slösa tid och inte en vist över huvudtaget. YAGNI (You arn't gonna need it) gör inget du inte behöver förrän du vet att du behöver det. Oprtimering för man först sist det är då man först vet om det ens behöver göras och fördelen är att det är väldigt få ställen man behöver optimera då istället för att optimera 80% av koden i onödan. Även logisk optimering (som många kör med) gör att system istället får långsammare då logik inte går ihop med praktik när det gäller kod. Även om man så gärna önska det vore så...
>Skapar man en User vill man ju gärna att dess displayname alltid ger resultat,
Hur kan du förutsätta det, har du sett designspecen?
För att annars hade man inte haft proppen på user överhuvudtaget.
Att ha user.DisplayName som ger null är inte så smart, vilket jag förklara tidigare varför.
Skall vi fortsätta kast sand på varandra???
Du tog det nog lite för personligt, sorry, var inte min mening alls att göra dig upprörd utan försöka förklara varför jag inte tycker dina argument var rätt.
Få rader är bra, helt klart, ju färre rader destu bättre. Färre rader ger färre möjligheter att införa buggar. Men återigen det handlar inte om ANTALET rader utan vad dessa rader gör.
Om du har en metod som består av 50 rader och du inte har någon redundant kod där i, och alla kod hör logiskt ihop. Tänker du då dela upp denna metod i 5 olika metoder bara för att du skall få 10 rader i varje och därefter skapa en annan metod som anropar på dessa 5 metoder. Skulle inte tro det!
Det är just det som inte stämmer. Du kommer typ aldrig kunna ha 50 rader kod och inte ha redundans. Just 10 rader är mer en statistik siffra som är en målriktning för att just minimera risken med redundans. Den är inte påhittat.
Jag ville med mitt exempel visa just redundansen som jag extrahera ut.
Ex DisplayName refactorera jag till user för att det kommer bergis finnas flera tillfällen som man vill ha ut Displayname och då vill man inte skriva den koden igen som du hade i if-satsen. Detta skrev jag inte för att klandra din kod utan för att faktiskt förtydliga och visa att få rader kod handlar inte bara om att ha små metoder för någon säger att det är snygg kod. Utan för att även bevisa att jag nu minimerade risken för redundant kod. Om du har en annan klass som sen skall använda user så skall man slippa skriva koden igen för att sätta ihop för o efternamn. Redundans kod handlar alltdå inte om att i sin metod ha redundans utan att man även då riskerar redundans på andra områden.
Jag är villig att diskutera det vidare med dig om du håller dig till sakfrågan och inte kommer med tramsiga kommentarer om tydliga buggar och sånt...
Sorry. Tyckte du kom med barnsligt svar ang lägga all kod på en rad så kunde inte låta blir... Ta det mer ironiskt än pajkasning... För pajkastning var det ej... bara ett förtydligande varför du har fel med dina påståenden om 200 rader kod.
-- Bhaaa.. ser massa slintningar när jag skrev. ursäkta om ord ser knasiga ut eller stavats fel... orka rinte rätta det just nu ---
Mvh Johan
