[alg] Slechtste programmeervoorbeelden deel 4

[.oisyn]

Verwijderd schreef op maandag 16 augustus 2010 @ 18:59:
[...]

Eigenlijk best duf dat het jump-statement verplicht is zonder dat je fall-through toestaat. Nu moet je dus een redundante break toevoegen.

Ja en nee. Een impliciete fall-through zorgt echter nogal eens voor de nodige bugs bij vergeten breaks, dus het is op zich geen rare keuze om de impliciete fall-through niet te ondersteunen. Echter, door de break in z'n geheel weg te laten zouden mensen het idee kunnen krijgen dat een fall-through weldegelijk mogelijk is, omdat vrijwel alle C-like talen nou eenmaal een impliciete fall-through ondersteunen. Ook zou het wel plaatsen van een break dan ineens invloed hebben op een loop die om de switch heen staat. Wat dat betreft is het dus handiger om de syntax gelijk te houden met datgene waar men bekend mee is. Je krijgt nu nooit onverwachte resultaten, hooguit compile errors in de gevallen waar je een impliciete fall-through voor ogen had.

[ Voor 6% gewijzigd door .oisyn op 17-08-2010 11:03 ]

[Verwijderd]

.oisyn schreef op dinsdag 17 augustus 2010 @ 11:01:
Ja en nee. Een impliciete fall-through zorgt echter nogal eens voor de nodige bugs bij vergeten breaks, dus het is op zich geen rare keuze om de impliciete fall-through niet te ondersteunen.

Oh maar dat vind ik opzich ook geen rare keuze; het is gewoon een keuze.

.oisyn schreef op dinsdag 17 augustus 2010 @ 11:01:
Echter, door de break in z'n geheel weg te laten zouden mensen het idee kunnen krijgen dat een fall-through weldegelijk mogelijk is, omdat vrijwel alle C-like talen nou eenmaal een impliciete fall-through ondersteunen.

Je dat vind ik wel een sterk argument om het jump-statement te verplichten. Ik betwijfel echter of dat nou de achterliggende gedachte was bij het definieren van de taal. Dat hele c sharp geeft bij mij een erg ontworpen-met-haast gevoel.

.oisyn schreef op dinsdag 17 augustus 2010 @ 11:01:
Ook zou het wel plaatsen van een break dan ineens invloed hebben op een loop die om de switch heen staat.

Nou dat hangt van de definitie af. het zou zo maar kunnen zijn dat het jump-statement impliciet een break is. Opzich springen we nu al alle kanten op: break heeft invloed op de switch en continue op een loop er omheen.

[PiepPiep]

Behalve de keuze of een project nederlands of engels is kan het ook belangrijk zijn om af te spreken hoe je variabelen noemt.
Ik kom nu bijvoorbeeld een subjecthidden tegen en een executorvisible.
Mooier zou zijn om het subjectHidden en executorHidden OF subjectVisible en executorVisible.

[kenneth]

Ik heb ze nog mooier meegemaakt:

C#:

subjectNotHidden = true;

[Dido]

kenneth schreef op woensdag 18 augustus 2010 @ 15:00:
Ik heb ze nog mooier meegemaakt:

C#:

subjectNotHidden = true;

code:

if  (*not (#com_self.isNotValid(#foo #bar ) = False) )

Woy schreef op woensdag 18 augustus 2010 @ 15:40:
En dan een leeg if block en alleen de else gevuld

Ben jij dat!

(Ik kom die dingen dus echt dagelijks tegen hier )

[ Voor 31% gewijzigd door Dido op 18-08-2010 16:12 ]

[Woy]

Dido schreef op woensdag 18 augustus 2010 @ 15:38:
[...]

code:

if  (*not (#com_self.isNotValid(#foo #bar ) = False) )

En dan een leeg if block en alleen de else gevuld

[CodeCaster]

Een van m'n vele voorgangers hield niet van korte code.

Delphi:

if (resultSet.fieldByName('eenwaarde').AsString = 'Y') then
        begin
          label453.Visible := true;
          dbedit1005.Visible := true;
        end
        else
        begin
          label453.Visible := false;
          dbedit1005.Visible := false;
        end;

Ik wel:

Delphi:

toonVelden := (resultSet.fieldByName('eenwaarde').AsString = 'Y');
label453.Visible := toonVelden;
dbedit1005.Visible := toonVelden;

Het voorbeeld is wat obfuscated (je weet nooit wie er meeleest) en verduidelijkt, maar het ging echt om lappen labels en textboxes van tweehonderd regels, die met een beetje handig coden waren te reduceren tot 10-20% van de omvang.

En ja, dat ging om de labels en dbedits 1 tot en met 1234. Happy testing. En dan heb ik het nog niet eens over het stuk code van 50 regels dat wordt gebruikt om een waarde op te halen en te valideren, dat zo'n zestig (!) keer is gekopiëerd met als enige aanpassing de DBEdit waarin het resultaat wordt gezet. Daar heb ik ook maar even een functie voor geschreven...

[ Voor 15% gewijzigd door CodeCaster op 18-08-2010 15:57 ]

[HuHu]

Woy schreef op woensdag 18 augustus 2010 @ 15:40:
[...]

En dan een leeg if block en alleen de else gevuld

Zeurpiet:

code:

if  (*not (*not (#com_self.isNotValid(#foo #bar ) = False) ) )

Zo... dan kun je de if vullen en de else leeg laten .

[HMS]

HuHu schreef op woensdag 18 augustus 2010 @ 16:24:
[...]

Zeurpiet:

code:

if  (*not (*not (#com_self.isNotValid(#foo #bar ) = False) ) )

Zo... dan kun je de if vullen en de else leeg laten .

Dat is wel helemaal in de trant van het topic

[Michali]

kenneth schreef op woensdag 18 augustus 2010 @ 15:00:
Ik heb ze nog mooier meegemaakt:

C#:

subjectNotHidden = true;

Beetje in trant van wat ik laatst op TDWTF zag:

http://thedailywtf.com/Articles/Boolean-Illogic.aspx

Moet zeggen dat ik er best moeite mee had om te achterhalen wat de uitkomst nu was.

[HMS]

Michali schreef op woensdag 18 augustus 2010 @ 19:04:
[...]

Beetje in trant van wat ik laatst op TDWTF zag:

http://thedailywtf.com/Articles/Boolean-Illogic.aspx

Moet zeggen dat ik er best moeite mee had om te achterhalen wat de uitkomst nu was.

Holy shit, je zou er maar mee moeten werken .

Ik denk dat dit bedoelt werdt:

Java:

if( statusIsNotValid ) skipValidation = false;

Btw lol @ TRWTF is Java.

[R4gnax]

Verwijderd schreef op dinsdag 17 augustus 2010 @ 13:53:
Dat hele c sharp geeft bij mij een erg ontworpen-met-haast gevoel.

In vergelijking met wat? Het zit een stuk beter in elkaar dan, pak hem beet, Java. Dat is pas een ontworpen-met-haast taal. In C# is er tenminste goed nagedacht over vrij elementaire zaken als property accessors, multi-cast delegates en generics. Java mist de helft en de andere helft is er in de loop der tijd maar redelijk ad-hoc bij gefabriekt met in het achterhoofd zoveel mogelijk backwards compatible te blijven met legacy Java code.

[Grijze Vos]

Michali schreef op woensdag 18 augustus 2010 @ 19:04:
[...]

Beetje in trant van wat ik laatst op TDWTF zag:

http://thedailywtf.com/Articles/Boolean-Illogic.aspx

Moet zeggen dat ik er best moeite mee had om te achterhalen wat de uitkomst nu was.

TRWTF is dat die gast een vraag stelt die je niet eens kan oplossen aan de hand van het code snippet. Staat namelijk helemaal niet waarop die skipValidation boolean op geinitialiseerd is.

[alex3305]

R4gnax schreef op woensdag 18 augustus 2010 @ 19:39:
[...]


In vergelijking met wat? Het zit een stuk beter in elkaar dan, pak hem beet, Java. Dat is pas een ontworpen-met-haast taal. In C# is er tenminste goed nagedacht over vrij elementaire zaken als property accessors, multi-cast delegates en generics. Java mist de helft en de andere helft is er in de loop der tijd maar redelijk ad-hoc bij gefabriekt met in het achterhoofd zoveel mogelijk backwards compatible te blijven met legacy Java code.

Volledig mee eens. Java heeft bijvoorbeeld geen zaken zoals Properties, iets wat heel wat methodes goed overbodig maakt. Daarnaast is er nooit echt nagedacht over een echte GUI designer. Behalve dan afzonderlijke implementaties, iets wat bij .net/C# wel erg goed voor elkaar is!

Daarnaast moeten heel veel zaken gecast worden, terwijl dat in C# niet altijd hoeft.

C#:

if ((extendedControlX as Control).PropertyOfExtendedControl) { }

[Grijze Vos]

Euhm, wat denk je dat die "as" doet? Juist, casten.

Ben het er overigens mee eens dat C# >>>>> Java, maar dat wordt meer een fanboy debate dan een zinnige discussie ben ik bang.

[ Voor 54% gewijzigd door Grijze Vos op 18-08-2010 20:59 ]

[Daspeed]

The as operator is like a cast operation. However, if the conversion is not possible, as returns null instead of raising an exception.

Mocht je extendedControlX ooit eens iets anders zijn dan een Control, dan krijg je een NullReferenceException. Persoonlijk heb ik dan liever een InvalidCastException, veel duidelijker.

[Sebazzz]

R4gnax schreef op woensdag 18 augustus 2010 @ 19:39:
[...]


In vergelijking met wat? Het zit een stuk beter in elkaar dan, pak hem beet, Java. Dat is pas een ontworpen-met-haast taal.

Ik weet dat niet hoor. Hoe lang zijn ze nu met Java 7 bezig?

[Matis]

Sebazzz schreef op woensdag 18 augustus 2010 @ 21:25:
Ik weet dat niet hoor. Hoe lang zijn ze nu met Java 7 bezig?

Java 7, de berichten op de site dateren al van 15 augustus 2006 Dat is pas 4 jaar geleden

[alex3305]

Grijze Vos schreef op woensdag 18 augustus 2010 @ 20:58:
Euhm, wat denk je dat die "as" doet? Juist, casten.

Ben het er overigens mee eens dat C# >>>>> Java, maar dat wordt meer een fanboy debate dan een zinnige discussie ben ik bang.

Ik dacht eens iets slims op te merken, valt dat ook weer tegen .

[Verwijderd]

Grijze Vos schreef op woensdag 18 augustus 2010 @ 20:58:
Euhm, wat denk je dat die "as" doet? Juist, casten.

Dat is níet helemaal waar Het resultaat is hetzelfde maar as ... is vriendelijker qua code dan casten. Als een cast mislukt krijg je namelijk een Exception als as mislukt krijg je een null-object

Een cast is namelijk een type conversie, waar je bij as een object naar zijn originele type (of een bovenliggend type) converteert.

MSDN voorbeeld

C#:

   class csrefKeywordsOperators
   {
       class Base
       {
           public override string  ToString()
           {
                 return "Base";
           }
       }
       class Derived : Base 
       { }

       class Program
       {
           static void Main()
           {

               Derived d = new Derived();

               Base b = d as Base;
               if (b != null)
               {
                   Console.WriteLine(b.ToString());
               }

           }
       }
   }

Linkje

Als je de uiteindelijke IL code vergelijkt zul je zien dat die weldegelijk anders is bij "as" dan bij een cast.

[ Voor 9% gewijzigd door Verwijderd op 18-08-2010 23:26 ]

[R4gnax]

Verwijderd schreef op woensdag 18 augustus 2010 @ 23:14:
[...]

Dat is níet helemaal waar

Kwestie van terminologie. In C++ heb je dezelfde operaties beschikbaar als static_cast<T> en dynamic_cast<T>. (Gesproken over een taal waar niet over nagedacht is, trouwens...)

[roy-t]

Om alle manieren maar bij elkaar te hebben:

C#:

//obj is mogelijk van type ClassA

//Methode 1:
ClassA a = obj as ClassA;
if(a!= null)
{
    DoStuff(); 
}

//Methode 2:
try
{
     ClassA a = (ClassA)obj;
     DoStuff();
}
catch(..){}

//Method 3
if(obj is ClassA)
{
    ClassA a = (ClassA)obj;
    DoStuff();
}

Maar welke is nu het beste? Ik ga zelf meestal voor methode 3 (is). Methode 2 lijkt me erg onhandig, maar methode1 is net zoveel regels als methode 3. Enige verschil is dat je op null checkt of dat je checkt of iets van type 'is'. De 'is' check is in mijn hoofd dan net wat logischer. Ook zit al je code dan in het if block, wat wel overzichtelijk is.


Methode 1: Als obj van ClassA is wordt deze a. Als a bestaat kan ik verder.
Methode3: Als obj van ClassA is. a word de ClassA versie van obj en nu kan ik verder.

[ Voor 12% gewijzigd door roy-t op 19-08-2010 00:11 ]

[R4gnax]

roy-t schreef op donderdag 19 augustus 2010 @ 00:08:
Maar welke is nu het beste?

Ik denk dat je behoorlijk objectief kunt claimen dat methode 1 het beste is. Immers zul je in veruit de meeste van de gevallen waar je controleert of een object van een bepaald type is, daarna een voor dat type specifieke operatie op of met dat object willen verrichten. Ik zou het verder óók in die paar gevallen waar het strikt niet nodig is alsnog op die manier doen, puur voor consistentie.

[Sebazzz]

De beste methode is de duidelijkste, welke dat is moet je voor jezelf bepalen. Qua cost is de tweede het duurste vanwege de exception.

[Niemand_Anders]

Zelf ga ik meestal voor methode 1. Methode 2 is gewoon evil. Methode 3 vind nogal 'dubbel' overkomen.

Overigens gebruik ik zelf meestal een afgeleide van methode 1:

C#:

ClassA a = obj as ClassA;
if (a == null) return;

a.DoStuff();

Meestal als de conversie niet mogelijk is hoeft er niets te gebeuren.

[Verwijderd]

R4gnax schreef op woensdag 18 augustus 2010 @ 19:39:
In vergelijking met wat?

In vergelijking met geen andere taal, want dat hoeft natuurlijk niet. Er zitten in c sharp nou eenmaal wat haast klusjes. Duffe scoping issues, lambda's zijn er bijna bij gehacked (Func<T, R>, Func<T,T, R> etc), dit switch voorbeeld.

En om het nou te vergelijken met Java, dat is zo'n beetje de traagst evoluerende taal. De minst zinnige vergelijking dus.

[Grijze Vos]

Welke scoping issues bedoel je dan?

Lambdas zijn w.m.b. overigens prima zoals ze zijn in C#, Wat verwacht je anders van een statically typed taal, dat ze lambdas niet typeren?

[RayNbow]

Verwijderd schreef op donderdag 19 augustus 2010 @ 07:52:
...lambda's zijn er bijna bij gehacked (Func<T, R>, Func<T,T, R> etc)...

Ja, lambda's zijn er later bijgekomen, maar dat wilt niet meteen zeggen dat ze er bij zijn gehackt. Je hebt bij het toevoegen met nieuwe features altijd te maken met de bestaande architectuur en dus zijn drastische veranderingen niet altijd wenselijk.

Maar goed, gezien je opmerking had je liever meer curry gezien in C#?

[Woy]

Verwijderd schreef op donderdag 19 augustus 2010 @ 07:52:
[...]
Duffe scoping issues

Geef eens een voorbeeld

lambda's zijn er bijna bij gehacked (Func<T, R>, Func<T,T, R> etc)

Zoals al gezegd, is het logisch dat lambda's typed zijn in een typed language.

dit switch voorbeeld.

Dat jij het niet eens bent met de zeer bewuste keuze, zegt niet dat het een haast klus is.

En om het nou te vergelijken met Java, dat is zo'n beetje de traagst evoluerende taal. De minst zinnige vergelijking dus.

De traagst evoluerende taal moet toch wel C++ zijn met C++ 01x

Maar ik snap je aversie tegen C# niet zo. Ik vind het een mooi ontworpen taal, die zeker zijn limitaties heeft, maar bij elke taal moeten wel eens concessies gedaan worden, want een perfecte taal bestaat nou eenmaal niet. Dat zie je vooral terug bij bijvoorbeeld C++ waar ze het maar niet eens kunnen worden over de nieuwe features waardoor een nieuwe versie telkens uitgesteld word, of features doorgeschoven worden naar een volgende versie.

[Verwijderd]

Grijze Vos schreef op donderdag 19 augustus 2010 @ 08:46:
Welke scoping issues bedoel je dan?

Lambdas zijn w.m.b. overigens prima zoals ze zijn in C#, Wat verwacht je anders van een statically typed taal, dat ze lambdas niet typeren?

scoping:

code:

if(...) {
   string bla;
}
string bla; //invalid

lambdas:
Ik vind de huidige oplossing een beperkend compromis. Het aantal parameters is beperkt tot 4 (Func<T1, T2, T3,T4, R>). Er zijn ook andere manieren om dit aan je taal toe te voegen zonder een beperking op te leggen.

Overigens zeg ik hier niet mee dat ik C# slecht vind, tegendeel, prima taal en op veel punten zeer krachtig.

[RayNbow]

Verwijderd schreef op donderdag 19 augustus 2010 @ 09:06:
lambdas:
Ik vind de huidige oplossing een beperkend compromis. Het aantal parameters is beperkt tot 4 (Func<T1, T2, T3,T4, R>).

Niet in .NET 4 hoor

Hell, zelfs niet in oudere .NET versies:

C#:

delegate R Awesome<in A, in B, in C, in D, in E, out R>(A a, B b, C c, D d, E e);
static void Main(string[] args)
{
    Awesome<int, int, int, int, int, int> f = (a, b, c, d, e) => a + b + c + d + e;
    Console.WriteLine(f(1, 2, 3, 4, 5));
    Console.ReadKey();
}

[Grijze Vos]

Dat is geen scoping issue maar een weloverwogen keuze.
Als je code die je niet kent leest en je komt in dezelfde functie twee keer dezelfde identifier tegen kun je gaan denken dat het nog steeds dezelfde is. (Als je over de tweede declaratie heen leest.)

Door expliciet die dubbele naming niet toe te staan voorkom je gewoon programmeerfouten.

[Woy]

Verwijderd schreef op donderdag 19 augustus 2010 @ 09:06:
[...]
scoping:

code:

if(...) {
   string bla;
}
string bla; //invalid

Het lijkt me dat dat niet anders is in de meeste andere talen, de 2e string bla is gewoon in het hele block gedefinieerd, en die kan je in een genest block niet nogmaals definiëren. Ik moet toegeven dat het op het eerste gezicht wel vreemd is, en er valt ook wel wat voor te zeggen om het toe te staan, maar ik zou het niet echt een issue noemen, want je code word ook niet echt duidelijker door variabele namen op die manier te hergebruiken. Bovendien is dat gewoon een bewuste keuze, dus niet iets wat met haast te maken heeft.

lambdas:
Ik vind de huidige oplossing een beperkend compromis. Het aantal parameters is beperkt tot 4 (Func<T1, T2, T3,T4, R>). Er zijn ook andere manieren om dit aan je taal toe te voegen zonder een beperking op te leggen.

Ik wist niet dat een Lambda gelimiteerd was op 4 parameters, dat is dan idd wel een beetje jammer, maar ik ben er nog nooit tegen aan gelopen.

[ Voor 4% gewijzigd door Woy op 19-08-2010 09:46 ]

[Verwijderd]

RayNbow schreef op donderdag 19 augustus 2010 @ 09:44:
Niet in .NET 4 hoor

Hell, zelfs niet in oudere .NET versies:

Ah dat laatste wist ik niet. Overigens zijn er wel betere manieren om lambdas te implementeren. Bijvoorbeeld door het als een functie te zien zodat daarmee elke interface methode als lambda kan worden uitgedrukt. Voordeel daarvan is dat je niet je API hoeft uit te breiden/ aan te passen om een lambda expressie toe te staan.

[Woy]

Verwijderd schreef op donderdag 19 augustus 2010 @ 10:05:
[...]
Bijvoorbeeld door het als een functie te zien zodat daarmee elke interface methode als lambda kan worden uitgedrukt.

Een lambda kan ook voor elke interface gedefiniëerd worden, maar om er een referentie naar te hebben moet je toch een type hebben die die interface bevat. En de manier om een interface van een methode vast te leggen in een type is een Delegate. Het enige probleem is dus dat er alleen standaard types voor Func's tot 4 parameters zijn opgenomen.

[ Voor 19% gewijzigd door Woy op 19-08-2010 10:10 ]

[Verwijderd]

Woy schreef op donderdag 19 augustus 2010 @ 10:08:
Een lambda kan ook voor elke interface gedefiniëerd worden, maar om er een referentie naar te hebben moet je toch een type hebben die die interface bevat.

Ik doel hier op:

code:

static void Main(string[] args)
        {
            Calculate(i, j => i + j);
        }
        static int Calculate(MyIterface func) { return func.Calculate(3, 4); }
        interface MyIterface { int Calculate(int a, int b);}

Volgens mij kan dit niet maar op dit punt wordt heeeeel graag gecorrigeerd

[Woy]

Nee een Lambda is een anonymous function, en dat is wat anders dan een interface. Een interface kan immers meerdere methodes bevatten. Als je een interface voor een enkele methode wilt definiëren, moet je een delegate definiëren.

Hoe zie jij jouw voorbeeld anders voor je als je een interface met meerdere methodes hebt? Hoe moet de compiler weten welke van de methodes hij aan moet roepen?

[Verwijderd]

Woy schreef op donderdag 19 augustus 2010 @ 10:36:
Nee een Lambda is een anonymous function, en dat is wat anders dan een interface. Een interface kan immers meerdere methodes bevatten. [..] Hoe zie jij jouw voorbeeld anders voor je als je een interface met meerdere methodes hebt? Hoe moet de compiler weten welke van de methodes hij aan moet roepen?

De compiler kan dat niet weten zonder dat je hem dat expliciet verteld. In zo'n geval is je statement simpelweg ambigu. Echter in veel situaties is het te herleiden en geeft een dergelijke implementatie een enorm voordeel: je kunt je lambda expressies loslaten op bestaande APIs. Een taal als Groovy kan dit bijvoorbeeld voor single method interfaces.

[roy-t]

http://forums.xna.com/forums/p/59092/363001.aspx
Geweldig debat over OO programmeren (door een mod afgesplitst). Aan de titel te zien weet je al hoe het zal gaan.

In het kort:
1 jongen 2e jaars aan een College heeft een nogal andere kijk op OO programmeren.
-Maak eerst alles public, zorg dat je class alles kan en limiteer pas op het einde de mogelijkheden van de class en maak alles private wat niet public hoeft te zijn (vast geweldig om mee samen te werken).

-Gebruikt nooit een debugger want hij schrijft iteratief schone code en weet dus altijd precies waar de bug zit, iedereen die wel een debugger gebruikt schrijft smerige code!


Samenwerken met deze gast is vast leuk .

[.oisyn]

R4gnax schreef op donderdag 19 augustus 2010 @ 00:04:
[...]


Kwestie van terminologie. In C++ heb je dezelfde operaties beschikbaar als static_cast<T> en dynamic_cast<T>. (Gesproken over een taal waar niet over nagedacht is, trouwens...)

Als er een taal is waar juist enorm over nagedacht wordt dan is C++ dat wel. Het verschil met andere talen is dat zij niet zoveel bagage hebben als C++ dat heeft.

Verwijderd schreef op donderdag 19 augustus 2010 @ 10:19:
[...]
Ik doel hier op:

code:

static void Main(string[] args)
        {
            Calculate(i, j => i + j);
        }
        static int Calculate(MyIterface func) { return func.Calculate(3, 4); }
        interface MyIterface { int Calculate(int a, int b);}

Volgens mij kan dit niet maar op dit punt wordt heeeeel graag gecorrigeerd

Verander MyInterface in een MyDelegate en het werkt gewoon.

Het type van een lambda is niet per se Func<>. Dat hangt namelijk nogal af van de context. Een Func<> is namelijk gewoon een getypeerde delegate. Delegates met dezelfde parameters en returntype zijn gewoon compatible, en daardoor kun je een lambda assignen aan een Func<> (of eigenlijk, pas bij een assignment aan een delegate bepaalt de compiler wat de types van de parameters zijn en giet hij het in de vorm van een delegate). Je kan een lambda ook assignen aan een Expression<>, en dan krijg je de expressie-boom van de lambda.

Dat Java nou zo gelimiteerd is ontworpen dat er interfaces moeten worden misbruikt om function-pointers te kunnen implementeren, en dat jij vervolgens diezelfde hack in C# wilt gebruiken terwijl dat niet kan omdat je daar betere constructies voor hebt, is niet de schuld van C#.

[ Voor 72% gewijzigd door .oisyn op 19-08-2010 16:09 ]

[Woy]

Verwijderd schreef op donderdag 19 augustus 2010 @ 10:48:
[...]
Echter in veel situaties is het te herleiden en geeft een dergelijke implementatie een enorm voordeel: je kunt je lambda expressies loslaten op bestaande APIs. Een taal als Groovy kan dit bijvoorbeeld voor single method interfaces.

Maar Groovy is gebaseerd op de JVM als ik zo snel in google kijk. Dan is het logischer om iets op die manier te implementeren. C# heeft vanaf het begin delegates gehad, en dan is het veel logischer om het op die manier te doen. Een dergelijke functie introduceren levert IMHO alleen maar meer onduidelijkheid op, aangezien er gewoon een beter alternatief is.

Het is inderdaad alleen een voordeel voor API's die er niet op ingericht zijn, maar dan nog is de bruikbaarheid beperkt tot single method interfaces. Ik zou het dan makkelijker vinden om de mogelijkheid te hebben om inline een interface te implementeren.

code:

static void Main(string[] args)
{
    Calculate(i, new MyIterface(){ Calculate: j => i + j });
}
static int Calculate(MyIterface func) { return func.Calculate(3, 4); }
interface MyIterface { int Calculate(int a, int b);}

Of iets in die trant.

[.oisyn]

Woy schreef op donderdag 19 augustus 2010 @ 09:06:
De traagst evoluerende taal moet toch wel C++ zijn met C++ 01x

Tot aan 2015 kan het C++0x blijven heten (dan wordt het C++0xf )

[alex3305]

roy-t schreef op donderdag 19 augustus 2010 @ 11:14:
http://forums.xna.com/forums/p/59092/363001.aspx
Geweldig debat over OO programmeren (door een mod afgesplitst). Aan de titel te zien weet je al hoe het zal gaan.

Het XNA forum . Soms staan er best zinnige dingen op, maar ik heb ook al vaak dingen gelezen als "Ik heb gehoord dat je met C# een 3D shooter kan maken. Kan ik nu MW2 hacken?" oid.

In het kort:
1 jongen 2e jaars aan een College heeft een nogal andere kijk op OO programmeren.
-Maak eerst alles public, zorg dat je class alles kan en limiteer pas op het einde de mogelijkheden van de class en maak alles private wat niet public hoeft te zijn (vast geweldig om mee samen te werken).

Public, vaak niet de meest handige modifier om te gebruiken in C# IMHO. Dan is 'internal' vaak nog beter toepasbaar.

-Gebruikt nooit een debugger want hij schrijft iteratief schone code en weet dus altijd precies waar de bug zit, iedereen die wel een debugger gebruikt schrijft smerige code!

Samenwerken met deze gast is vast leuk .

Gebruik nooit een debugger . Dat zal 'em vast gaan worden. Ook al schrijf je de schoonste code allertijden, dan lijkt het mij nog wel eens slim om waarde X te controleren in methode Y.

Ik zou wel wat code-voorbeelden van deze gozer willen zien.

[kenneth]

Mijn docent testen was ook fel tegen debuggers omdat die dingen een symptoom zouden zijn van slechte voorbereiding, gebrek aan goede unit tests en slechts leiden tot ad hoc programeerwerk ...

[boe2]

alex3305 schreef op donderdag 19 augustus 2010 @ 14:27:
[...]

Het XNA forum . Soms staan er best zinnige dingen op, maar ik heb ook al vaak dingen gelezen als "Ik heb gehoord dat je met C# een 3D shooter kan maken. Kan ik nu MW2 hacken?" oid.

Ik heb er zelf vorig jaar wat rondgehangen omdat ik wat ervaring wou opdoen op vlak van 2D gamedesign. Sommige van die recruteringstopics zijn echt te slecht voor woorden. In de trend van: "goeiedag, ik heb vorige week voor het eerst in mijn leven visual studio eens aangeraakt en heb een fantastisch idee voor een 3D shooter. Voor mijn project heb ik enkele programmeurs en artiesten nodig en met wat geluk kunnen we over 3 maanden ons product voorstellen".

Anderzijds ben ik er wel vrij snel in contact gekomen met enkele mensen die serieus bezig waren voor een project waarmee ze gingen deelnemen in dream-build-play. Ze waren echter nog op zoek mensen die full-time werk konden doen, wat ik simpelweg niet kan doen (en al helemaal niet onbezoldigd). Passionele mensen daar, maar vrees dat ik zelf niet passioneel genoeg ben

[.oisyn]

kenneth schreef op donderdag 19 augustus 2010 @ 14:33:
Mijn docent testen was ook fel tegen debuggers omdat die dingen een symptoom zouden zijn van slechte voorbereiding, gebrek aan goede unit tests en slechts leiden tot ad hoc programeerwerk ...

Het is wel weer duidelijk dat een dergelijke docent nooit een echte applicatie heeft geschreven.

[HMS]

roy-t schreef op donderdag 19 augustus 2010 @ 11:14:
http://forums.xna.com/forums/p/59092/363001.aspx
Geweldig debat over OO programmeren (door een mod afgesplitst). Aan de titel te zien weet je al hoe het zal gaan.

In het kort:
1 jongen 2e jaars aan een College heeft een nogal andere kijk op OO programmeren.
-Maak eerst alles public, zorg dat je class alles kan en limiteer pas op het einde de mogelijkheden van de class en maak alles private wat niet public hoeft te zijn (vast geweldig om mee samen te werken).

-Gebruikt nooit een debugger want hij schrijft iteratief schone code en weet dus altijd precies waar de bug zit, iedereen die wel een debugger gebruikt schrijft smerige code!


Samenwerken met deze gast is vast leuk .

Ik denk: "Successfull troll is successfull"

Hoewel hij wel punten heeft waar van ik denk, moah daar zit wel wat in. Alleen de manier waarop hij ze presenteerd is nogal naief.

Het lijkt me trouwens niet echt een teamplayer, samenwerken met zoiemand is echt een hel. Maar misschien verteld ie maar de helft van het verhaal .

[CodeCaster]

Boeboe schreef op donderdag 19 augustus 2010 @ 14:39:
[...]


Ik heb er zelf vorig jaar wat rondgehangen omdat ik wat ervaring wou opdoen op vlak van 2D gamedesign. Sommige van die recruteringstopics zijn echt te slecht voor woorden. In de trend van: "goeiedag, ik heb vorige week voor het eerst in mijn leven visual studio eens aangeraakt en heb een fantastisch idee voor een 3D shooter. Voor mijn project heb ik enkele programmeurs en artiesten nodig en met wat geluk kunnen we over 3 maanden ons product voorstellen".

Anderzijds ben ik er wel vrij snel in contact gekomen met enkele mensen die serieus bezig waren voor een project waarmee ze gingen deelnemen in dream-build-play. Ze waren echter nog op zoek mensen die full-time werk konden doen, wat ik simpelweg niet kan doen (en al helemaal niet onbezoldigd). Passionele mensen daar, maar vrees dat ik zelf niet passioneel genoeg ben

Ik denk dat het meer met rijke ouders, een school om de hoek en/of een lening te maken heeft dan met passie.

[kenneth]

.oisyn schreef op donderdag 19 augustus 2010 @ 14:59:
[...]

Het is wel weer duidelijk dat een dergelijke docent nooit een echte applicatie heeft geschreven.

VWO -> universiteit -> promotie -> voor de klas.

Zo'n type. Inspirerend figuur waar je veel van kon leren maar je moest wel weten wanneer je je vingers in je oren moest stoppen.

[Sebazzz]

.oisyn schreef op donderdag 19 augustus 2010 @ 11:54:
[...]

Dat Java nou zo gelimiteerd is ontworpen dat er interfaces moeten worden misbruikt om function-pointers te kunnen implementeren

Dat is natuurlijk ook een keuze, net zoals het triviale dingen zoals properties mist.

[.oisyn]

Natuurlijk is dat een keuze. En Groove hackt om die keuze heen, en vervolgens gebruikt je mark platvoet dat als argument waarom er in C# niet goed over na is gedacht

.edit: oh oeps ik verwar jou nu met mark platvoet.

[ Voor 25% gewijzigd door .oisyn op 19-08-2010 16:07 ]

[Vinnienerd]

Delegates etc. zijn er juist zodat je in Java en C# niet met pointers hoeft te werken.

[.oisyn]

Het ging ten eerste om functiepointers, en ten tweede als een concept. Niet om letterlijke pointers zoals in C en C++. Ergo, een delegate is ook gewoon een functiepointer. En java kent geen delegates, dus Groove hackt daar omheen door interfaces te gebruiken.

[ Voor 48% gewijzigd door .oisyn op 19-08-2010 15:45 ]

[Sebazzz]

Dat er ondertussen geen C# op een JVM is

Als we het toch over hackwerk gaan hebben, ik zou Java meer hackwerk noemen omdat je daar geen operator overloading hebt, maar toch de + operator is overloaded bij de String class zodat je geen .concat hoeft te gebruiken.

[Woy]

Sebazzz schreef op donderdag 19 augustus 2010 @ 15:48:
Als we het toch over hackwerk gaan hebben, ik zou Java meer hackwerk noemen omdat je daar geen operator overloading hebt, maar toch de + operator is overloaded bij de String class zodat je geen .concat hoeft te gebruiken.

Dat vind ik wel meevallen. Het niet ondersteunen van operator overloading om zo de taal "schoner" te houden vind ik niet zo heel gek, al had ik zelf een andere keuze gemaakt.

Dat de + operator van String overloaded is vind ik niet gek. Strings hebben immers sowieso al een aparte status binnen de taal aangezien er speciale syntax is om een object van het type string te instantieren.

[Vinnienerd]

.oisyn schreef op donderdag 19 augustus 2010 @ 15:44:
Het ging ten eerste om functiepointers, en ten tweede als een concept. Niet om letterlijke pointers zoals in C en C++. Ergo, een delegate is ook gewoon een functiepointer. En java kent geen delegates, dus Groove hackt daar omheen door interfaces te gebruiken.

Functiepointers zijn toch ook pointers? Ze wijzen alleen naar de plek van een functie in het geheugen ipv. een variable. C# kent bijvoorbeeld IntPtr als je met native DLLs werkt.

[.oisyn]

Een pointer is toch gewoon een verwijzing? Java en C# kennen toch ook pointers?

Snap je nu wat ik bedoel? Je hebt het concept pointers (of referenties of verwijzingen of whatever), en de specifieke C++ implementatie ervan. En ondertussen loop je nu de boel te verwarren door in een een of andere discussie iets compleet buiten context te roepen. Een delegate ís een pointer (verwijzing) naar een functie, klaar. Het hele idee van functiepointers in C is helemaal niet aan de orde gekomen, dat is iets wat jij erbij haalde.

[ Voor 78% gewijzigd door .oisyn op 19-08-2010 16:18 ]

[Verwijderd]

.oisyn schreef op donderdag 19 augustus 2010 @ 15:40:
En Groove hackt om die keuze heen, en vervolgens gebruikt je mark platvoet dat als argument waarom er in C# niet goed over na is gedacht

Het is totaal irrelevant of het in Groovy een hack is om over de tekortkomingen van Java heen te komen. Het relevante is het conceptuele voorbeeld wat het gebruik van nieuwe en bestaande APIs kan vereenvoudigen. Het is toch gewoon fijn om bijvoorbeeld een IComparer direct als lambda te kunnen opschrijven.

[.oisyn]

Daar heb je een Comparison<T> voor. Da's een delegate. Die werkt met lambda's.

[Woy]

Bovendien kun je ook in C en C++ gewoon type"safe" functiepointers definiëren.

C:

typedef int(*pfCallBack)(int, int);

Het "probleem" met pointers is vooral de pointer arithmetic, en het feit dat het memory managment wat anders werkt, waardoor je er sneller problemen mee krijgt.

.oisyn schreef op donderdag 19 augustus 2010 @ 16:18:
Daar heb je een Comparison<T> voor. Da's een delegate. Die werkt met lambda's.

Al zou ik het wel makkelijk vinden als je inline een interface zou kunnen implementeren, zodat je je Lambda/Delegate gewoon kunt wrappen op het moment dat de Library toch gebruik maakt van interfaces in plaats van Delegates. Dat is IMHO een stuk duidelijker dan maar wat compiler magic die zelf uitzoekt welke methode hij aan moet roepen.

[ Voor 47% gewijzigd door Woy op 19-08-2010 16:23 ]

[.oisyn]

Gelukkig bestaat dat probleem niet voor functiepointers, want daar kun je niet mee rekenen . Overigens wijzen pointer to members weer alleen naar het member, ze hebben geen object-context zoals een delegate dat wel heeft. En daarom heb je ook std::tr1::function<int (int, int)>, en std::tr1::bind() om een 'this' aan een pointer to memberfunction te binden. De syntax is alleen niet zo mooi.

C++:

#include <functional>
#include <iostream>

using namespace std::tr1;

class MyClass
{
public:
    MyClass(int i) : i(i) { }
    void Foo() { std::cout << i << std::endl; }
private:
    int i;
};

int main()
{
    MyClass o(42);
    function<void()> func = bind(&MyClass::Foo, o);  // ipv iets als: = &o.Foo;
    func();
}

[ Voor 255% gewijzigd door .oisyn op 19-08-2010 16:31 ]

[Verwijderd]

.oisyn schreef op donderdag 19 augustus 2010 @ 16:18:
Daar heb je een Comparison<T> voor. Da's een delegate. Die werkt met lambda's.

Wat dus in de regel betekent dat de de .Net API overloaded methods bevat om beide te ondersteunen. bijvoorbeeld: Sort(Comparison<T>), Sort(IComparer<T>)
Ik vind dat niet handig

[.oisyn]

Idd, die hele IComparer interface is nutteloos.

[ Voor 16% gewijzigd door .oisyn op 19-08-2010 16:28 ]

[Verwijderd]

.oisyn schreef op donderdag 19 augustus 2010 @ 16:28:
Idd, die hele IComparer interface is nutteloos.

Toegegeven, ik moest grinniken

[Woy]

Ze hadden de IComparer<T> versie ook gewoon weg kunnen laten IMHO

edit:

Spuit 11

[ Voor 15% gewijzigd door Woy op 19-08-2010 16:32 ]

[Vinnienerd]

.oisyn schreef op donderdag 19 augustus 2010 @ 16:15:
Een pointer is toch gewoon een verwijzing? Java en C# kennen toch ook pointers?

Snap je nu wat ik bedoel? Je hebt het concept pointers (of referenties of verwijzingen of whatever), en de specifieke C++ implementatie ervan. En ondertussen loop je nu de boel te verwarren door in een een of andere discussie iets compleet buiten context te roepen. Een delegate ís een pointer (verwijzing) naar een functie, klaar. Het hele idee van functiepointers in C is helemaal niet aan de orde gekomen, dat is iets wat jij erbij haalde.

Ik bedoel alleen maar te zeggen dat er in C# wel degelijk over dingen nagedacht is qua callbackfuncties, door een vergelijking te trekken tussen delegates in C# en function pointers in C. In Java gaat dat juist via een omweggetje.

[Davio]

Ach, die gozer lijkt wel clueless, maar volgens mij snapt de rest op dat forum ook niet echt dat hij gewoon op hetzelfde uitkomt als iemand die met alles private begint.

Hij doet het gewoon omgekeerd.

En het is onzin dat hij nooit een debugger heeft gebruikt; hij denkt waarschijnlijk dat dat een apart programma is dat je moet starten. Als je Visual Studio gebruikt, run je toch alles via de debugger.

[.oisyn]

Vinnienerd schreef op donderdag 19 augustus 2010 @ 16:37:
[...]


Ik bedoel alleen maar te zeggen dat er in C# wel degelijk over dingen nagedacht is qua callbackfuncties, door een vergelijking te trekken tussen delegates in C# en function pointers in C. In Java gaat dat juist via een omweggetje.

Ja maar dat was toch allang de revue gepasseerd
.oisyn in "[alg] Slechtste programmeervoorbeelden d..."

[Vinnienerd]

Davio schreef op donderdag 19 augustus 2010 @ 16:37:
Ach, die gozer lijkt wel clueless, maar volgens mij snapt de rest op dat forum ook niet echt dat hij gewoon op hetzelfde uitkomt als iemand die met alles private begint.

Hij doet het gewoon omgekeerd.

En het is onzin dat hij nooit een debugger heeft gebruikt; hij denkt waarschijnlijk dat dat een apart programma is dat je moet starten. Als je Visual Studio gebruikt, run je toch alles via de debugger.

Volgens mij is het gewoon een troll.

[Azer]

Ik werk sinds korte tijd als softwareontwikkelaar bij een bedrijf. Ik had de volgende code geschreven:

C#:

public void doeiets(int parameter1, int parameter2)
{
     doedit(parameter1);
     doedat(parameter2);
     doenogmeer();
}

public void functie1()
{
      doeiets(1, 2);
      doenogiets();
}

public void functie2()
{
      doeiets(5, 1);
      doenogiets();
}

public void functie3()
{
      doeiets(2, 8);
      doenogiets();
}

Gaat de één van de hoofdontwikkelaars de code met mij doornemen, moet ik het volgens hem op deze manier maken:

C#:

public void functie1()
{
     doedit(parameter1);
     doedat(parameter2);
     doenogmeer();
     doenogiets();
}

public void functie2()
{
     doedit(parameter1);
     doedat(parameter2);
     doenogmeer();
     doenogiets();
}

public void functie3()
{
     doedit(parameter1);
     doedat(parameter2);
     doenogmeer();
      doenogiets();
}

Toen ik hier tegenin ging, omdat het veel repeterende code zou zijn (het ging totaal om ongeveer 20 van deze functies, waar slechts een paar parameters verschillend zouden zijn), vertelde hij dat ik nog niet ervaren genoeg was om hem te begrijpen

Binnenkort maar op zoek naar een andere baan denk ik.

[Tharulerz]

@ Azer, ik denk dat je een slecht voorbeeld hebt gegeven. Voor beide implementaties is iets te zeggen, afhankelijk van wat de functies doen, waar ze gebruikt worden, hoe vaak ze gebruikt worden, hoe vaak ze aangepast worden, etc.

Soms kan het beter zijn om in 1 oogopslag te kijken wat een functie doet dan 5 functies diep te moeten zoeken voor je weet wat die functie doet.

Alhoewel als je zegt dat het er 20 zijn lijkt het eigenaardig, maar dan nog.

[.oisyn]

Tharulerz schreef op vrijdag 20 augustus 2010 @ 00:44:
Voor beide implementaties is iets te zeggen

Klopt, maar:

Azer schreef op vrijdag 20 augustus 2010 @ 00:25:
Toen ik hier tegenin ging, [..] vertelde hij dat ik nog niet ervaren genoeg was om hem te begrijpen

Als je een (in jouw ogen) valide standpunt hebt dan kun je die verdedigen. Als je zonder discussie gelijk de ervaring-kaart speelt dan a) leert de junior er niets van en b) is de kans groot dat je eigenlijk helemaal geen valide argument hébt.

@Azer: ik zou als ik jou was nog eens de discussie met hem aangaan. Als ie het weer over ervaring heeft dan moet je zeggen dat je graag wil leren. Als hij alsnog geen argumenten wil geven moet je het er eens met iemand anders over hebben (openlijk, zodat hij dat ook opmerkt, liefst terplekke waar hij bij staat iets van "hey [2e collega], wat vind jij eigenlijk"). Als ie dan boos wordt is het wel duidelijk dat ie gewoon geen tegenspraak duidt ookal draag je goede argumenten aan, en dan weet je zeker dat je onder zo'n iemand niet wil werken. Heeft ie daarentegen een uitleg (of je het er nou helemaal mee eens bent of niet - je hebt immers wel minder ervaring, dus er is een kans dat hij het wel bij het juiste eind heeft ) dan is de werkplek wellicht zo slecht nog niet

[ Voor 38% gewijzigd door .oisyn op 20-08-2010 02:22 ]

[Azer]

Tharulerz schreef op vrijdag 20 augustus 2010 @ 00:44:
@ Azer, ik denk dat je een slecht voorbeeld hebt gegeven. Voor beide implementaties is iets te zeggen, afhankelijk van wat de functies doen, waar ze gebruikt worden, hoe vaak ze gebruikt worden, hoe vaak ze aangepast worden, etc.

Soms kan het beter zijn om in 1 oogopslag te kijken wat een functie doet dan 5 functies diep te moeten zoeken voor je weet wat die functie doet.

Alhoewel als je zegt dat het er 20 zijn lijkt het eigenaardig, maar dan nog.

Bij het ontwikkelen van software zijn er natuurlijk altijd meerdere manieren om iets op te lossen, maar in dit geval vond ik mijn oplossing toch veel beter. De functie doeiets was een functie die verbinding maakt met een database. De parameters zijn het SQL commando dat uitgevoerd moet worden, deze verschillen namelijk bij functie1, functie2 en functie3.

Nu heb ik dus de code om verbinding te maken met een database in elke functie gekopieerd Omdat het om 20 van deze functies ging, ging mijn code ook van 350 regels naar ongeveer 1200.

Deze code om verbinding te maken met de database is dus overal precies hetzelfde, alleen het SQL commando verschilt.

[jip_86]

Hmm voor allebei is nog steeds wel iets te zeggen. Verbinding maken en en commando uitvoeren is logischerwijs iets wat ik wel zou scheiden. Maar als je dan van 350 naar 1200 gaat zit er wel iets fout

[Azer]

.oisyn schreef op vrijdag 20 augustus 2010 @ 02:08:

@Azer: ik zou als ik jou was nog eens de discussie met hem aangaan. Als ie het weer over ervaring heeft dan moet je zeggen dat je graag wil leren. Als hij alsnog geen argumenten wil geven moet je het er eens met iemand anders over hebben (openlijk, zodat hij dat ook opmerkt, liefst terplekke waar hij bij staat iets van "hey \[2e collega], wat vind jij eigenlijk"). Als ie dan boos wordt is het wel duidelijk dat ie gewoon geen tegenspraak duidt ookal draag je goede argumenten aan, en dan weet je zeker dat je onder zo'n iemand niet wil werken. Heeft ie daarentegen een uitleg (of je het er nou helemaal mee eens bent of niet - je hebt immers wel minder ervaring, dus er is een kans dat hij het wel bij het juiste eind heeft ) dan is de werkplek wellicht zo slecht nog niet

Bedankt voor het advies Het probleem is alleen echter dat het maar een kleine afdeling is. Er is nog een andere ontwikkelaar, maar die heb ik nog maar een paar keer gezien omdat hij op vakantie ging kort nadat ik begon. Volgende week heb ik een evaluatiegesprek, waarin ik nog een keer met hem in discussie zal gaan.

jip_86 schreef op vrijdag 20 augustus 2010 @ 08:53:
Hmm voor allebei is nog steeds wel iets te zeggen. Verbinding maken en en commando uitvoeren is logischerwijs iets wat ik wel zou scheiden. Maar als je dan van 350 naar 1200 gaat zit er wel iets fout

Ik had het dus gescheiden, maar hij wil juist dat het niet gescheiden is. Als het niet gescheiden is, gaat het aantal regels dus naar ongeveer 1200 in plaats van 350.

[ Voor 20% gewijzigd door Azer op 20-08-2010 09:40 ]

[mcDavid]

Tharulerz schreef op vrijdag 20 augustus 2010 @ 00:44:
@ Azer, ik denk dat je een slecht voorbeeld hebt gegeven. Voor beide implementaties is iets te zeggen, afhankelijk van wat de functies doen, waar ze gebruikt worden, hoe vaak ze gebruikt worden, hoe vaak ze aangepast worden, etc.

Soms kan het beter zijn om in 1 oogopslag te kijken wat een functie doet dan 5 functies diep te moeten zoeken voor je weet wat die functie doet.

Dat lijkt me een argument om duidelijke functienamen te kiezen. Niet om al je functies op te blazen

[YopY]

Moet je hem eens huiswerk geven - "Pas deze code (verbinding maken met de database) eens aan." Of daag hem uit voor een wedstrijd - hij met zijn code, jij met de jouwe, wie kan het snelste en bugvrij een aanpassing maken in die code.

iig, je kunt ook de technieken die besproken zijn in deze vraag op SO. Eigenlijk is het heel logisch - zelf zul je, als junior, niet serieus genomen worden als je mensen direct aanspreekt. Echter, als je ze hints stuurt en links naar interresante artikelen (in dit geval over code duplicatie en evt. iets basaals als verbinding maken met een database zonder code te dupliceren) zullen ze dat zelf lezen. Omdat dat vaak van een andere bron is (die óf autoriteit uitstraalt, óf gewoon neutraal is) zal de ontwikkelaar dat makkelijker overnemen dan wanneer een junior developer dit aandraagt.

Zit spychologie achter, . Ander voorbeeld: je kunt beter je baas spammen met links naar onderzoeken over verhoogde productiviteit door het gebruik van twee monitoren dan om een tweede monitor te vragen. (afhankelijk van de baas, die van mij zou het zomaar doen - mits ik een PC had ipv een laptop ).

[Azer]

Ik heb het er daarnet nog even met hem over gehad, dit keer kwam hij wel met argumenten. Zijn argumenten waren:
1. Het zou makkelijk te zien zijn voor andere programmeurs wat de functie precies doet.
2. De code om te verbinden met de database zal toch nooit veranderen, dus het maakt niet uit of dit op 1 plek staat of op meerdere plekken.

Ik ben het er nog steeds niet mee eens, omdat het in mijn mening nooit te voorspellen is dat bepaalde code nooit hoeft te veranderen. Ook vind ik zijn eerste argument zwak, aangezien het met goede functienamen ook duidelijk is wat de functie doet.

Toch vind ik het fijn dat ik het met hem heb kunnen bespreken, gisteren was ik nogal boos omdat hij vooral dooddoeners gebruikte om zijn wil door te drijven ("ik heb meer ervaring dus we doen het zo"). Ook al zijn we het niet eens geworden, ik heb er toch een beter gevoel bij dan dat ik gisteren had.

[.oisyn]

[YopY]

Een functie maakDatabaseVerbinding() is minder duidelijk dan ConnectionManager.getConnection().prepareStatement("SELECT * FROM x").execute(); ?

Er zit logica achter zijn stellingen, maar ook gewoon misconcepties. Voor het maken van een verbinding moet je toch ook weten wat getConnection() (van de database connector API) doet? Waarom zou hij er dan zoveel moeite mee hebben als dat vervangen wordt met een functie die dat aanpast?

En als hij code copy-pastaen leuk vindt moet 'ie dat zelf weten, .

En makkelijk te zien zijn wat een functie doet... Als ik als ontwikkelaar een bestand van 1300 regels zie waar 2/3e copypasta-code is ga ik facepalmen. Er bestaat ook zoiets als codeblindheid - bij veel copypasta code zie je niet meer wat het verschil is tussen twee functies, en heb je meer tijd nodig om goed te kijken wat een functie doet (lees: de copypasta boilerplate code mentaal filteren).

Ga voor de lol eens kleine aanpassingkjes doen in elk stukje copypasta code, formattering net iets anders, hier en daar een bugje introduceren, en geef hem de opdracht om je te helpen omdat je de bug(s) niet kunt vinden. (let op: stel je junior op, doe een beroep op zijn onmetelijke kennis en ervaring).

Kijken of hij het nog leuk vindt .

(Disclaimer: Heb zelf ook gewerkt met een bestand dat heel veel copypasta code had met het ophalen van een verbinding, starten van een transactie, query uitvoeren en verwerken en transactie comitten. Daar zijn 'design patterns' (soort van) om dat te voorkomen, o.a. het verwerken van de queryresultaten door een handler object uit laten voeren)

[Davio]

Lijkt toch alsof hij één van de oeroude progammer-paradigma's niet kent: "Never repeat yourself."

Want stel nou dat er een fout blijkt te zitten in het verbinden met de database of het wachtwoord wordt een keer gewijzigd (noem maar wat): wil je dat dan 1 of 1000x veranderen?

[Verwijderd]

Davio schreef op vrijdag 20 augustus 2010 @ 12:59:
Lijkt toch alsof hij één van de oeroude progammer-paradigma's niet kent: "Never repeat yourself."

Was dat niet "Don't repeat yourself" (DRY)...

[Davio]

Verwijderd schreef op vrijdag 20 augustus 2010 @ 13:15:
[...]

Was dat niet "Don't repeat yourself" (DRY)...

True, maar ik vind zogenaamd hippe acroniemen stom.

[brama]

C:

int item = item_list[0]; // Always select the first item in this case!

Correctie:

C:

int item = item_list[0]; // select first item in this case because INSERT_REASON_HERE

Waarom is het nou toch zo fucking moeilijk voor de meeste coders om te begrijpen dat het geen zin heeft om je statements letterlijk uit te schrijven in commentaar? Documenteer dan in godsnaam de REDEN. Snappu? Kthxbye.

[kenneth]

Jaaaa, jij snapt het

Ik heb code moeten onderhouden waar zelfs statements als "i++" werden toegelicht

[Webgnome]

kenneth schreef op vrijdag 20 augustus 2010 @ 14:48:
Jaaaa, jij snapt het

Ik heb code moeten onderhouden waar zelfs statements als "i++" werden toegelicht

Maar dat is altijd nog beter dan dat er helemaal geen commentaar in code zit en je bij een functie van een bijna 100 regels maar moet uitzoeken wat er mis gaat / wat de bedoeling is.

[Jegorex]

Davio schreef op vrijdag 20 augustus 2010 @ 13:38:
[...]

True, maar ik vind zogenaamd hippe acroniemen stom.

KISS my ass?

[brama]

Webgnome schreef op vrijdag 20 augustus 2010 @ 14:56:
[...]


Maar dat is altijd nog beter dan dat er helemaal geen commentaar in code zit en je bij een functie van een bijna 100 regels maar moet uitzoeken wat er mis gaat / wat de bedoeling is.

Niet mee eens. "i++; /// Increment i by 1" voegt werkelijk helemaal niets toe. Kan je prima weglaten. Zo ook bij mijn voorbeeld.

[Dido]

Webgnome schreef op vrijdag 20 augustus 2010 @ 14:56:
Maar dat is altijd nog beter dan dat er helemaal geen commentaar in code zit en je bij een functie van een bijna 100 regels maar moet uitzoeken wat er mis gaat / wat de bedoeling is.

Liever geen commentaar dan onzinnig en overbodig commentaar dat niets toevoegt.

Onderstaand voorbeeldje is een impressie van wat ik (30x in 1 source ) tegenkwam nadat iemand een voorbeeldje uit de tutorial had gekopieerd en aangepast

code:

* open integrator using jsmx_open
USE BUILTIN(JSMX_OPEN) WITH_ARGS(#OM10) TO_GET(#JSMSTS #JSMMSG #JSMHDL)
* load service using jsmx_command open
USE BUILTIN(JSMX_COMMAND) WITH_ARGS(#JSMHDL "OPEN SERVICE(SOAPSERVICE)") TO_GET(#JSMSTS #JSMMSG)
* set parameter using jsmx_command set
USE BUILTIN(JSMX_COMMAND) WITH_ARGS(#JSMHDL "SET PARAMETER(PARAM1) EXCHANGE(*FIELDS)") TO_GET(#JSMSTS #JSMMSG)
* set parameter using jsmx_command set
USE BUILTIN(JSMX_COMMAND) WITH_ARGS(#JSMHDL "SET PARAMETER(PARAM2) EXCHANGE(*FIELDS)") TO_GET(#JSMSTS #JSMMSG)
* set parameter using jsmx_command set
USE BUILTIN(JSMX_COMMAND) WITH_ARGS(#JSMHDL "SET PARAMETER(PARAM3) EXCHANGE(*FIELDS)") TO_GET(#JSMSTS #JSMMSG)
* set parameter using jsmx_command set
USE BUILTIN(JSMX_COMMAND) WITH_ARGS(#JSMHDL "SET PARAMETER(PARAM4) EXCHANGE(*FIELDS)") TO_GET(#JSMSTS #JSMMSG)
* set parameter using jsmx_command set
USE BUILTIN(JSMX_COMMAND) WITH_ARGS(#JSMHDL "SET PARAMETER(PARAM5) EXCHANGE(*FIELDS)") TO_GET(#JSMSTS #JSMMSG)
* call service using jsmx_command call
USE BUILTIN(JSMX_COMMAND) WITH_ARGS(#JSMHDL "CALL") TO_GET(#JSMSTS #JSMMSG)

Ziet er nu ongeveer zo uit (en van die 30 instances heb ik 1 functie gemaakt, uiteraard)

code:

* Execute SOAP call
Use Builtin(jsmx_open) With_Args(#om10) To_Get(#jsmsts #jsmmsg #jsmhdl)
Use Builtin(jsmx_command) With_Args(#jsmhdl "open service(soapservice)") To_Get(#jsmsts #jsmmsg)
Use Builtin(jsmx_command) With_Args(#jsmhdl "set parameter(param1) exchange(*fields)") To_Get(#jsmsts #jsmmsg)
Use Builtin(jsmx_command) With_Args(#jsmhdl "set parameter(param2) exchange(*fields)") To_Get(#jsmsts #jsmmsg)
Use Builtin(jsmx_command) With_Args(#jsmhdl "set parameter(param3) exchange(*fields)") To_Get(#jsmsts #jsmmsg)
Use Builtin(jsmx_command) With_Args(#jsmhdl "set parameter(param4) exchange(*fields)") To_Get(#jsmsts #jsmmsg)
Use Builtin(jsmx_command) With_Args(#jsmhdl "set parameter(param5) exchange(*fields)") To_Get(#jsmsts #jsmmsg)
Use Builtin(jsmx_command) With_Args(#jsmhdl "call") To_Get(#jsmsts #jsmmsg)

De oude code was niet fout, maar was niet te onderhouden

[YopY]

Dido schreef op vrijdag 20 augustus 2010 @ 15:29:
[...]
De oude code was niet fout, maar was niet te onderhouden

Zie je pas echt als je de twee naast elkaar zet. De eerste legt mooi uit (voor een half-leek) wat de daaropvolgende regel doet (zodat ze de regel zelf niet hoeven te lezen), maar je refactoring laat zien dat het eigenlijk grotendeels self-documenting code is.

D'r zou eigenlijk een kort verhaaltje bij moeten staan wat er precies gedaan wordt met die SOAP call (set parameters 1 - 5 in soap service call?), maar meer niet.

code:

// increments i by 1 (one). Not 2, not 3, just 1.
// Replace with i = i + 2 if i needs to be incremented by 2. 
// Consider creating a function if i has to be increased with a variable number.
// TODO: write unit test (I don't trust syntactic sugar like this)
// TODO: get code review from Henk.
i++;

[Hydra]

Die i++ is gewoon fout, wat nu als je later inderdaad met 2 wilt incrementen? Nee, i += 1 is dan beter. En aangezien die 1 een magic number is, moet je die voor een constant vervangen. Dus i += CONST_ONE;. Als je dan later wilt incrementen met 2, kun je die CONST gewoon aanpassen. Krijg je dus:

C:

/* increment with 2 */
i += CONST_ONE

[kenneth]

[Verwijderd]

Hydra schreef op vrijdag 20 augustus 2010 @ 16:35:
Die i++ is gewoon fout, wat nu als je later inderdaad met 2 wilt incrementen? Nee, i += 1 is dan beter. En aangezien die 1 een magic number is, moet je die voor een constant vervangen. Dus i += CONST_ONE;. Als je dan later wilt incrementen met 2, kun je die CONST gewoon aanpassen. Krijg je dus:

C:

/* increment with 2 */
i += CONST_ONE

Als je nou wat meer CONSTs aan maakt, dan kan je er gewoon dit van maken:

C:

/* increment with 2 */
i += CONST_TWO

[Reptile209]

Davio schreef op vrijdag 20 augustus 2010 @ 12:59:
Lijkt toch alsof hij één van de oeroude progammer-paradigma's niet kent: "Never repeat yourself."

Want stel nou dat er een fout blijkt te zitten in het verbinden met de database of het wachtwoord wordt een keer gewijzigd (noem maar wat): wil je dat dan 1 of 1000x veranderen?

Dat password zet je toch in een global die je overal gebruikt? * Reptile209 duikt .

[Mammon]

Verwijderd schreef op vrijdag 20 augustus 2010 @ 16:37:
[...]

Als je nou wat meer CONSTs aan maakt, dan kan je er gewoon dit van maken:

C:

/* increment with 2 */
i += CONST_TWO

Doet me denken aan dit artikel.

[Killemov]

Azer schreef op vrijdag 20 augustus 2010 @ 09:18:
[...]
Ik had het dus gescheiden, maar hij wil juist dat het niet gescheiden is. Als het niet gescheiden is, gaat het aantal regels dus naar ongeveer 1200 in plaats van 350.

Een reductie van 1200 naar 350 regels zonder daarmee in de breedte te gaan is al reden genoeg. (Code moet eigenlijk worden gemeten in vierkante characters ) Als de databasefuncties sequentieel worden aangeroepen is het wellicht verstandig om open-sql-sluiten-open-sql-sluiten-open-sql-sluiten te vervangen met open-sql-sql-sql-sluiten. En daarvoor moet je toch al de databaseconnectie apart openen.

[CRiMiNaL]

De mooiste van deze week was toch wel:

PHP:

function foo($time, $meer_argumenten) {
   $sql = //Query voor het checken of een record bestaat
   $res = mysql_query($sql);
   if(mysql_num_rows($res) == 0 || $time == "10:00:00") {
      $sql = //Query voor het inserten van een record
      mysql_query($sql);
   }
}

Reden was dat functie op 2 plaatsen werd aangeroepen en dat er bij een aanroep 1 geen check nodig was (en dan werd het argument tijd op 10:00:00 gezet) en bij aanroep 2 wel. Dat ook aanroep 2 wel eens zou kunnen gebeuren met de tijd op exact 10:00:00 was alleen maar een kwestie van tijd. Met een flinke rotzooi tot gevolg die ik natuurlijk weer op mocht ruimen

[Davio]

Reptile209 schreef op vrijdag 20 augustus 2010 @ 17:07:
[...]

Dat password zet je toch in een global die je overal gebruikt? * Reptile209 duikt .

Nou ja, met wachtwoorden moet je altijd een beetje oppassen natuurlijk; je wilt ook niet dat iemand een external include doet en zo jouw wachtwoord kan achterhalen.

Het was ook maar een voorbeeld.

[X_lawl_X]

Zit ik dagenlang mijn eigen PHP session handler te debuggen omdat de session data meteen vergeten werd, kom ik er na heel lang zoeken achter wat ik fout had gedaan.

PHP:

/* <sessie data ophalen uit database enzo> */
if ($result['user_agent'] != $_SERVER['HTTP_USER_AGENT'])
    #   return '';
                
if ($result['ip_lock'] && $result['user_ip'] != $_SERVER['REMOTE_ADDR'])
    #   return '';

return $result['session_data'];

Ik had de eerste twee return values tijdelijk uitgecomment omdat ik nog geen IPs & user agents had opgeslagen in de database. Een goede reden dus om voortaan weer brackets te gebruiken >.>

[Michali]

Mijn maandagochtend begint goed:

PHP:

// Den_Haag naar Den Haag omzetten
function ReplaceDenHaag($plaats)
{
    if ($plaats == "Den_Haag") {
        $newplaats = "Den Haag";
    } else {
        $newplaats = $plaats;
    }

    return $newplaats;
}