Jag är lite fundersam till användningen av "var" men det är fler och fler som börjar använda det. Men de som inte har börjat med det menar att det blir sämre läsbarhet. Jag kan hålla med lite fast ändå inte :) Jag har försökt att argumentera för användning av var men jag tycker mig möta motstånd.
Ett motargument mot att det blir sämre läsbarhet är att man väldigt ofta kallar sin variabel för detsamma som klassnamnet och därför påverkas inte läsbarheten något. Exempel:
Old way
Customer customer = new Customer();
Var way
var customer = new Customer();
Ett annat motargument är att om man har flera variabler deklarerade efter varandra så blir det en "fin" linje mellan de nya variablerna. Exempel:
Old way
Customer customer = new Customer();
Order order = new Order();
Product product = new Product();
Var way
var customer = new Customer();
var order = new Order();
var product = new Product();
Jag kan också tänka mig att användningen av var kan hjälpa en med refaktorering fast jag ser en liten risk och det är att gamla variabelnamn har namnet som är kopplat till det gamla klassnamnet.
Är ni en var:are eller en icke-var:are och varför i så fall?
Jag skulle djärvt vilja påstå att sättet du använde var (d.v.s vid deklaration av nya objekt) är inte det tilltänkta sättet att använda det.
Det förbättrar läsbarheten (och till viss del funktionalitet) vid deklarationer som;
Customer customer = new Customer(12);
var orders = customer.Orders;
Nu spelar det ingen roll om customer.Orders returnerar en ObservableCollection, IEnumerable, IList, List, o.s.v. Nu kan man ändra implementationen av Customer.Orders utan att bryta användning av densamma, samtidigt som man slipper s.k. code noise.
En del .NET-utvecklare litar för mycket på ReSharper tycker jag. Kom ihåg att det bara är ett verktyg - t.o.m. ett verktyg som inte följer Microsoft Coding Guidelines. ;)
Nej, jag ville bara vara lite tydligare i mitt exempel - att använda 'var' framför en new-tilldelning är väl helt OK. Jag menade bara att 'var' gör större nytta framför proppar eller metoder, än vad det gör framför deklarationer av nya objekt.
"Code noise" skulle kunna vara;
[b]ObjectForSerialization[/b] obj = new ObjectForSerialization();
[b]HashMap<String, ObjectForSerialization>[/b] map = new HashMap<String, ObjectForSerialization>();
...
I ovanstående kod är dom fetmarkerade avsnitten vad jag skulle kalla code noise, då typdeklarationen redan finns till höger om tilldelningsoperatorn. Således är dom fetmarkerade avsnitten egentligen helt onödiga, och att använda 'var' istället får vår kod mycket snyggare;
var obj = new ObjectForSerialization();
var map = new HashMap<String, ObjectForSerialization>();
Nu kanske exempelkoden inte var överdrivet nedskräpad, det finns mycket värre exempel. :)
Jag tycker att man ska hålla sig borta från var så länge man inte vet varför man ska använda det.
[förtydligande]
Vad jag menar är att om jag inte verkligen kan motivera användandet av var i en specifik situation, så bör jag istället använda en korrekt datatyp
[/förtydligande]
-> Nickemannen
Det som är kasst med var i refaktoreringssyfte är att variabelnamnet inte ändras till tex den nya klassinstansen. Detta gör att det blir mer svårläst kod eftersom gammalt skräp ligger kvar i koden. Tex
Nu är inte jag någon .NET-kodare men jag kan ana vad var är till för och ställer då istället frågan: Vad vinner du på att använda var i det fallet?
Fingrar, tid och tangentbordslivslängd är tre saker som kommer upp i huvudet. Explicit typning av variablerna när man newar objekt innebär att man säger samma sak två gånger. Det är rimligt att ange typen en gång - kompilatorn måste ju veta vad den ska instansiera - men två gånger, hur kan man motivera den redundansen?
Det enda egentliga argumentet jag kan se emot implicit typning är följande kodsnutt:
IList<T> list = new List<T>();
[I]// versus[/I]
var list = new List<T>(); // Ekvivalent med List<T> list = new List<T>();
... eftersom man här kan lockas att coupla sin kod mot den arraybaserade List-klassen (typ genom att använda iterera över den med indexering istället för en iterator) så att man inte kan byta en annan IList-implementation som LinkedList. För egen del kan jag inte påstå att det ställt till problem eftersom det bara är lokala variabler i metoder som kan typas implicit, så koden blir hårt kopplad ändå eftersom man antingen själv newar objekt av den specifika implementationsklassen, eller använder en metod som har implementationstypen i sin signatur (och i det senare fallet är det metoden det är fel på, inte den implicita typningen).
Och så kommer vi ihåg: Implicit typning är inte vare sig svag eller dynamisk. Det finns till och med statiska explicit typade språk som har svag typning (C, exempelvis). Den enda skillnaden mellan ett implicit och ett explicit typat program är att det implicit typade programmet inte säger en massa saker om sig självt som kompilatorn redan vet.
-> Nickemannen
Det som är kasst med var i refaktoreringssyfte är att variabelnamnet inte ändras till tex den nya klassinstansen. Detta gör att det blir mer svårläst kod eftersom gammalt skräp ligger kvar i koden. Tex
var person = GetCustomerByID(1);
Vad har det med implicit/explicit typning att göra? Har man kod som Person person = GetPersonById(1); och sen gör en rename på Person till Customer, och döper om GetPersonById till GetCustomerById kommer inga variabler att byta namn. Visst, deklarationen kommer säga att det är en Customer, men variabeln kommer fortfarande ha ett felaktigt namn.
Vad har det med implicit/explicit typning att göra? Har man kod som Person person = GetPersonById(1); och sen gör en rename på Person till Customer, och döper om GetPersonById till GetCustomerById kommer inga variabler att byta namn. Visst, deklarationen kommer säga att det är en Customer, men variabeln kommer fortfarande ha ett felaktigt namn.
GetCustomerById kanske retunerar en ICustomer istället för Customer, just domänobjekt i detta fallet kanske inte ändras så ofta men det finns andra saker. Men fortfarande, jag ser ingen anledning till varför man inte skulle kunna använda var. Jag säger inte att man ska använda var utan att det är en smaksak med en liten fördel i dessa fallen, sedan har den en svag nackdel att man kanske kan påstå att läsbarheten av koden blir lite sämre om man inte döper sina metoder och variabler rätt, men så som på alla sätt så kan man missbruka "frihet".
-> Nickemannen
Det som är kasst med var i refaktoreringssyfte är att variabelnamnet inte ändras till tex den nya klassinstansen. Detta gör att det blir mer svårläst kod eftersom gammalt skräp ligger kvar i koden. Tex
