Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

[C#][discussie] Lekker veel var gebruiken?

Pagina: 1 2 Laatste
Acties:

Onderwerpen


  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

Ankona schreef op dinsdag 15 september 2020 @ 23:28:
Weet iemand de echte reden waarom Microsoft en zeker Resharper zulke fans zijn van var?
Wanneer is het echt belangrijk om te weten wat het type is van een variabele? Het idee is dat een variabelenaam al beschrijvend genoeg moet zijn.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
De variabele naam is vooral beschrijvend naar het domein toe, niet naar de implementatie. Ik ben het wel met je eens dat goede code makkelijker leest, zeker ook als namen goed gekozen zijn.
Maar wanneer lees je nou je code? Vooral als je bugs aan het oplossen bent, dan is het erg plezierig om een goed beeld van de implementatie te hebben om te begrijpen waarom het ander gedrag vertoont dan je verwacht.
En tijdens het schrijven zelf vind ik het ook wel handig. Ik werk nu in een team waar men afgesproken heeft dat alles var MOET zijn. Ik ontwikkel dat alles expliciet en vlak voor de code review refactor ik de boel pas naar var.

alles kan off-topic


  • Cyphax
  • Registratie: november 2000
  • Laatst online: 22:09

Cyphax

Moderator NOS
Ankona schreef op woensdag 16 september 2020 @ 07:26:
De variabele naam is vooral beschrijvend naar het domein toe, niet naar de implementatie.
Als je bekend bent met dat domein, dan weet je toch alsnog wat iets, is als de naamgeving maar beschrijvend is?
Ik moest in het begin ook niets hebben van dat 'var' overal, maar over de jaren heen is het ingeburgerd en is het wel prettig. Het maakt in mijn ervaringen vaak niet zo heel veel uit wat iets precies is. Het is misschien lastig te pinpointen maar ik kan me niet herinneren dat ik in de afgelopen jaren eens heb gedacht "damnit stond hier maar niet 'var'". :)

Saved by the buoyancy of citrus


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
Cyphax schreef op woensdag 16 september 2020 @ 07:39:
[...]

Als je bekend bent met dat domein, dan weet je toch alsnog wat iets, is als de naamgeving maar beschrijvend is?
Tenzij daar juist de fout zit. Bijvoorbeeld omdat een int gebruikt is waar het een double had moeten zijn. Of nog een decimal waar je jaren geleden had besloten bedragen (oid) uit te drukken in een eigen value type.

Verder heb je soms (ik werk nu aan een grote technische applicatie) te maken met zeer complexe model structuren. Dan ben je ook al snel het overzicht kwijt tenzij je in de naamgeving precies vast gaat leggen wat je eigenlijk aan de declaratie al had moeten kunnen zien.

Kortom, zat situaties waar het niet echt nodig hoeft te zijn, maar in mijn ogen geen situaties waarin het een voordeel biedt om var te gebruiken. En nog genoeg situaties waarin expliciete declaraties toch wel plezieriger zijn. (naar mijn mening dan)

alles kan off-topic


  • Cyphax
  • Registratie: november 2000
  • Laatst online: 22:09

Cyphax

Moderator NOS
Ankona schreef op woensdag 16 september 2020 @ 07:47:
[...]

Tenzij daar juist de fout zit. Bijvoorbeeld omdat een int gebruikt is waar het een double had moeten zijn. Of nog een decimal waar je jaren geleden had besloten bedragen (oid) uit te drukken in een eigen value type.
Over het algemeen komen die waarden uit functies met een return type. Imho de verkeerde plek om je daar zorgen over te maken. Hangt mogelijk ook af van het type applicatie waar je in zit, hoewel ik zo niet iets kan bedenken. :)
Verder heb je soms (ik werk nu aan een grote technische applicatie) te maken met zeer complexe model structuren. Dan ben je ook al snel het overzicht kwijt tenzij je in de naamgeving precies vast gaat leggen wat je eigenlijk aan de declaratie al had moeten kunnen zien.
Ja, nou, ik doe al jaren hetzelfde en ik ben nooit het overzicht kwijt. Daarom zal het wel persoonlijke voorkeur zijn met name. Maar het is imho vooral fout om iets wat niet jouw voorkeur heeft fout te noemen. Dan doe je anderen tekort vind ik.
Kortom, zat situaties waar het niet echt nodig hoeft te zijn, maar in mijn ogen geen situaties waarin het een voordeel biedt om var te gebruiken. En nog genoeg situaties waarin expliciete declaraties toch wel plezieriger zijn. (naar mijn mening dan)
Dat geeft ook niet, het is ook niet erg, het is vooral goed om er enigszins bij stil te staan uiteindelijk, dan heb je altijd een weloverwogen keuze en over smaak en voorkeur valt ook niet te twisten. :)

[Voor 3% gewijzigd door Cyphax op 16-09-2020 07:54]

Saved by the buoyancy of citrus


  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

Ankona schreef op woensdag 16 september 2020 @ 07:26:
Maar wanneer lees je nou je code? Vooral als je bugs aan het oplossen bent, dan is het erg plezierig om een goed beeld van de implementatie te hebben om te begrijpen waarom het ander gedrag vertoont dan je verwacht.
Maar voldoen de types die in de type-signature van je functie staan dan niet?
Ankona schreef op woensdag 16 september 2020 @ 07:47:
[...]

Tenzij daar juist de fout zit. Bijvoorbeeld omdat een int gebruikt is waar het een double had moeten zijn.
Dat lijkt me een slecht voorbeeld. Een compiler zal een type-error geven omdat een double niet impliciet om te zetten is naar een int.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Black Eagle
  • Registratie: december 2002
  • Niet online
Ikzelf gebruik var voor alle complex types. Mensen die geen var willen gebruiken zie ik echt als die oude developers die te stug zijn om zich aan te passen. Elke editor laat het type zien met een mousehover en als je duidelijke namen kiest is al duidelijk wat voor type het is.

  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

Laten we anders wat voorbeelden plaatsen. Hier is een stukje code dat var gebruikt:
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
// Read TIFF
using var tif = Tiff.Open(sourceImagePath, "r");
var w = tif.GetField(TiffTag.IMAGEWIDTH)[0].ToInt();
var h = tif.GetField(TiffTag.IMAGELENGTH)[0].ToInt();
var buf = new int[w * h];
tif.ReadRGBAImageOriented(w, h, buf, Orientation.TOPLEFT);

// Convert to BGR:
using var mat = new Mat<Vec4b>(h, w, buf);
using var matBGR = new Mat<Vec3b>();
Cv2.CvtColor(mat, matBGR, ColorConversionCodes.RGBA2BGR);

WriteResult(outputPath, matBGR, someOtherArgumentsThatDontMatterRightNow);

Wordt dit stukje code leesbaarder als we de types van tif, w, h, buf, mat en matBGR uitschrijven?

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
RayNbow schreef op woensdag 16 september 2020 @ 07:54:
[...]

Maar voldoen de types die in de type-signature van je functie staan dan niet?
[...]
[...]

Dat lijkt me een slecht voorbeeld. Een compiler zal een type-error geven omdat een double niet impliciet om te zetten is naar een int.
Dat is nou net de grap, een var past zich automagisch aan waardoor de compiler het vaak wel ok vindt. Bij expliciete declaratie zou je wel gealarmeerd worden door de compiler.

alles kan off-topic


  • jessy100
  • Registratie: november 2010
  • Laatst online: 20:29
MBV schreef op dinsdag 9 februari 2010 @ 14:47:
offtopic:
viel mij ook al op ja. Heeft in deze context toch geen enkel nut, en kan toch ook voor een lagere performance zorgen? Los daarvan haal je alle voordelen van een strongly typed language weg, ga dan lekker ironPython gebruiken als je in .NET wilt spelen :X
Ik stoor me echt ernorm aan deze reactie in de OP. Lagere performance? hoe kom je er bij? Tijdens het omzetten naar IL code wordt var gewoon omgezet naar zijn expliciete type.. Voordelen van een strongly typed language bijven ook gewoon bestaan..

Iets met klok en klepel.

Overigens vind ik @pedorus zijn gebruik van var precies zoals het hoort. In mijn team zijn anti-var mensen vooral de wat ouderen die opgegroeid zijn zonder..

  • Cyphax
  • Registratie: november 2000
  • Laatst online: 22:09

Cyphax

Moderator NOS
Ankona schreef op woensdag 16 september 2020 @ 08:31:
[...]

Dat is nou net de grap, een var past zich automagisch aan waardoor de compiler het vaak wel ok vindt.
Het is in de praktijk vaker wel dan niet okee. Ik geef veel interfaces door, als parameter bijvoorbeeld. Wat de instantie dan uiteindelijk wordt maakt me eigenlijk niet uit. Ik wil een collectie, dus ik vraag om een IEnumerable (mits ik me daartoe beperk, gewoon een foreach loopje bijvoorbeeld) als parameter of return type van een functie. Of er dan een List uitkomt of iets anders dat IEnumerable maar implementeert vind ik dat goed genoeg.
Natuurlijk is dat niet van toepassing bij strings en integers, maar ik besteed daar in de praktijk toch minder tijd aan blijkbaar. Anders zou ik er persoonlijk steeds tegenaan gelopen zijn. En een goede naamgeving is daarin voor mij meestal genoeg om niet in de war te raken.

[Voor 4% gewijzigd door Cyphax op 16-09-2020 08:41]

Saved by the buoyancy of citrus


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:20

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

Ankona schreef op woensdag 16 september 2020 @ 07:26:
Maar wanneer lees je nou je code?
Uh, vaker dan je 't schrijft. Een regel code kun je maar één keer schrijven. Aangenomen dat je 'm dan ook meteen leest is 't 1:1 en vanaf dat punt wordt 't lezen alleen maar vaker en 't schrijven blijft 1.
Code is read much more often than it is written, so plan accordingly.
Ik sta ook firm in "kamp var" (itt tot past self :+ ).

C#:
1
2
3
4
5
6
7
8
9
DateTimeOffset date = DateTimeOffset.Now;
ApplicationRepositoryFactory repofact = new ApplicationRepositoryFactory(...);
Customer cust = repo.GetCustomerById(123);

//vs

var date = DateTimeOffset.Now;
var repofact = new ApplicationRepositoryFactory(...);
var cust = repo.GetCustomerById(123);

Zelfs zonder IDE is hier prima uit te komen. Er zijn best wel gevallen waar 't misschien niet altijd 100% duidelijk welk (afgeleid) type je terugkrijgt, maar niets wat een commentje of op die ene plek een expliciete declaratie of cast niet oplost.

C#:
1
var student = (IStudent)schoolRepo.GetPersonById(123);

[Voor 5% gewijzigd door RobIII op 16-09-2020 10:42]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • AtleX
  • Registratie: maart 2003
  • Niet online

AtleX

Tyrannosaurus Lex 🦖

In C#9 kan je met target typed new expressions wel kortere regels schrijven zonder var te vermijden. Bijvoorbeeld:

C#:
1
MemoryStream ms = new();


Ik weet nog niet zo goed wat ik er van vind, ik werk pas een paar weken met C#9 dus moet nog voor mezelf bepalen wanneer ik var fijner vind en wanneer target typed new expressions. Tot nu toe, pre C#9, zit ik nogal in Kamp Var. Het is veel makkelijker met refactoring en ik vind het makkelijker leesbaar ook.

[Voor 4% gewijzigd door AtleX op 16-09-2020 08:54]


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
RobIII schreef op woensdag 16 september 2020 @ 08:43:
[...]

Uh, vaker dan je 't schrijft. Een regel code kun je maar één keer schrijven. Aangenomen dat je 'm dan ook meteen leest is 't 1:1 en vanaf dat punt wordt 't lezen alleen maar vaker en 't schrijven blijft 1.
Klopt, de vraag was ook meer retorisch. Uit onderzoek blijkt dat de developer gemiddeld 5 keer zoveel tijd kwijt is met het lezen van zijn eigen code dan met het schrijven. (Daarom is wat meer tijd steken in het schrijven van code en geen vage afkortingen etc gebruiken ook gewoon tijdwinst. )

Maar wat ik bedoelde met de vraag is vooral het wanneer. Vaak als het nodig is om de implementatie goed te begrijpen om iets op te lossen of aan te passen. Niet zozeer om het globale functionele doel te begrijpen. (Daarvoor zou de methode naam voldoende moeten zijn)

alles kan off-topic


  • Rub3s
  • Registratie: mei 2007
  • Laatst online: 17:12

Rub3s

+3 , omdat het kan

Ankona schreef op dinsdag 15 september 2020 @ 23:28:
Spottend zeg ik vaak dat var ideaal is voor developers die geen idee hebben wat ze aan het doen zijn.
:'(

Je kan de discussie ook andersom voeren: Wat heb jij tegen var?

Zelf vind ik het gewoon minder typewerk. Ik typ al genoeg.

  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

AtleX schreef op woensdag 16 september 2020 @ 08:47:
In C#9 kan je met target typed new expressions wel kortere regels schrijven zonder var te vermijden. Bijvoorbeeld:

C#:
1
MemoryStream ms = new();
Of je nu MemoryStream ms = new(); of var ms = new MemoryStream (); schrijft is om het even. In beide gevallen schrijf je het type maar 1x op. De nieuwe syntax is vooral handig voor fields in een class waarin var niet mogelijk is.
Ankona schreef op woensdag 16 september 2020 @ 08:31:
[...]

Dat is nou net de grap, een var past zich automagisch aan waardoor de compiler het vaak wel ok vindt. Bij expliciete declaratie zou je wel gealarmeerd worden door de compiler.
Kom eens met een concreet voorbeeld?

Kijk, ik snap dat het volgende een type-error is:
C#:
1
int result = someDouble();

En het volgende niet:
C#:
1
var result = someDouble();

Maar de tweede variant zal alsnog een type-error opleveren zodra je result ergens op een plek gebruikt waar een int verwacht wordt.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
RobIII schreef op woensdag 16 september 2020 @ 08:43:

C#:
1
var student = (IStudent)schoolRepo.GetPersonById(123);
Ik moet zeggen dat ik een dergelijke cast alleen om te zorgen dat de var het juiste type krijgt wel lelijk vind, dan gebruik ik op die plek liever een expliciete declaratie.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:20

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

Woy schreef op woensdag 16 september 2020 @ 09:49:
[...]

Ik moet zeggen dat ik een dergelijke cast alleen om te zorgen dat de var het juiste type krijgt wel lelijk vind, dan gebruik ik op die plek liever een expliciete declaratie.
Was een beetje een geforceerd voorbeeld. Eens dat een expliciete declaratie dan mooier is.
RobIII schreef op woensdag 16 september 2020 @ 08:43:
of op die ene plek een expliciete declaratie of cast niet oplost.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • whoami
  • Registratie: december 2000
  • Laatst online: 20:44
AtleX schreef op woensdag 16 september 2020 @ 08:47:
In C#9 kan je met target typed new expressions wel kortere regels schrijven zonder var te vermijden. Bijvoorbeeld:

C#:
1
MemoryStream ms = new();


Ik weet nog niet zo goed wat ik er van vind, ik werk pas een paar weken met C#9 dus moet nog voor mezelf bepalen wanneer ik var fijner vind en wanneer target typed new expressions. Tot nu toe, pre C#9, zit ik nogal in Kamp Var. Het is veel makkelijker met refactoring en ik vind het makkelijker leesbaar ook.
Wat hier gebeurd is eigenlijk het omgekeerde van `var`

code:
1
var ms = new MemoryStream();


vind ik dan beter. :)

[Voor 1% gewijzigd door whoami op 16-09-2020 09:52. Reden: code-tags ipv markdown style code]


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

RayNbow schreef op woensdag 16 september 2020 @ 09:36:
[...]
... zal alsnog een type-error opleveren zodra je result ergens op een plek gebruikt waar een int verwacht wordt.
Tenzij de code erna gaat rekenen. Dan gebruik ik liever wel expliciete types, om te zien of er ergens ineens integer division gaat plaatsvinden.

Ik ben benieuwd of die nieuwe new()-syntax ook genest werkt? Dus:

C#:
1
2
3
4
5
Dictionary<string, Foo<Bar>> dict = new()
{
    { "baz", new(42) }, // instead of new Foo<Bar>(42)
    { "qux", new(21) },
};

As always, we are nailed to a cross of our own construction.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:01
Ik gebruik zelf geen C# maar Kotlin, nu ongeveer 2 jaar full time. Kotlin heeft ook var/val. Ook in de Java wereld speelt deze discussie, met argumenten als dat de code onleesbaar wordt. M.i. is dit een compleet non-issue, integendeel: var/val dwingt je eerder om goede variabele namen te kiezen.

Mensen 'doen' alsof code er meestal zo uitziet:

code:
1
2
List<Person> persons = someService.findByName("Foo");
persons.doSomething();


Maar meestal is het zo iets:

code:
1
2
3
4
5
List<Person> persons = someService.findByName("Foo");

//heel veel regels code

persons.doSomething();


Daar is er een flinke afstand tussen de declaratie van het persons object, en het gebruik ervan. Dus er is echt geen groot verschil, m.i. is dat 'code lezen' een non-argument. Dat is ook mijn ervaring na 2 jaar full time Kotlin; de code wordt er absoluut niet slechter leesbaar door. Je hebt juist minder visuele overhead en je wordt meer gedwongen goeie namen te gebruiken.

https://niels.nu


  • Cyphax
  • Registratie: november 2000
  • Laatst online: 22:09

Cyphax

Moderator NOS
Hydra schreef op woensdag 16 september 2020 @ 10:03:


Daar is er een flinke afstand tussen de declaratie van het persons object, en het gebruik ervan.
Ik zou dan die afstand verkleinen, maakt je method ws al een stuk leesbaarder los van of je var gebruikt of niet.

Saved by the buoyancy of citrus


  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

whoami schreef op woensdag 16 september 2020 @ 09:52:
[...]


Wat hier gebeurd is eigenlijk het omgekeerde van `var`

code:
1
var ms = new MemoryStream();


vind ik dan beter. :)
Maar dat werkt niet als veld-declaratie, vandaar de nieuwe syntax. :)
CodeCaster schreef op woensdag 16 september 2020 @ 09:59:
[...]

Tenzij de code erna gaat rekenen. Dan gebruik ik liever wel expliciete types, om te zien of er ergens ineens integer division gaat plaatsvinden.
Maar in welke situatie met var zal dit voorkomen? Dit zal alleen gebeuren als het resultaat ergens al een int was en je dus niet hebt omgezet naar een double.
Ik ben benieuwd of die nieuwe new()-syntax ook genest werkt? Dus:

C#:
1
2
3
4
5
Dictionary<string, Foo<Bar>> dict = new()
{
    { "baz", new(42) }, // instead of new Foo<Bar>(42)
    { "qux", new(21) },
};
Blijkbaar? :)
C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
using System;
using System.Collections.Generic;

namespace csharp9test
{
    class Foo<T> {
        public int X { get; set; }
        public Foo(int x) 
        {
            X = x;
        }
    }
    
    class Bar {}
    
    class Program
    {
        static void Main(string[] args)
        {
            Dictionary<string, Foo<Bar>> dict = new()
            {
                { "baz", new(42) }, // instead of new Foo<Bar>(42)
                { "qux", new(21) },
            };

            Console.WriteLine($"Hello World! {dict["baz"].X}");
        }
    }
}

C:\tmp\csharp9test> dotnet run
Hello World! 42


Edit: Dit werkt ook:
C#:
1
2
3
4
5
var dict = new Dictionary<string, Foo<Bar>>()
{
    { "baz", new(42) }, // instead of new Foo<Bar>(42)
    { "qux", new(21) },
};

[Voor 5% gewijzigd door RayNbow op 16-09-2020 10:21]

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:14
Rub3s schreef op woensdag 16 september 2020 @ 09:27:
[...]

:'(

Je kan de discussie ook andersom voeren: Wat heb jij tegen var?

Zelf vind ik het gewoon minder typewerk. Ik typ al genoeg.
Minder typewerk is niet echt een argument om var te gebruiken, want dat is een kwestie van een betere IDE gebruiken :+ Ik typ zelf altijd de definitie, en laat de IDE met een toetsencombinatie de declaratie genereren. Dat scheelt een hoop typen, omdat de naam van de variabele 9 van de 10 keer goed is (wordt afgeleid van de methode naam en/of return value).

  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
RayNbow schreef op woensdag 16 september 2020 @ 09:36:

[...]

Kom eens met een concreet voorbeeld?
Het eerste waar ik dan meteen aan denk is het gedrag van operators op numerieke types. Met name delen is bij integers anders dan bij floating point types.

Verder kan het handig zijn bij primitieven om te zien of ze wel of niet nullable zijn. Dit zijn eigenlijk de eerste redelijk normale voorbeelden die me zo te binnen schieten. Meer geforceerde voorbeelden zijn als een return value van een functie verandert maar wel (een aantal) gelijknamige members heeft.

Maar terug op het meer algemene. Natuurlijk, ik heb mijn voorkeuren en het is goed om zelf ook regelmatig in de spiegel te kijken. Zeker als je merkt dat je tegen een stroom in zwemt. (toen var geïntroduceerd werd dook ik er ook als een jonge hond op om het te pas en te onpas te gebruiken, later ben ik steeds meer overtuigd geraakt dat het niets toevoegt en juist soms zaken onduidelijker of fout gevoeliger maakt )
Ik ben ervan overtuigd dat je in beide stijlen goede code kunt schrijven. Technisch maakt het helemaal niets uti voor de compiler (in IL wordt het hetzelfde dus verwacht geen performance argumenten)

Ik mis eigenlijk vooral de echte steekhoudende argumenten om informatie over de te gebruiken types af te willen schermen.

Wat betreft de leesbaarheid is het ook een stuk gewenning. Ik vind het plezierig dat een declaratie altijd begint met het type. Dan hoef ik niet te kijken naar waar het vandaan komt als ik alleen in het gedrag en niet in de instance zelf geïnteresseerd ben. Gewoon links in de regel staat dan wat ik wil weten. (maar dit is natuurlijk ook voor een groot deel net wat je gewend bent. Echter, afhankelijk zijn van je tooling om code te kunnen begrijpen vind ik nooit een goed uitgangspunt)

alles kan off-topic


  • AtleX
  • Registratie: maart 2003
  • Niet online

AtleX

Tyrannosaurus Lex 🦖

whoami schreef op woensdag 16 september 2020 @ 09:52:
[...]


Wat hier gebeurd is eigenlijk het omgekeerde van `var`

code:
1
var ms = new MemoryStream();


vind ik dan beter. :)
Ja klopt. En ook eens. Al zijn target typed new expressions wel handig in static readonly fields of properties. Dat kunnen soms lange regels zijn en nu worden met target typed new expressions wat korter.

  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

@Ankona: Met een concreet voorbeeld bedoelde ik een programma (of deel ervan) die het probleem waar je (met var) tegenaan loopt illustreert.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
RayNbow schreef op woensdag 16 september 2020 @ 10:36:
@Ankona: Met een concreet voorbeeld bedoelde ik een programma (of deel ervan) die het probleem waar je (met var) tegenaan loopt illustreert.
Fijn, dat je dat bedoelt maar het issue is zo ook wel duidelijk. Mijn productie code van onder NDA met de klanten dus die kan ik niet delen en anders zou ik een voorbeeld in elkaar moeten knutselen naar het probleem toe. Iets wat niets toevoegt. (En een stuk concrete code doorspitten om in een regel iets te herkennen wat je met een simpele beschrijving ook kunt duiden voegt ook weinig toe)

alles kan off-topic


  • Grijze Vos
  • Registratie: december 2002
  • Laatst online: 18-09 23:10
Ik denk dat het vooral smaak is. Mensen lezen nou eenmaal code anders. Ik heb ook collega's gehad die code moesten herschrijven voordat ze in staat waren de code te begrijpen. (Ok granted, deze collega's werken nu niet meer bij ons.)
Ankona schreef op dinsdag 15 september 2020 @ 23:28:
Spottend zeg ik vaak dat var ideaal is voor developers die geen idee hebben wat ze aan het doen zijn.
HIer zou ik dan weer terug op willen reageren door te zeggen dat als het wel of niet aanwezig zijn van var de leesbaarheid dermate beinvloed, dat dan je code gewoon slecht gestructureerd is. Als jij functies hebt van 5-10 regels code met iets van 2-3 variabelen in gebruik, dan maakt het echt geen drol meer uit.

Misschien moet iemand gewoon eens wat tijd investeren in een VS plugin die die var declaraties gewoon live vertaald naar de onderliggende type def. Wellicht zelfs gewoon met een keyboard shortcut om snel te togglen oid.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
Maar dan niet alleen in Visual Studio, ook je code review tooling moeten dat dan gaan ondersteunen. Ik wil voor een code review liever niet de branch ook nog lokaal in VS openen. Ik wil de code gewoon zelf begrijpen.

alles kan off-topic


  • Hydra
  • Registratie: september 2000
  • Laatst online: 17:01
Cyphax schreef op woensdag 16 september 2020 @ 10:11:
Ik zou dan die afstand verkleinen, maakt je method ws al een stuk leesbaarder los van of je var gebruikt of niet.
Dat is het punt niet :)

https://niels.nu


  • Sissors
  • Registratie: mei 2005
  • Laatst online: 22:58
Nu ben ik geen professioneel programmeur, en is mijn ervaring vooral in de embedded wereld, maar ik vind code die allemaal gebaseerd is op var of het equivalent in een andere taal veel moeilijker te lezen. En gedeelte zal gewoon gewenning zijn, maar was is nu het probleem wat wordt opgelost? Expliciet types opgeven lijkt mij een stuk minder foutgevoelig. En ik kan prima volgen dat er situaties zijn waar het prima is (eg zoals deze: Rickets in "[C#][discussie] Lekker veel var gebruiken?").

Maar gemiddeld genomen lijkt het me gewoon minder foutgevoelig als je expliciet types opgeeft, en errors/warnings krijgt als die niet kloppen. En ik vind het ook wel handig om direct te zien of een type signed of unsigned is, int8, 16, 32 of 64 is, of een float is. Al vermoed ik dat het dus ook ervan afhangt wat je doet, als je allemaal code hebt zoals het voorbeeld die in mijn link hierboven zit, dan snap ik dat var lekker werkt. Als je primair native data types gebruikt, dan vind ik het onhandig.

  • supersnathan94
  • Registratie: juli 2010
  • Laatst online: 17:26
Ik vind deze discussie wel grappig aangezien hij nu al meer dan tien jaar loopt en ik kom toch een aantal voorbeelden tegen waarvan ik denk: huh?

En dan heb ik het over dingen als:

code:
1
2
3
4
5
6
7
var ms = new MemoryStream();
var mat = new Mat<Vec4b>(h, w, buf);
var matBGR = new Mat<Vec3b>();
using var tif = Tiff.Open(sourceImagePath, "r");

List<String> bad = new ArrayList<String>();
var good = new ArrayList<String>();


In al deze gevallen heb ik heel veel moeite met het gebruik van var. Uit niets wordt namelijk duidelijk wat var is, niet uit de namen en niet uit de initialisaties. Wat iemand anders terecht al aanhaalde is het java voorbeeld echt kompleet niet hoe je het zou doen in de praktijk.
Daarnaast is de naamgeving dusdanig onduidelijk dat var het laatste concern is.


code:
1
2
3
4
5
6
var ms = new MemoryStream(); // En wat gaan we doen met die MemoryStream(); 
var mat = new Mat<Vec4b>(h, w, buf); // mega specifiek in init, maar superambigu in decl. Why?

List<String> bad = new ArrayList<String>(); // YES indeed should've been: List<String> bad = new ArrayList<>(); 

var good = new ArrayList<String>(); // What type is it going to use now? I can tell you that it is not the one you needed.


Var is leuk voor in loopconstructs, maar gebruik het alsjeblieft niet met het excuus dat het beter leest. Integendeel het maakt het voor nieuwe collega's veeeeeel moeilijker om te zien wat er gebeurt. Gebruik het op plekken waar uit context heel snel afgeleid kan worden wat het onderliggende type is (foreach var item in shoppingList bijvoorbeeld)

Voor de rest gewoon lekker strongly typed. Var is luiheid die je uiteindelijk van achteren bijt in extra tijd die je nodig hebt dingen uit te leggen of te herschrijven. Zoals in het voorbeeld van de ArrayList werkt het ook totaal niet goed met interfaces. Var gooit echt een aantal basis principes door de war en dat moet je dus voorzichtig benaderen.

  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

Ankona schreef op woensdag 16 september 2020 @ 10:47:
[...]

Fijn, dat je dat bedoelt maar het issue is zo ook wel duidelijk. [...] anders zou ik een voorbeeld in elkaar moeten knutselen naar het probleem toe. Iets wat niets toevoegt. (En een stuk concrete code doorspitten om in een regel iets te herkennen wat je met een simpele beschrijving ook kunt duiden voegt ook weinig toe)
Nou, nee, een concreet voorbeeld zou juist helpen.

Eerder zei je dit:
Het eerste waar ik dan meteen aan denk is het gedrag van operators op numerieke types. Met name delen is bij integers anders dan bij floating point types.
Maar ik zie geen voorbeeld waarbij een expliciet uitgeschreven type je hier gaat helpen?
C#:
1
var result = f() / g();

versus

C#:
1
double result = f() / g();

Mochten de returntypes van f en g beide int zijn, dan is het weliswaar zo dat in het eerste stuk code result van het type int is (en niet double), maar in beide voorbeelden heeft er een integerdeling plaatsgevonden.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • supersnathan94
  • Registratie: juli 2010
  • Laatst online: 17:26
hoe is dit ooit code die je serieus gaat opleveren?

code:
1
var result = f() / g();


var is hier niet het probleem. Wat doet f, wat doet g en wat gaan we doen met result?

Wat voor type result heeft is uiteindelijk ook wel van belang, maar eerst die andere dingen eens fiksen.

  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

supersnathan94 schreef op woensdag 16 september 2020 @ 11:07:
Ik vind deze discussie wel grappig aangezien hij nu al meer dan tien jaar loopt en ik kom toch een aantal voorbeelden tegen waarvan ik denk: huh?

En dan heb ik het over dingen als:

code:
1
2
3
4
5
6
7
var ms = new MemoryStream();
var mat = new Mat<Vec4b>(h, w, buf);
var matBGR = new Mat<Vec3b>();
using var tif = Tiff.Open(sourceImagePath, "r");

List<String> bad = new ArrayList<String>();
var good = new ArrayList<String>();


In al deze gevallen heb ik heel veel moeite met het gebruik van var. Uit niets wordt namelijk duidelijk wat var is, niet uit de namen en niet uit de initialisaties.
In het geval van bijv. mat zie je toch aan de RHS dat het een Mat<Vec4b> is? Waarom zou ik dat ook aan de LHS moeten herhalen?
code:
1
var mat = new Mat<Vec4b>(h, w, buf); // mega specifiek in init, maar superambigu in decl. Why?
Hoezo ambigu? Het type van mat is Mat<Vec4b>.
Voor de rest gewoon lekker strongly typed.
var *is strongly-typed*.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • RayNbow
  • Registratie: maart 2003
  • Laatst online: 18:18

RayNbow

Kirika <3

supersnathan94 schreef op woensdag 16 september 2020 @ 11:18:
hoe is dit ooit code die je serieus gaat opleveren?

code:
1
var result = f() / g();
Als je de rest van de draad gelezen had, dan had je kunnen uitvogelen dat ik om een codevoorbeeld vroeg waarin het gebruik van var resulteerde in ongewenst gedrag. Zonder dat er voorbeelden worden gegeven moet ik maar gissen met kunstmatige, abstracte voorbeelden.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

supersnathan94 schreef op woensdag 16 september 2020 @ 11:07:
Integendeel het maakt het voor nieuwe collega's veeeeeel moeilijker om te zien wat er gebeurt. Gebruik het op plekken waar uit context heel snel afgeleid kan worden wat het onderliggende type is (foreach var item in shoppingList bijvoorbeeld)
Ik hoor dat argument vaak, maar heb het in al die jaren nooit relevant gevonden.

Waarom zou zo'n nieuwe developer beter z'n werk kunnen doen als er staat foreach (ShoppingListItem item in shoppingList)? Domein, context en daaropvolgende code duiden al aan wat het type inhoudt en wat je ermee kunt doen.

Voor de rest is er IntelliSense (of hoe het in je favoriete IDE ook heet): houd de muispijl op var, en de IDE toont je het type.
RayNbow schreef op woensdag 16 september 2020 @ 10:15:
Maar in welke situatie met var zal dit voorkomen? Dit zal alleen gebeuren als het resultaat ergens al een int was en je dus niet hebt omgezet naar een double.
In dit geval:

C#:
1
2
3
4
float f = f();
float g = g();

float h = f / g;

Als f() en g() een int retourneren, wordt er zonder expliciete declaratie (var) integer division toegepast. Het compileert dus vrolijk en levert onverwachte resultaten op, met een expliciete declaratie wordt dat stilletjes geconverteerd omdat een int altijd in een float past.

[Voor 40% gewijzigd door CodeCaster op 16-09-2020 11:27]

As always, we are nailed to a cross of our own construction.


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:20

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

supersnathan94 schreef op woensdag 16 september 2020 @ 11:07:
In al deze gevallen heb ik heel veel moeite met het gebruik van var. Uit niets wordt namelijk duidelijk wat var is,
Ik haal uit je betoog veel meer dat je moeite hebt met de variabelenaam ("ms" bijvoorbeeld) dan dat je moeite hebt met var. En dat is terecht, maar daar ging 't voorbeeld niet over (en dus is er, voor 't voorbeeld, waarschijnlijk weinig aandacht besteed aan zinvolle namen omdat 't daar niet over ging).

C#:
1
2
var memstream = new MemoryStream();
MemoryStream memstream = new MemoryStream();


Geef mij die eerste maar hoor.

C#:
1
2
var custlookup = new Dictionary<long, CustomerI>();
Dictionary<long, CustomerI> custlookup = new Dictionary<long, CustomerI>();


Again: doe mij die eerste maar.
supersnathan94 schreef op woensdag 16 september 2020 @ 11:07:
Var is luiheid die je uiteindelijk van achteren bijt in extra tijd die je nodig hebt dingen uit te leggen of te herschrijven.
Noem eens een voorbeeld wanneer 't van achteren bijt :?
supersnathan94 schreef op woensdag 16 september 2020 @ 11:07:
Var gooit echt een aantal basis principes door de war en dat moet je dus voorzichtig benaderen.
Helemaal niet :? Var is gewoon een shorthand:
C#:
1
var cust = new Customer();
Is gewoon:
C#:
1
Customer cust = new Customer();
Voor de compiler. Het compiled beide naar exact dezelfde IL. Eigenlijk schrijf je gewoon:
C#:
1
hee_compiler_zoek_effe_het_type_uit_dat_kun_je_prima cust = new Customer();

[Voor 40% gewijzigd door RobIII op 16-09-2020 11:31]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
RobIII schreef op woensdag 16 september 2020 @ 11:27:

C#:
1
2
var memstream = new MemoryStream();
MemoryStream memstream = new MemoryStream();


Geef mij die eerste maar hoor.

C#:
1
2
var custlookup = new Dictionary<long, CustomerI>();
Dictionary<long, CustomerI> custlookup = new Dictionary<long, CustomerI>();


Again: doe mij die eerste maar.
Dit zijn precies voorbeeld zoals Microsoft het gebruik van var ook adviseert. Is dan ook puur cosmetisch waar je voorkeur ligt. Ik kan ermee leven maar het voegt niets toe en kan inconsistent zijn richting andere declaraties.

C#:
1
var EenOfAnderVaagObject = _serviceXYZ.CreateIets();

Dit is dus een voorbeeld zoals Resharper het zou willen. (Microsoft niet, die schrijven dan expliciete declaratie voor)

alles kan off-topic


  • YakuzA
  • Registratie: maart 2001
  • Laatst online: 00:32

YakuzA

Wat denk je nou zelluf hey :X

RobIII schreef op woensdag 16 september 2020 @ 11:27:
[...]
Ik haal uit je betoog veel meer dat je moeite hebt met de variabelenaam ("ms" bijvoorbeeld) dan dat je moeite hebt met var. En dat is terecht, maar daar ging 't voorbeeld niet over (en dus is er, voor 't voorbeeld, waarschijnlijk weinig aandacht besteed aan zinvolle namen omdat 't daar niet over ging).
C#:
1
2
var custlookup = new Dictionary<long, CustomerI>();
Dictionary<long, CustomerI> custlookup = new Dictionary<long, CustomerI>();


Again: doe mij die eerste maar.
Var is af en toe een geschenk uit de hemel als je een project hebt waar mensen meerdere linebreaks in de declaratie gaan aanbrengen omdat die zo lang wordt idd:

C#:
1
ParameterResponse<EnumServiceResult, ParameterResponse<EnumOperationResult, BlaBlaIngewikkeldeDtoNaam>> result = xxxx

[Voor 23% gewijzigd door YakuzA op 16-09-2020 11:37]

Death smiles upon us all, all a man can do is smile back.
PSN


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:20

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

Ik ben het wel met je eens bij een CreateIets() maar bij een GetCustomerById(123); verwacht ik toch écht een customer en vind ik var prima kunnen. In veruit de meeste gevallen (in ieder geval die ik tegen kom) is dat prima af te leiden / duidelijk en héél soms met een piepkleinbeetje domeinspecifieke kennis te bepalen. Ik kom, zo uit het hoofd althans, zelden gevallen tegen waar je echt een CreateSomething() hebt. En, helemaal eens, daar zou ik dan geen var gebruiken (of een var gebruiken en een cast ofzo).
Exact; en nog een tandje erger:

C#:
1
ParameterResponse<EnumServiceResult, ParameterResponse<EnumOperationResult, BlaBlaIngewikkeldeDtoNaam>> foo = new ParameterResponse<EnumServiceResult, ParameterResponse<EnumOperationResult, BlaBlaIngewikkeldeDtoNaam>>(x, y, z);


Dan ben je IMHO echt wel een masochist als je daar geen var gebruikt.

[Voor 25% gewijzigd door RobIII op 16-09-2020 11:52]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • farlane
  • Registratie: maart 2000
  • Laatst online: 22-09 09:27
Ankona schreef op woensdag 16 september 2020 @ 11:35:
Dit zijn precies voorbeeld zoals Microsoft het gebruik van var ook adviseert. Is dan ook puur cosmetisch waar je voorkeur ligt. Ik kan ermee leven maar het voegt niets toe en kan inconsistent zijn richting andere declaraties.
var gebruiken in deze situaties voegt wat toe in de zin dat het het informatie duplicatie voorkomt, en dan is het wat mij betreft betere code.

In zijn boek houdt de heer Meyers een betoog waarom "auto" (de C++ variant van "var") 'a good thing' is. Ik vond het overtuigend in ieder geval.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • supersnathan94
  • Registratie: juli 2010
  • Laatst online: 17:26
CodeCaster schreef op woensdag 16 september 2020 @ 11:21:
[...]
Waarom zou zo'n nieuwe developer beter z'n werk kunnen doen als er staat foreach (ShoppingListItem item in shoppingList)? Domein, context en daaropvolgende code duiden al aan wat het type inhoudt en wat je ermee kunt doen.
En in precies dat voorbeeld zeg ik ook dat het daar gewoon een prima manier is om te gebruiken. Daar kun je afspraken over maken intern die consistent te houden zijn.
Voor de rest is er IntelliSense (of hoe het in je favoriete IDE ook heet): houd de muispijl op var, en de IDE toont je het type.

[...]

In dit geval:

C#:
1
2
3
4
float f = f();
float g = g();

float h = f / g;

Als f() en g() een int retourneren, wordt er zonder expliciete declaratie (var) integer division toegepast. Het compileert dus vrolijk en levert onverwachte resultaten op, met een expliciete declaratie wordt dat stilletjes geconverteerd omdat een int altijd in een float past.
Dat is dus een van de voorbeelden waarin het gruwelijk fout zal gaan.

  • farlane
  • Registratie: maart 2000
  • Laatst online: 22-09 09:27
supersnathan94 schreef op woensdag 16 september 2020 @ 14:28:
Dat is dus een van de voorbeelden waarin het gruwelijk fout zal gaan.
Waarom gaat het daar fout?

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • supersnathan94
  • Registratie: juli 2010
  • Laatst online: 17:26
RobIII schreef op woensdag 16 september 2020 @ 11:27:
[...]

Ik haal uit je betoog veel meer dat je moeite hebt met de variabelenaam ("ms" bijvoorbeeld) dan dat je moeite hebt met var. En dat is terecht, maar daar ging 't voorbeeld niet over (en dus is er, voor 't voorbeeld, waarschijnlijk weinig aandacht besteed aan zinvolle namen omdat 't daar niet over ging).
En dat is dus precies waarom je dit soort dingen niet zou moeten gebruiken denk ik zelf. het dwingt je namelijk om na te denken over het type wat je wil hebben. ik weet niet in hoeverre C# het gebruik van interfaces heeft geregeld, maar daar ga je dan dus al direct de mist mee in. Het werkt inconsistentie in de hand, want interface types ga je hiermee dus nooit kunnen inferren.
Noem eens een voorbeeld wanneer 't van achteren bijt :?
code:
1
var cust = new MaleCustomer();

Gaat de compiler dan snappen dat je Customer als interface type wil gebruiken? Zo niet dan moet je dat weer expliciet maken en zo krijg je inconsistentie in hoe je variabelen declareert. Als je dit met zijn allen afspreekt (we gebruiken altijd var tenzij we een superType nodig hebben) dan heb ik daar verder geen problemen mee, maar dan moet je dat wel doen.
Eigenlijk schrijf je gewoon:
C#:
1
hee_compiler_zoek_effe_het_type_uit_dat_kun_je_prima cust = new Customer();
En dat kan ie dus niet altijd right?

  • farlane
  • Registratie: maart 2000
  • Laatst online: 22-09 09:27
supersnathan94 schreef op woensdag 16 september 2020 @ 14:37:
[...]
code:
1
var cust = new MaleCustomer();

Gaat de compiler dan snappen dat je Customer als interface type wil gebruiken?
Ja. Als jij die meegeeft aan een functie die een interface verwacht en je type voldoet daar aan dan kan dat.
En dat kan ie dus niet altijd right?
Ja dat kan wel : op plekken waar var gebruikt kan worden kan *altijd* het statische type worden geinferred.

Als je een ander type wilt dan de compiler vindt dat ie is moet je casten, maar net zo goed als in het C voorbeeld is een expliciete cast veel duidelijker dan een impliciete.

[Voor 14% gewijzigd door farlane op 16-09-2020 14:44]

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • supersnathan94
  • Registratie: juli 2010
  • Laatst online: 17:26
Omdat integer division. Als je daar dus niet expliciet een float declareert, je nooit decimalen gaat krijgen van 2 integers. integer division geeft je truncation. 1/2 is dus 0, -5/2 geeft je -2.

dit soort dingen wil je echt expliciet in je code hebben, want als er iets fout gaat (and it will) dan zie je dus niet 1,2,3 waarom.
farlane schreef op woensdag 16 september 2020 @ 14:41:
[...]

Ja. Als jij die meegeeft aan een functie die een interface verwacht en je type voldoet daar aan dan kan dat.


[...]

Ja dat kan wel : op plekken waar var gebruikt kan worden kan *altijd* het statische type worden geinferred.
Oke fair enough

Maar is dit ook slim vanuit onderhoudsperspectief?

again code schrijf je niet omdat je er nooit meer naar hoeft te kijken, als je hier afspraken over kan maken met je team sure go ahead, maar lijkt mij echt niet slim om dergelijke constructen zonder afspraken hierover zomaar in je codebase toe te passen.

Code moet namelijk meestal onderhouden worden door iemand anders dan jij. Zij moeten het dus ook snel kunnen snappen.

  • farlane
  • Registratie: maart 2000
  • Laatst online: 22-09 09:27
supersnathan94 schreef op woensdag 16 september 2020 @ 14:46:
Omdat integer division. Als je daar dus niet expliciet een float declareert, je nooit decimalen gaat krijgen van 2 integers. integer division geeft je truncation. 1/2 is dus 0, -5/2 geeft je -2.
Dat is alleen van belang als van f *en* g het return type wijzigt van float naar int, zodat de compiler plots een int division gaat doen ipv een float.

Als je dat return type wijzigt (van either functie) van float naar int moet je sowieso kijken naar je callers want er is kans op loss of information, aangezien in jouw situatie plots ints aan floats worden toegewezen, terwijl dat met var niet het geval is.

Het is wat mij betreft lood om oud ijzer.
Maar is dit ook slim vanuit onderhoudsperspectief?
Ja, het zorgt zelfs voor minder onderhoud denk ik.

[Voor 7% gewijzigd door farlane op 16-09-2020 14:57]

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
supersnathan94 schreef op woensdag 16 september 2020 @ 14:37:

[...]


code:
1
var cust = new MaleCustomer();

Gaat de compiler dan snappen dat je Customer als interface type wil gebruiken? Zo niet dan moet je dat weer expliciet maken en zo krijg je inconsistentie in hoe je variabelen declareert. Als je dit met zijn allen afspreekt (we gebruiken altijd var tenzij we een superType nodig hebben) dan heb ik daar verder geen problemen mee, maar dan moet je dat wel doen.
In theorie klopt dit, maar dit is niet iets waar je snel mee in de problemen komt. Zelf leg ik ook graag zoveel mogelijk dependencies op interfaces, maar dat speelt vooral bij DI.
Lokale variabelen ken je meestal maar een keer een waarde toe (anders is er misschien iets anders wat aandacht vraagt)

Om jouw code problematisch te maken:
code:
1
2
3
4
5
var cust = new MaleCustomer();

cust.DoeIets();

cust  = new FemaleCustomer(); // auw!


Waar dit gewoon zou werken: (Maar daarmee nog geen goede code is. )
code:
1
2
3
4
5
ICustomer cust = new MaleCustomer();

cust.DoeIets();

cust  = new FemaleCustomer();

alles kan off-topic


  • farlane
  • Registratie: maart 2000
  • Laatst online: 22-09 09:27
Ankona schreef op woensdag 16 september 2020 @ 15:07:
Om jouw code problematisch te maken:
code:
1
2
3
4
5
var cust = new MaleCustomer();

cust.DoeIets();

cust  = new FemaleCustomer(); // auw!
Waarom is dat auw? Wat gebeurt daar volgens jou? Het kan nooit zo zijn dat in het tweede geval een FemaleCustomer voor een MaleCustomer wordt aangezien nl.

Of je code werkt (beide implementeren een base class/interface, maar dan moet je de eerste casten) of je compiler gaat klagen.

[Voor 13% gewijzigd door farlane op 16-09-2020 15:12]

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
farlane schreef op woensdag 16 september 2020 @ 15:10:
[...]

Waarom is dat auw? Wat gebeurt daar volgens jou? Het kan nooit zo zijn dat in het tweede geval een FemaleCustomer voor een MaleCustomer wordt aangezien nl.

Of je code werkt (beide implementeren een base class/interface, maar dan moet je de eerste casten) of je compiler gaat klagen.
Probeer maar, de compiler zal je een error tonen. De variabele heeft namelijk het type MaleCustomer gekregen, niet de interface of supertype.

alles kan off-topic


  • farlane
  • Registratie: maart 2000
  • Laatst online: 22-09 09:27
Ankona schreef op woensdag 16 september 2020 @ 15:16:
[...]

Probeer maar, de compiler zal je een error tonen. De variabele heeft namelijk het type MaleCustomer gekregen, niet de interface of supertype.
Ja dat zeg ik. Dat is toch goed? Je doet iets waar de compiler het niet mee eens is. Op geen enkel moment zorgt "var" er voor dat er iets onverwachts gebeurt.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
farlane schreef op woensdag 16 september 2020 @ 15:19:
[...]


Ja dat zeg ik. Dat is toch goed? Je doet iets waar de compiler het niet mee eens is. Op geen enkel moment zorgt "var" er voor dat er iets onverwachts gebeurt.
Tja, niet werkende code is m.i. toch wel een auw. Dat je om toch var te gebruiken een work-around hebt middels casten maakt het niet mooier.

alles kan off-topic


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:14
Ankona schreef op woensdag 16 september 2020 @ 15:16:
[...]

Probeer maar, de compiler zal je een error tonen. De variabele heeft namelijk het type MaleCustomer gekregen, niet de interface of supertype.
Dat is toch ook niet zo raar, maar gewoon wat je verwacht. new MaleCustomer kun je zien als een functie dat een MaleCustomer returned. Het zou raar zijn als dat ineens een ICustomer wordt. Als je dat wél wilt, moet je dat zelf aangeven. Maar dat heeft weinig met var te maken. Var gebruik je op plekken waar het overbodig is om het type in de declaratie te zetten, wat het in dat geval dus niet is.

  • farlane
  • Registratie: maart 2000
  • Laatst online: 22-09 09:27
Ankona schreef op woensdag 16 september 2020 @ 15:22:
[...]

Tja, niet werkende code is m.i. toch wel een auw. Dat je om toch var te gebruiken een work-around hebt middels casten maakt het niet mooier.
Niet werkende code moet gefixed worden, dat ben ik met je eens. Specifiek casten naar het supertype icm met var is wmb een heel duidelijk verhaal en geeft precies aan wat je wilt, terwijl de impliciete cast in jouw versie subtieler is, en eigenlijk onduidelijker (eye of beholder en zo)

C#:
1
2
3
4
5
6
7
    var cust = new MaleCustomer() as ICustomer;

    cust.DoeIets();

    cust  = new FemaleCustomer() as ICustomer;

    cust.DoeIets();


Of je gebruikt 2 aparte variabelen wat in dit stomme voorbeeld eigenlijk veel beter zou zijn
C#:
1
2
3
4
5
6
7
    var male = new MaleCustomer();

    male.DoeIets();

    var female  = new FemaleCustomer();

    female.DoeIets();

[Voor 28% gewijzigd door farlane op 16-09-2020 15:51]

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


  • KNed
  • Registratie: juni 2006
  • Laatst online: 23:47
Heerlijk, de var discussie :)

Ik was ook tegenstander, maar inmiddels niet zo erg meer. Mits er goede duidelijke namen gebruikt worden.
Ik zie hier nu voorbeelden langs komen die met var gewoon lekkerder lezen.

De laatste posts tussen @farlane en @Ankona laten zien dat het maar net is wat je doel is.
Als je iets met de interface of supertype wil doen dan voldoet var niet.
Mijn stelling zou dan zijn:
-Gebruik je nooit die interface, doe dan lekker overal var.
-Gebruik je het door elkaar doe dan overal specifieke types voor ICustomer/MaleCustomer/FemaleCustomer om het verschil duidelijk te maken.

  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
farlane schreef op woensdag 16 september 2020 @ 15:46:
[...]


Niet werkende code moet gefixed worden, dat ben ik met je eens. Specifiek casten naar het supertype icm met var is wmb een heel duidelijk verhaal en geeft precies aan wat je wilt, terwijl de impliciete cast in jouw versie subtieler is, en eigenlijk onduidelijker (eye of beholder en zo)

C#:
1
2
3
4
5
6
7
    var cust = new MaleCustomer() as ICustomer;

    cust.DoeIets();

    cust  = new FemaleCustomer() as ICustomer;

    cust.DoeIets();


Of je gebruikt 2 aparte variabelen wat in dit stomme voorbeeld eigenlijk veel beter zou zijn
C#:
1
2
3
4
5
6
7
    var male = new MaleCustomer();

    male.DoeIets();

    var female  = new FemaleCustomer();

    female.DoeIets();
Je eerste fix (met as) doet eigenlijk nog iets anders. Die zet een null reference als de cast niet uitgevoerd kan worden.

Zonder twijfel is je tweede fix de enige juiste oplossing, maar daarmee is het voorbeeld ook gelijk weg. Wat ik aan het begin ook al aangaf, een nieuwe toekenning aan een bestaande variabele is zelden een goed idee en duidt vaak op te veel responsibilities. (Wat dan ook weer na de fix nog steeds het geval is maar dan krijg je een hele andere discussie.... ik kan mijn team ook dagen van het werk houden met dit soort zeer interessante en leerzame discussies..... wordt de klant alleen niet altijd even blij als we ons sprintdoel daardoor niet halen)

alles kan off-topic


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:20

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

Ankona schreef op woensdag 16 september 2020 @ 16:01:
[...]

Je eerste fix (met as) doet eigenlijk nog iets anders. Die zet een null reference als de cast niet uitgevoerd kan worden.
Dan doe je (ICustomer)MaleCustomer 8)7

Wat mensen niet (altijd) lijken te snappen is dat var niks anders is dan syntactic sugar; je compiler inferred het type (MaleCustomer) en maakt cust dus ook daadwerkelijk dat type; het "blijft" geen var. Als je er dus verderop een FemaleCustomer in probeert te stoppen gaat 't niet werken. Wél als je cast naar ICustomer (en beide types ICustomer implementeren uiteraard). Either way: Een var "bestaat niet"; je compiler maakt er meteen, daar, op dat moment het juiste (al dan niet expliciet gecaste) type van en vanaf daar is heel het "var" concept verleden tijd voor die variabele.
Ankona schreef op woensdag 16 september 2020 @ 16:01:
een nieuwe toekenning aan een bestaande variabele is zelden een goed idee
Daarom is dat (geforceerde) voorbeeld ook geen goed voorbeeld; het heeft niets te maken met nieuwe toekenningen maar met het voorkomen van:

C#:
1
EenDictionaryVanType<FooDinges, BarDinges> mijnvariabele = new HierMagIkNogEenKeerDatzelfdeStommeTypeHelemaalUitTypenWatIkNetOokAlHebGedaan<FooDinges, BarDinges>();
'

C#:
1
2
3
4
5
CustomerDictionary<CustomerKey, Customer> myCustomers1 = new CustomerDictionary<CustomerKey, Customer>();

//vs

var myCustomers2 = new CustomerDictionary<CustomerKey, Customer>();

Onder de streep zijn myCustomers1 en 2 exact hetzelfde type. De myCustomers variabele "blijft" geen var zodat je er een paar regels later een int aan kunt toewijzen. Daar heb je object voor (en dan heb je hele andere problemen :P ).

[Voor 35% gewijzigd door RobIII op 16-09-2020 16:12]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator Devschuur®
Sowieso moet ik zeggen dat het in mijn code niet vaak voorkomt dat ik een lokale variabele assign, en dan bewust wil dat het gedeclareerde type een van de geimplemeteerde interfaces/superclasses is. Of het is een lokaal object waar het prima een concreet type mag zijn, of het komt al uit een factory method o.i.d. die al netjes als return type een interface heeft.

Daarmee is het ook een beetje een moot point, want in dat geval zal ik inderdaad terug vallen op een expliciete declaratie ( Wat in mijn geval een kleine voorkeur heeft boven het casten van de value )

[Voor 9% gewijzigd door Woy op 16-09-2020 16:43]

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”


  • Haan
  • Registratie: februari 2004
  • Laatst online: 22-09 10:26

Haan

dotnetter

Ik ben zelf ook voorstander van wél zoveel mogelijk var gebruiken. Bij mij in het bedrijf is dat ook de richtlijn. En natuurlijk zijn er gevallen waarin je soms wel het type expliciet wilt gebruiken en natuurlijk zijn er allerlei geforceerde voorbeelden waarin het misschien minder handig is, maar verder heeft var bijna alleen maar voordelen.
Alleen in onderstaande situatie kan var een beetje onhandig uitpakken, maar in principe kom je er dan ook wel weer snel genoeg achter dat je iets vergeten bent.
C#:
1
2
3
4
5
public async Task DoSomething()
{
    var input = await _someService.GetInputAsync(); 
    var foo = _someOtherService.GetFooAsync(input); // result is een Task ipv een Foo object
}

Kater? Eerst water, de rest komt later
Last.fm profiel


  • pedorus
  • Registratie: januari 2008
  • Niet online
offtopic:
Mooi om te zien dat de discussie nog niet is afgesloten :D
Ankona schreef op dinsdag 15 september 2020 @ 23:28:
Weet iemand de echte reden waarom Microsoft en zeker Resharper zulke fans zijn van var? Sommige teams leunen blind op deze aanbevelingen wat discussies erg lastig maakt.
Volgens mij maakt resharper daar geen geheim van:
it improves readability in many scenarios
Maar ze zijn flexibel, dus je kunt het configureren. Ik zit nog steeds in 'kamp var', dat leest het beste, maar een paar keer per jaar moet je toch een IDE opstarten om een type te achterhalen. Dat is een kleine prijs voor het veelal snellere leeswerk.
Ankona schreef op woensdag 16 september 2020 @ 15:07:
code:
1
2
3
4
5
var cust = new MaleCustomer();

cust.DoeIets();

cust  = new FemaleCustomer(); // auw!
In nieuwere talen (Scala, Kotlin, evt Go met const) heb je vaak ook een onderscheid tussen var en val. val (een niet opnieuw te assignen waarde) heeft vaak de voorkeur. In zo'n geval zou ik het als onhandig zien om de variabele te hergebruiken en 2 vals met andere namen gebruiken, maar het is deels een kwestie van smaak. Ik zou het dus zelf juist als voordeel zien dat dit niet kan.

Vitamine D tekorten in Nederland | Corona: wat niet gepost kan worden


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:20

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

Haan schreef op woensdag 16 september 2020 @ 19:31:

Alleen in onderstaande situatie kan var een beetje onhandig uitpakken, maar in principe kom je er dan ook wel weer snel genoeg achter dat je iets vergeten bent.
C#:
1
2
3
4
5
public async Task DoSomething()
{
    var input = await _someService.GetInputAsync(); 
    var foo = _someOtherService.GetFooAsync(input); // result is een Task ipv een Foo object
}
In dat voorbeeld is de assignment naar foo sowieso nutteloos (en zou je een discard kunnen gebruiken) en zeurt VS iig over het niet awaiten van een async method (en over een unused var foo dus). Dus ook hier zie ik niet echt een probleem - of je moet blind zijn voor warnings (waar ik sowieso al jeuk van krijg, maar dat is een andere discussie :P ) of werken in notepad ofzo (als een holbewoner :+ )

Gerelateerd en interessant leesvoer: https://ericlippert.com/2009/01/26/why-no-var-on-fields. Maar voordat je dat leest: onthou dat het in 2009 is geschreven, aan het eind staat een 2020 update.

[Voor 12% gewijzigd door RobIII op 16-09-2020 19:55]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Haan
  • Registratie: februari 2004
  • Laatst online: 22-09 10:26

Haan

dotnetter

RobIII schreef op woensdag 16 september 2020 @ 19:49:

In dat voorbeeld is de assignment naar foo sowieso nutteloos (en zou je een discard kunnen gebruiken) en zeurt VS iig over het niet awaiten van een async method (en over een unused var foo dus). Dus ook hier zie ik niet echt een probleem - of je moet blind zijn voor warnings (waar ik sowieso al jeuk van krijg, maar dat is een andere discussie :P ) of werken in notepad ofzo (als een holbewoner :+ )
Nee VS zeurt hier juist niet, omdat erboven wel een await staat ;)

Overigens, om alle leesbaarheids-argumenten tegen var meteen van tafel te vegen, Resharper kan dit doen voor je :9 : https://tweakers.net/i/Gl-2x6ztnMKfqSDntEB3mqKik1c=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/qNc2zoeRzX5wolZtIyb7vp3y.png?f=user_large

Kater? Eerst water, de rest komt later
Last.fm profiel


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

Haan schreef op donderdag 17 september 2020 @ 08:47:
[...]

Nee VS zeurt hier juist niet, omdat erboven wel een await staat ;)

Overigens, om alle leesbaarheids-argumenten tegen var meteen van tafel te vegen, Resharper kan dit doen voor je :9 : [Afbeelding]
Ja, maar dát is meteen de meest onzinnige feature ooit. Nou ja, misschien op de "inconsistent line endings" warning na. (edit: die is niet per se onzinnig, en van VS ipv R#) maar wel irritant als je je Git niet goed instelt)

De nieuwste Visual Studio heeft die hints ook gejat (ik ga m'n ReSharper ook niet meer verlengen, MS bouwt de nuttigste features toch wel in), ook voor functieparameters. Je code wordt friggin' onleesbaar met al die hints.

[Voor 7% gewijzigd door CodeCaster op 17-09-2020 09:24]

As always, we are nailed to a cross of our own construction.


  • Ankona
  • Registratie: mei 2014
  • Laatst online: 21:41
Ik ben eigenlijk ook totaal geen fan (meer) van Resharper. Visual Studio heeft bijna alle goeds overgenomen en werkt zonder Resharper soepeler en stabieler. (Die drukte in beeld met al die extra hints bevalt mij ook niet)

Enige wat lekker werkt is de ctrl-t zoek functie. Werk in mijn huidige project aan een spaghetti monoliet dus dan heb je dergelijke hulpmiddelen wel nodig.

alles kan off-topic


  • RobIII
  • Registratie: december 2001
  • Laatst online: 00:20

RobIII

Admin Devschuur®

^ Romeinse 3 ja!

Haan schreef op donderdag 17 september 2020 @ 08:47:
[...]

Nee VS zeurt hier juist niet, omdat erboven wel een await staat ;)
Ghe... is me nooit opgevallen :X
Dan nog loop je er vanzelf tegenaan omdat foo dan een Task<T> is i.p.v. een T die je daar verwacht (als je de await dus zou 'vergeten').

[Voor 26% gewijzigd door RobIII op 17-09-2020 09:24]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 20:02
Ankona schreef op woensdag 16 september 2020 @ 15:22:
[...]

Tja, niet werkende code is m.i. toch wel een auw. Dat je om toch var te gebruiken een work-around hebt middels casten maakt het niet mooier.
Ipv een workaround kun je ook gewoon kiezen om niet twee keer aan dezelfde lokale variable te assignen.

code:
1
2
3
4
5
var male = new MaleCustomer();

male.DoeIets();

var female = new FemaleCustomer();


Wordt er nog beter leesbaar op, want je hoeft niet teruguit te scannen om te kijken wat er op dat ene moment ook al weer in die variable zat.

[EDIT]
Zie net dat @farlane dit ook al aanhaalde.
Ben dus niet de enige die ziet dat het gewoon een stom en geconstrueerd voorbeeld is. Daar heeft iemand gewoon een probleem bij een vooringenomen oplossing gezocht.

Dat is eigenlijk onderliggend aan de hele var discussie: van alle problemen 'met var' ligt het overgrote merendeel niet aan het gebruik van var, maar aan iets anders.

Ook het integer division voorbeeld ligt in die categorie. Want als je in bestaande software het return type van een bestaande public of protected method aanpast naar een nauwer type zonder naar usages te kijken, dan ben je eigenlijk per definitie al fout bezig.

[Voor 35% gewijzigd door R4gnax op 22-09-2020 20:02]

Pagina: 1 2 Laatste


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True