[alg] Slechtste programmeervoorbeelden deel 4

[Olaf van der Spek]

PiepPiep schreef op maandag 03 oktober 2011 @ 14:57:
Het is idd syntactic sugar

Ligt eraan wat je onder sugar verstaat.

code:

f(a ? 1 : 0, b ? 2 : 0, c ? 4 : 0);

Zonder ? : heb je extra variabelen nodig.

[Verwijderd]

Die variabelen worden weer weggeoptimaliseerd. In jouw voorbeeld moet de compiler net zogoed een waarde op de stack pushen alvorens f() aan te roepen.

Dat is een gok hoor maar dat is wat ik denk wat er gebeurt.

[ Voor 18% gewijzigd door Verwijderd op 03-10-2011 15:27 ]

[MBV]

@Olaf: als je dat door mij laat reviewen mag je dat er direct weer uithalen, want het is niet leesbaar en geeft bij kleine typfoutjes een compleet ander gedrag. Maar het kan erger:

code:

x = a ? 1 : b ? 2 : c ? 3 : 0;

[xos]

of

code:

cond1 ? a : b = cond2 ? c : d

Dit soort constructies ontstonden toen een programmeur nog 1 jaar moest voordat hij met pensioen mocht en geen zin had om iets nieuws te leren. Het laatste jaar heeft hij de tijd gekregen om het product waar hij al jaren lang aan werkte goed te documenteren en klaar te stomen voor overdracht. Eigenlijk onzin aangezien het product toch binnenkort wordt vervangen, maar het hield hem bezig. Maargoed, het aantal regels codes is wel met 30% afgenomen het laatste jaar. En volgens een of andere obscure regel om de complexiteit te meten van software is de complexiteit van het code natuurlijk ook met 30% afgenomen

[Verwijderd]

Olaf van der Spek schreef op maandag 03 oktober 2011 @ 15:19:
[...]

Ligt eraan wat je onder sugar verstaat.

code:

f(a ? 1 : 0, b ? 2 : 0, c ? 4 : 0);

Zonder ? : heb je extra variabelen nodig.

Zo dan?

C++:

f(1 * (bool)a, 2 * (bool)b, 4 * (bool)c);

[MBV]

xos schreef op maandag 03 oktober 2011 @ 17:36:
of

code:

cond1 ? a : b = cond2 ? c : d

Dit soort constructies ontstonden toen een programmeur nog 1 jaar moest voordat hij met pensioen mocht en geen zin had om iets nieuws te leren. Het laatste jaar heeft hij de tijd gekregen om het product waar hij al jaren lang aan werkte goed te documenteren en klaar te stomen voor overdracht. Eigenlijk onzin aangezien het product toch binnenkort wordt vervangen, maar het hield hem bezig. Maargoed, het aantal regels codes is wel met 30% afgenomen het laatste jaar. En volgens een of andere obscure regel om de complexiteit te meten van software is de complexiteit van het code natuurlijk ook met 30% afgenomen

Mijn stelling: er is geen enkele complexiteitsmetric die in alle gevallen een 1-op-1 relatie heeft tussen complexiteit van de code en de output. Mensen vinden altijd bochten om zich in te wringen om die metric omlaag te krijgen zonder de complexiteit omlaag te brengen. Als ze die creativiteit nou eens zouden stoppen in het verminderen van de complexiteit...

_{Over het code-voorbeeldje dat ik gaf, en wat sommige mensen nodig vonden om te nit-picken : ik heb even een explode-functie geschreven om de 'argumenten' uit elkaar te trekken, scheelt 3 regels code en een hoop complexiteit, zeker in de subclass met meer 'argumenten' Ook het stuk van de verwerking van de 'argumenten' te parsen heb ik apart getrokken, zodat een subclass extra argumenten kan accepteren. Regels code per functie is dus ook omlaag.}

[Olaf van der Spek]

Verwijderd schreef op maandag 03 oktober 2011 @ 15:26:
Die variabelen worden weer weggeoptimaliseerd. In jouw voorbeeld moet de compiler net zogoed een waarde op de stack pushen alvorens f() aan te roepen.

Natuurlijk, maar dat zegt toch niks over of het syntactic sugar is?

MBV schreef op maandag 03 oktober 2011 @ 15:44:
@Olaf: als je dat door mij laat reviewen mag je dat er direct weer uithalen, want het is niet leesbaar en geeft bij kleine typfoutjes een compleet ander gedrag.

Hoezo is het niet leesbaar?
Kleine typefoutjes kunnen toch zo vaak een grote invloed hebben?

Verwijderd schreef op maandag 03 oktober 2011 @ 18:35:
[...]

Zo dan?

C++:

f(1 * (bool)a, 2 * (bool)b, 4 * (bool)c);

Grapjas. Die, 1, 2, 4 en 0 waren natuurlijk maar placeholders.

[ Voor 50% gewijzigd door Olaf van der Spek op 03-10-2011 20:05 ]

[Patriot]

Olaf van der Spek schreef op maandag 03 oktober 2011 @ 20:02:
[...]

Natuurlijk, maar dat zegt toch niks over of het syntactic sugar is?

Het zijn twee manieren om hetzelfde te doen, waarbij de ternary operator ervoor zorgt dat het e.e.a. wat compacter en leesbaarder wordt (ook al valt over dat laatste te twisten omdat leesbaarheid iets persoonlijks is). Dus ja, het is syntactische suiker.

EDIT: "Not that there's anything wrong with that..."

[...]

Hoezo is het niet leesbaar?
Kleine typefoutjes kunnen toch zo vaak een grote invloed hebben?

Kleine typo's kunnen inderdaad al snel een grote invloed hebben, dus ben ik met je eens dat dat geen tegenargument zou moeten zijn. Of het leesbaar is hangt denk ik vooral af van de programmeur. Als je het wat vaker gebruikt zal je er geen enkele moeite mee hebben om het te lezen. Als je het zelden gebruikt is het allemaal wat ingewikkelder.

[ Voor 5% gewijzigd door Patriot op 03-10-2011 20:32 ]

[Olaf van der Spek]

Patriot schreef op maandag 03 oktober 2011 @ 20:30:
Dus ja, het is syntactische suiker.

De gegenereerde code is anders (maar semantisch waarschijnlijk equivalent). Dan is het toch geen syntactic sugar meer?

[ Voor 40% gewijzigd door Olaf van der Spek op 03-10-2011 20:44 ]

[Patriot]

Olaf van der Spek schreef op maandag 03 oktober 2011 @ 20:44:
[...]

De gegenereerde code is anders (maar semantisch waarschijnlijk equivalent). Dan is het toch geen syntactic sugar meer?

Jawel, heeft namelijk alles met functionaliteit te maken. Een for-loop is al syntactische suiker omdat het ook met een while loop en wat extra moeite kan.

[Verwijderd]

Een while loop is weer syntaxische suiker omdat je hetzelfde met een if en een GOTO kan doen

[Olaf van der Spek]

Als we zo gaan beginnen dan is elke taal natuurlijk gewoon syntactic sugar voor machinecode.

[Verwijderd]

LINQ is ook syntactic sugar Maar het maakt het leven echt extreem veel handiger

[R4gnax]

Olaf van der Spek schreef op maandag 03 oktober 2011 @ 22:13:
Als we zo gaan beginnen dan is elke taal natuurlijk gewoon syntactic sugar voor machinecode.

En is machine code syntactic sugar voor de set operaties gedefinieerd door een Turing machine ...

Wie biedt om nog lager te gaan?

[.oisyn]

Verwijderd schreef op maandag 03 oktober 2011 @ 14:24:
Ik vroeg me precies hetzelfde af. Een moderne compiler compileert dat toch naar precies dezelfde executable?

En hoe stel je voor hoe een niet-moderne compiler de code genereert in beide gevallen dan?

Olaf van der Spek schreef op maandag 03 oktober 2011 @ 20:44:
[...]

De gegenereerde code is anders

Waarom dan?

[ Voor 21% gewijzigd door .oisyn op 03-10-2011 23:13 ]

[Verwijderd]

Een niet-moderne compiler zal mogelijk niet doorhebben dat de variabelen meteen weer worden weggegooid na het aanroepen van de functie, er zal dus geheugen worden gealloceerd voor de 3 variabelen. Een moderne compiler zou die moeite niet doen en de tussentijdse resultaten gewoon opslaan in een register.

* User heeft overigens nog nooit gekeken wat een compiler nu eigenlijk uitspuugt...

.oisyn schreef op maandag 03 oktober 2011 @ 23:10:
Waarom dan?

I was wondering the same thing.. Als je het nu over een switch statement had, oke. Maar je mag er toch wel vanuitgaan dat if en ? uiteindelijk tot dezelfde machinecode worden vertaald.

[ Voor 40% gewijzigd door Verwijderd op 03-10-2011 23:19 ]

[MBV]

Olaf van der Spek schreef op maandag 03 oktober 2011 @ 20:02:
[...]

Hoezo is het niet leesbaar?
Kleine typefoutjes kunnen toch zo vaak een grote invloed hebben?

Een , en : verwisselen, of met geneste ternary operators een haakje verkeerd zetten, zorgt voor grote verschillen. Een ternary operator per regel vind ik wel genoeg. En ja, kleine dingetjes kunnen ook op andere plaatsen grote gevolgen hebben, zoals haakjes op verkeerde plekken etc, vandaar dat o.a. het bedrijf waar ik werk in de style guide heeft staan om overal haakjes omheen te zetten. Je moet de kans gewoon zo klein mogelijk maken dat jij of je collega het fout doet. Wat ik uiteraard vergeet bij dit stukje:

code:

x = myvar & 0xF00 >> 2;

[...]

Grapjas. Die, 1, 2, 4 en 0 waren natuurlijk maar placeholders.

Als daar iets complexers staat dan de variabelen a, b, en c, dan past de regel niet meer in de breedte op het scherm. Dan kan je beter temp variabelen neerzetten, weet iedereen ook direct wat je bedoelde, als je ze een zinnige naam geeft. Dit is dan weer over the top:

code:

bool UseFastSearch = true;
search(x, y, UseFastSearch);

[RayNbow]

Patriot schreef op maandag 03 oktober 2011 @ 20:30:
[...]


Het zijn twee manieren om hetzelfde te doen, waarbij de ternary operator ervoor zorgt dat het e.e.a. wat compacter en leesbaarder wordt (ook al valt over dat laatste te twisten omdat leesbaarheid iets persoonlijks is). Dus ja, het is syntactische suiker.

Zelf vind ik dat een best (te?) ruime definitie voor syntactische suiker. Ik prefereer de definitie waarbij je op basis van alleen syntax een bepaalde constructie kunt herschrijven naar een andere constructie.

code:

--Haskell:
(a,b)          ~~~>   ((,) a b)
(a,b,c)        ~~~>   ((,,) a b c)


[]             ~~~>   []
[a]            ~~~>   (a : [])
[a,b]          ~~~>   (a : [b])
[a,b,c]        ~~~>   (a : [b,c])
...


do a <- ma     ~~~>   ma >>= \a -> f a
   f a


// C#
from x in xs   ~~~>   xs.Select(x => f(x))
select f(x)

Bovenstaade voorbeeldtransformaties kijken alleen naar de syntax, niet naar de rest van het programma.

[Olaf van der Spek]

.oisyn schreef op maandag 03 oktober 2011 @ 23:10:
Waarom dan?

Zonder optimalisaties in ieder geval. Met optimalisaties is de code hopelijk wel hetzelfde, al denk ik dat dat afhankelijk is van de types. Classes zonder trivial copy constructor en zonder move constructor bijvoorbeeld.

[ Voor 23% gewijzigd door Olaf van der Spek op 04-10-2011 11:08 ]

[Olaf van der Spek]

MBV schreef op maandag 03 oktober 2011 @ 23:42:
Een , en : verwisselen,

Dat levert een compile error op.

of met geneste ternary operators een haakje verkeerd zetten, zorgt voor grote verschillen.

Genest is weer een stap complexer, maar mijn voorbeeld had geen geneste operators.

Een ternary operator per regel vind ik wel genoeg. En ja, kleine dingetjes kunnen ook op andere plaatsen grote gevolgen hebben, zoals haakjes op verkeerde plekken etc, vandaar dat o.a. het bedrijf waar ik werk in de style guide heeft staan om overal haakjes omheen te zetten.

Te veel onnodige haakjes vind ik dan weer minder leesbaar.

Als daar iets complexers staat dan de variabelen a, b, en c, dan past de regel niet meer in de breedte op het scherm.

Werk je met een 80 x 25 terminal?
Dan nog:

code:

f(a ? 1 : 0, 
  b ? 2 : 0, 
  c ? 4 : 0);

[ Voor 4% gewijzigd door Olaf van der Spek op 04-10-2011 11:11 ]

[Wolfos]

Word gek van het hoofdlettergebruik in Unity3D. Classes beginnen 50/50 met een hoofdletter of niet, functions kunnen zoZijn() maar OokZo() en variables hebben soms helemaal geen hoofdletters.

Meestal kom je alleenDit() tegen.

[MBV]

Olaf van der Spek schreef op dinsdag 04 oktober 2011 @ 11:01:
[...]
Te veel onnodige haakjes vind ik dan weer minder leesbaar.

Ik ook, en ik heb er een hekel aan, maar die lompe fout van mezelf toonde het nut wel aan

[...]

Werk je met een 80 x 25 terminal?
Dan nog:

code:

f(a ? 1 : 0, 
  b ? 2 : 0, 
  c ? 4 : 0);

Nee, met Eclipse op een 1280x1024 scherm, ik geloof dat je met een tekstgrootte van 9 punten maar iets van 100 karakters kwijt kan. En de style guide gaat nog altijd uit van 80 tekens, waar ik me niet aan houd als het onduidelijker wordt van line-breaks

[Matis]

Olaf van der Spek schreef op dinsdag 04 oktober 2011 @ 11:01:
Werk je met een 80 x 25 terminal?
Dan nog:

code:

f(a ? 1 : 0, 
  b ? 2 : 0, 
  c ? 4 : 0);

Maak er maar grappen over

Bij ons op de zaak zijn er ontwikkelaars die VI(M) gebruiken, veelal dual-headed, waardoor er maar 80 karakters per lijn op passen.

Gelukkig schrijven onze richtlijnen 128 karakters per regel voor

[MTWZZ]

Matis schreef op dinsdag 04 oktober 2011 @ 22:36:
[...]

Maak er maar grappen over

Bij ons op de zaak zijn er ontwikkelaars die VI(M) gebruiken, veelal dual-headed, waardoor er maar 80 karakters per lijn op passen.

Gelukkig schrijven onze richtlijnen 128 karakters per regel voor

code:

:set wrap

[.oisyn]

Olaf van der Spek schreef op dinsdag 04 oktober 2011 @ 10:58:
[...]

Zonder optimalisaties in ieder geval. Met optimalisaties is de code hopelijk wel hetzelfde, al denk ik dat dat afhankelijk is van de types. Classes zonder trivial copy constructor en zonder move constructor bijvoorbeeld.

Maar dan heb je het specifiek over C++, waar sommige dingen niet eens kunnen zonder ternaire operator.

[MBV]

Dat is de default, bij veel bestanden doe ik juist :set nowrap om nog iets te kunnen lezen... kan je daar trouwens nog iets aan instellen, zoals een speciaal tekentje om de wrap aan te geven?

[Lointje]

code:

public boolean checkBicBankAccount(String inValue) {
        boolean isNotBicBankAccount = !checkNotNullOrEmpty(inValue, BIC_BANK_ACCOUNT);
        if (!isNotBicBankAccount) {
            if (!isBicBankAccount(inValue)) {
                this.add(BusinessErrorType.INVALID_FORMAT, BIC_BANK_ACCOUNT);
            }
        }
        return !isNotBicBankAccount;
    }

Vandaag kwamen we dit tegen op het werk. Je krijgt niet alleen ontzettende hoofdpijn van alle nutteloze negaties die het allemaal veel moeilijker maken dan het is, uiteindelijk is het dan nog fout ook omdat slechts één van de twee controles wordt teruggegeven.

[418O2]

En de naamgeving is ook al zo handig...

Toch wel handig om een boolean method naam met is te beginnen, of niet?

[ Voor 49% gewijzigd door 418O2 op 05-10-2011 12:41 ]

[Phoenix1337]

418O2 schreef op woensdag 05 oktober 2011 @ 12:41:
En de naamgeving is ook al zo handig...

Toch wel handig om een boolean method naam met is te beginnen, of niet?

Niet perse. Bij sommige woorden kan het gewoon niet. Zolang je maar er maar ja of nee op kan antwoorden is het goed toch?

[kenneth]

Juist, meestal is dat is, soms has, heel soms iets anders maar nooit check.

Dat de variabele in de methode wel een goede naam heeft maar de methode zelf niet is een fijn staaltje inconsequente naamgeving ...

[Caelorum]

Phoenix1337 schreef op woensdag 05 oktober 2011 @ 12:59:
[...]Niet perse. Bij sommige woorden kan het gewoon niet. Zolang je maar er maar ja of nee op kan antwoorden is het goed toch?

ah maar waar wordt de account op gechecked in de functie?
Is een functienaam als isBicBankAccountValid of iets dergelijks niet duidelijker?

[Phoenix1337]

Caelorum schreef op woensdag 05 oktober 2011 @ 13:04:
[...]

ah maar waar wordt de account op gechecked in de functie?
Is een functienaam als isBicBankAccountValid of iets dergelijks niet duidelijker?

Dat ben ik met je eens hoor. De naam van de methode is gewoon fout. Alleen hoeft niet elke methode welke een boolean returned te beginnen met is. Zolang je de naam van methode met ja of nee kan beantwoorden, de naam ook nog beschrijft wat er gedaan word en geen 24 kantjes aan tekst is, is het een goede methodenaam.

[ Voor 3% gewijzigd door Phoenix1337 op 05-10-2011 13:11 ]

[Olaf van der Spek]

MBV schreef op dinsdag 04 oktober 2011 @ 20:21:
Nee, met Eclipse op een 1280x1024 scherm, ik geloof dat je met een tekstgrootte van 9 punten maar iets van 100 karakters kwijt kan. En de style guide gaat nog altijd uit van 80 tekens, waar ik me niet aan houd als het onduidelijker wordt van line-breaks

Hmm, met 1920 pixels pasten er bijna 240 tekens op mijn scherm dacht ik.

[Phoenix1337]

Olaf van der Spek schreef op woensdag 05 oktober 2011 @ 13:22:
[...]

Hmm, met 1920 pixels pasten er bijna 240 tekens op mijn scherm dacht ik.

225 bij mij

[MBV]

En wordt het daar leesbaarder van? Je kan dan wel myString.substring(12,15).replace(0,1).toUpper().find(0) neerzetten, en vast nog wel gekker, maar zodra een regel voorbij de 100 tekens gaat raak ik het overzicht kwijt. Het lijkt dan alsof iemand een complexiteitsmetric tevreden probeert te houden

[Gorion3]

Yep, ik vind 80 tekens ook te weinig tegenwoordig, maar echt veel meer dan 120 zijn ze niet (ik gebruik altijd self-describing functienamen, welke soms dus best wel lang kunnen worden)

[Olaf van der Spek]

MBV schreef op woensdag 05 oktober 2011 @ 15:06:
En wordt het daar leesbaarder van? Je kan dan wel myString.substring(12,15).replace(0,1).toUpper().find(0) neerzetten, en vast nog wel gekker, maar zodra een regel voorbij de 100 tekens gaat raak ik het overzicht kwijt. Het lijkt dan alsof iemand een complexiteitsmetric tevreden probeert te houden

Soms. Als je de breedte probeert te minimaliseren, krijg je soms code zoals dit:

C++:

optimizer::ExplainPlan planner(this, 
                               false,
                               false,
                               false,
                               (zero_result_cause ? zero_result_cause : "No tables used"));

IMO is een enkele regel dan veel leesbaarder.

[ Voor 26% gewijzigd door Olaf van der Spek op 05-10-2011 15:44 ]

[Patriot]

RayNbow schreef op dinsdag 04 oktober 2011 @ 06:29:
[...]

Zelf vind ik dat een best (te?) ruime definitie voor syntactische suiker. Ik prefereer de definitie waarbij je op basis van alleen syntax een bepaalde constructie kunt herschrijven naar een andere constructie.

Tsja, wat voor definitie moet je dan hanteren?

Bovenstaade voorbeeldtransformaties kijken alleen naar de syntax, niet naar de rest van het programma.

Dat is een behoorlijk vage definitie, als hij al te begrijpen is. Wat bedoel je in hemelsnaam met kijken naar de syntax ipv de rest van het programma

EDIT:
Also, waarom zou het 'te' ruim kunnen zijn? Dan is het net alsof syntactische iets anders is dan een feitelijke observatie, wat niets zegt over datgene wat het is. Alsof het een waardeoordeel is

[ Voor 14% gewijzigd door Patriot op 06-10-2011 01:17 ]

[.oisyn]

Olaf van der Spek schreef op woensdag 05 oktober 2011 @ 15:41:
[...]

Soms. Als je de breedte probeert te minimaliseren, krijg je soms code zoals dit:

C++:

optimizer::ExplainPlan planner(this, 
                               false,
                               false,
                               false,
                               (zero_result_cause ? zero_result_cause : "No tables used"));

IMO is een enkele regel dan veel leesbaarder.

Ik snap dit soort uitlijning nooit. Als de functie zelf dus vrij lang is staan alle parameters aan de rechterkant van je scherm . Ik gebruik gewoon 1 extra tab.

C++:

optimizer::ExplainPlan planner(
    this, 
    false,
    false,
    false,
    zero_result_cause ? zero_result_cause : "No tables used");

[Jeldert]

Precies, helemaal omdat je met uitlijning nog met spaties zit te klooien, om alles onder de 1e parameter te krijgen...

[Matis]

Muhaha,

ik maakte (eigenlijk geheel onbewust) de volgende expressie

C:

if(8==D)
{
  /* ... */
}

D is een macro voor debuglogging.

[ Voor 13% gewijzigd door Matis op 06-10-2011 14:50 ]

[RayNbow]

Patriot schreef op donderdag 06 oktober 2011 @ 01:15:
[...]


Tsja, wat voor definitie moet je dan hanteren?

EDIT:
Also, waarom zou het 'te' ruim kunnen zijn? Dan is het net alsof syntactische iets anders is dan een feitelijke observatie, wat niets zegt over datgene wat het is. Alsof het een waardeoordeel is

Als we het over syntactische suiker hebben, lijkt me het slim om minstens het woord syntax in de definitie op te nemen.

[...]

Dat is een behoorlijk vage definitie, als hij al te begrijpen is. Wat bedoel je in hemelsnaam met kijken naar de syntax ipv de rest van het programma

Bij het desugaren wordt er louter en alleen gekeken naar de syntax en wordt een syntactische constructie vervangen door een andere syntactische constructie.

[.oisyn]

Syntactische suiker is gewoon een alternatieve schrijfwijze voor iets wat al in de taal zelf op een andere manier te schrijven is ("syntactisch"), maar dan op een leesbaardere manier ("suiker").

Wat dat betreft is de ?: in C++ iig geen suiker - hij is uitgevonden omdat dat de énige manier is om een if-then-else constructie te gebruiken in expressies, en er zijn een aantal plaatsen waar je louter een expressie (en dus geen statement) kunt gebruiken (zoals voor constanten en initializers).

C++:

struct Foo { /* ... */ };

enum Enum
{
    value = sizeof(Foo) > 2 ? 5 : 7;
}

[ Voor 43% gewijzigd door .oisyn op 06-10-2011 18:15 ]

[Remus]

Jeldert schreef op donderdag 06 oktober 2011 @ 14:46:
Precies, helemaal omdat je met uitlijning nog met spaties zit te klooien, om alles onder de 1e parameter te krijgen...

Een beetje IDE doet dat gewoon voor je met de juiste codestyle instellingen. Niks zelf klooien met spaties

[Grijze Vos]

Lointje schreef op woensdag 05 oktober 2011 @ 12:38:
Vandaag kwamen we dit tegen op het werk. Je krijgt niet alleen ontzettende hoofdpijn van alle nutteloze negaties die het allemaal veel moeilijker maken dan het is, uiteindelijk is het dan nog fout ook omdat slechts één van de twee controles wordt teruggegeven.

Ach, jouw variabele namen kloppen tenminste nog. Kwam gister een viewmodel tegen met de boolean property 'isIncludeNotReserve'. Ik heb er uiteindelijk 'FilterReservationsWithDontRemoveFlag' van gemaakt. Ook niet een schoonheidsprijs qua grootte, maar tenminste wel in 1x duidelijk wat het ding doet.

[PiepPiep]

Een mooie die ik tegen kwam op bash.org :

quote: http://bash.org

<atrus> i worked on a project once where somebody named variables defined in various places explicity so on one line of code, it showed up as:
<atrus> function_name($all, $urBase, $rBelong, $toUs);
<atrus> closest i've ever come to manslaughter

[ValHallASW]

Ik had dit eerst in de koffiecorner getikt om mijn frustratie te uiten, maar ik denk dat het toch beter in de categorie 'slecht programmeervoorbeeld' past...

Lieve SF.net, wat zuig je weer hard vandaag.

Ik ben bezig met het overzetten van bugs van sf.net naar JIRA. (yay! JIRA!).

sf.net heeft een export-functionaliteit. Ik weet alleen niet zo goed wat ik er van moet denken.

code:

<field name="summary">...</field>

in plaats van gewoon een

code:

<summary>...</summary>

. Maargoed, ik moet het toch parsen, dus dat is niet zo'n ramp.

Irritanter is de huge brainfuck die ze van encodings gemaakt hebben. De XML is, volgens de header, encoded in ISO-8859-1. Vervolgens zijn niet-ISO-8859-1-tekens als htmlentities opgeslagen. Redelijk.

Totdat je ziet wat ze precies opslaan. "Spellcheck.py – Print title" ( = u'Spellcheck.py \u2013 Print title') wordt namelijk in de exported XML....

code:

<field name="summary">Spellcheck.py â&#8364;&#8220; Print title</field>

..en nee, dat is niet omdat GoT iets geks doet. Er staat daadwerkelijk in de XML &#226;&#8364;&#8220;.... dat is namelijk wat je krijgt als je de – éérst als utf-8 encoded, en vervolgens inleest als windows-1252, en de unicode-entities die je dan krijgt weer wegschrijft in je XML-file.

In pythonspeak:

code:

>>> u"–".encode('utf-8').decode('windows-1252').encode('ascii', 'xmlcharrefreplace')
'–'

EDIT: maar niet alle tekens die je krijgt als je er utf-8 van maakt zijn ook zinnige windows-1252-characters. Wat doe je daarmee? Negeren, en gewoon 1-op-1 overnemen, natuurlijk. Maakt niet uit hoor, kan python ook. Maar toch: WTF?!

spamspamspam: https://github.com/valhallasw/sfjira/blob/master/parser.py ;-)

[ Voor 9% gewijzigd door ValHallASW op 09-10-2011 22:45 ]

[Grijze Vos]

Iemand die probeert onleesbare code overzichtelijk te houden:

C#:

public void SavePayment()
  {
  [.. 10 regels code ..]
  #region
  if( SomeThing )
  {
    [.. 70 regels code ..]
  }
  #endregion
  #region
  else
  {
    [.. 70 regels code ..]
  }
  #endregion

  [.. 60 regels code ..]
}

Opdelen in functies was klaarblijkelijk niet handig genoeg.
Oh, en ik zal maar niet beginnen over het feit dat deze client-server applicatie het opslaan van alle info rondom 1 betaaltransactie niet atomair doet, maar item voor item een webservice aanspreekt. Als die er toevallig halverwege uitklapt heb je mooi een halve transactie in je DB staan. ><

[ Voor 45% gewijzigd door Grijze Vos op 12-10-2011 16:37 ]

[CodeCaster]

Grijze Vos schreef op woensdag 12 oktober 2011 @ 16:35:
Oh, en ik zal maar niet beginnen over het feit dat deze client-server applicatie het opslaan van alle info rondom 1 betaaltransactie niet atomair doet, maar item voor item een webservice aanspreekt. Als die er toevallig halverwege uitklapt heb je mooi een halve transactie in je DB staan. ><

Weet jij dan of die webservice geen commit doet aan het eind van een serie transaties, zij het via een workaround als een soort ready-flag?

[ Voor 59% gewijzigd door CodeCaster op 12-10-2011 16:50 ]

[Grijze Vos]

Nope, zo'n flag zit er niet in.

[YopY]

mbt lange regels: Ik vind het niet eens zo erg, in Objective-C met XCode en line wrapping. Bakkesen als dit... wil ik liever niet op meerdere regels:

Objective-C:

+(NSAPIRequest *)getDepartureTimesForStationCodeString:(NSString *)code withCallback:(void (^)(NSArray *))callback errorCallback:(void (^)(void))anErrorCallback {
}

Op meerdere regels zou het zoiets worden:

Objective-C:

+(NSAPIRequest *)getDepartureTimesForStationCodeString:(NSString *)code
    withCallback:(void (^)(NSArray *))callback
    errorCallback:(void (^)(void))anErrorCallback {
}

...ok misschien zo erg nog niet .

[Davio]

Ik heb Obj-C sowieso altijd erg onleesbaar gevonden...

[alex3305]

YopY schreef op donderdag 13 oktober 2011 @ 09:56:
mbt lange regels: Ik vind het niet eens zo erg, in Objective-C met XCode en line wrapping. Bakkesen als dit... wil ik liever niet op meerdere regels:

Objective-C:

+(NSAPIRequest *)getDepartureTimesForStationCodeString:(NSString *)code withCallback:(void (^)(NSArray *))callback errorCallback:(void (^)(void))anErrorCallback {
}

Op meerdere regels zou het zoiets worden:

Objective-C:

+(NSAPIRequest *)getDepartureTimesForStationCodeString:(NSString *)code
    withCallback:(void (^)(NSArray *))callback
    errorCallback:(void (^)(void))anErrorCallback {
}

...ok misschien zo erg nog niet .

Volgens mij worden de : altijd onder elkaar gezet over meerdere regels en zou je zoiets krijgen:

Objective-C:

+(NSAPIRequest *)getDepartureTimesForStationCodeString:(NSString *)code
                                          withCallback:(void (^)(NSArray *))callback
                                         errorCallback:(void (^)(void))anErrorCallback { ... }

Wat ik nog niet eens zo extreem onleesbaar vind. Overloads werken IMHO zo ook best mooi. Alleen moest ik er in het begin gruwelijk aan wennen.

[Otherside1982]

Obj-C levert wel mooi ASCII-art op als je alle letters weglaat:

code:

+( *):( *)
    :( (^)( *))
    :( (^)()) {
}

Ik zie wel niet meteen of het nu een konijntje, of een beertje moet voorstellen

[Solopher]

Hmmm, er is een nieuwe view gemaakt waarbij de succesmeldingen in een andere div worden geladen.

Waarom zou het nu niet meer werken?

PHP:

if ($data['errors'] == '<div id="succeed">Het formulier is verstuurd</div>'){
    // doe iets
}

Sowieso is het al "vreemd" om een succesbericht in een error array te zetten .

[Styxxy]

Ik heb net volgende code gezien in de broncode van een website (vraag me niet wat ik daar zit te neuzen ):

JavaScript:

<script type='text/javascript'>
    //<[!CDATA[
        jsDebug = 0; /* Must come before JS includes */
        USE_RTE = 1;
        DISABLE_AJAX = parseInt(0); /* Disables ajax requests where text is sent to the DB; helpful for charset issues */
        inACP   = false;
    //]]>
</script>

En dan voornamelijk die parseInt(0), lol .

[Alex)]

Gisteren 'even' een classfile opgeschoond. Van 3500 regels naar 250

Vreselijk, mensen die ipv source control hun source files als versiegeschiedenis gebruiken

[CodeCaster]

Nog erger: mensen die wel source control gebruiken, maar massa's dode code (functies die nooit meer worden aangeroepen) en uitgecommentariseerde code laten staan.

Code weggooien is niet eng...

[Aloys]

CodeCaster schreef op zaterdag 15 oktober 2011 @ 21:14:
Code weggooien is niet eng...

Niet als je version control gebruikt nee, maar dan vraag ik mij af of ze wel hebben begrepen wat ze nou eigenlijk doen met version control .

[ValHallASW]

ValHallASW schreef op zondag 09 oktober 2011 @ 22:17:
In pythonspeak:

code:

>>> u"–".encode('utf-8').decode('windows-1252').encode('ascii', 'xmlcharrefreplace')
'–'

Nuja, het blijkt iets subtieler te zijn. Er zijn drie entiteiten: de site, een binary storage en de xml-export.

De situatie N jaar geleden was dat er nergens een encoding was gedefineerd. De binary data die door de browser werd opgestuurd werd gewoon 1-op-1 in de binary storage geperst. Dat was dus, afhankelijk van de browser, latin-1 of windows-1252

Dat is inmiddels anders: er wordt tegen de browser gezegd dat alles utf-8 is - ook als dat eigenlijk niet zo is - de data uit de storage wordt nog steeds 1-op-1 doorgegeven. Maar: de browser zal data nu als utf-8 sturen, die wordt zonder het te bekijken opgeslagen en zo teruggegeven.

Maar: de XML exporter kan dat niet. Immers, om xmlcharrefs weg te kunnen schrijven moet je weten met welke unicode characters je te maken hebt. Om een onduidelijke reden heeft iemand er voor gekozen daar windows-1252 voor te gebruiken.

Uiteindelijk is de XML output dus gewoon een representatie van hun binary storage, en het is aan de ontvanger om uit te zoeken wat de daadwerkelijke encoding is (bv door het als utf-8 in te lezen met een fallback naar latin-1/windows-1252, wat een redelijk gangbare techniek is). Toch lichtelijk irritant dat ze dat niet even gedocumenteerd hebben (en dat ze windows-1252 hebben gebruikt ipv latin-1, want in dat laatste geval was het een stuk herkenbaarder geweest).

[Alex)]

CodeCaster schreef op zaterdag 15 oktober 2011 @ 21:14:
Nog erger: mensen die wel source control gebruiken, maar massa's dode code (functies die nooit meer worden aangeroepen) en uitgecommentariseerde code laten staan.

Code weggooien is niet eng...

Helemaal mee eens, ik kan daar ook niet tegen. Vooral als het allemaal public is enzo.

Ik heb nu nog een class library waarvan 90% van de methods (stuk of 100) niet meer wordt gebruikt, en ik wil deze weggooien. Kan ik dat ook met tooling laten doen? R# kan een safe delete doen, maar dat is op member-niveau, of op class-niveau, maar niet 'voor alle members van een class'

[Verwijderd]

C#:

[Obsolete()]

Toevoegen aan de methode lost al heel snel het probleem op (je krijgt een warning per aanroep van de method)

Dus bv

C#:

[Obsolete()]
public void OudeMethod()
{
//Doe iets...
}

Daarna ga je de warnings af en pas je die aan

[ Voor 35% gewijzigd door Verwijderd op 15-10-2011 22:23 ]

[Alex)]

[Obsolete] is inderdaad een handige, die heb ik al bij een andere class gebruikt. Visual Studio geeft er mooi een warning op. Ik denk dat ik R#'s Safe Delete maar ga gebruiken op iedere method van de class.

[Verwijderd]

Ook kan je "Find All References" gebruiken, wat je hele Solution doorzoekt. Maar ja, dat werkt weer minder voor shared libraries.

[Dwarrelegel]

Samen werken werkt soms niet. Mijn practicum partner probeerde een thread even te laten slapen....
Denk dat de wijn zijn code niet heeft verbeterd.

Java:

// Sleep action
public void sleep(int time){
    this.sleep(time);
}

Dit was nadat hij in een switch case de breaks was vergeten en stond te roepen waarom alle acties altijd werden uitgevoerd.

[Enfer]

Dwarrelegel schreef op zondag 16 oktober 2011 @ 22:37:
Samen werken werkt soms niet. Mijn practicum partner probeerde een thread even te laten slapen....
Denk dat de wijn zijn code niet heeft verbeterd.

Java:

// Sleep action
public void sleep(int time){
    this.sleep(time);
}

Als ie nou een beeetje slim was had ie het volgende geproduceerd

Java:

// Sleep action
public void sleep(int time){
        if( time > 0 )
           this.sleep(--time);
}

Dan heb je nog een klein beetje een sleep functie gemaakt

[Jegorex]

Enfer schreef op dinsdag 18 oktober 2011 @ 08:35:
[...]


Als ie nou een beeetje slim was had ie het volgende geproduceerd

Java:

// Sleep action
public void sleep(int time){
        if( time > 0 )
           this.sleep(--time);
}

Dan heb je nog een klein beetje een sleep functie gemaakt

Gelukkig staat er nergens beschreven dat time in milliseconds is.
En je zult nog even moeten aangeven dat je de stack moet vergroten als je langer wilt wachten

[Enfer]

Eentje uit eigen hand, dat moet toch echt andersom als je thread safe wilt zijn

C:

if( object == nil ){
    @synchronized( self ){
        object = [[NSObject alloc] init];
    }
}

[ Voor 26% gewijzigd door Enfer op 18-10-2011 15:41 ]

[CoolGamer]

Wat je regelmatig ook ziet zijn constructies als:

C:

if( object == nil ){
    @synchronized( self ){
        if( object == nil ){
            object = [[NSObject alloc] init];
        }
    }
}

Zo is het in de meeste gevallen niet nodig om te locken.

[.oisyn]

Wat ook alleen maar goed gaat als memory synchronization rules duidelijk zijn gedefinieerd. In C is dat iig niet het geval, wellicht in Objective-C wel?

[Remus]

CoolGamer schreef op dinsdag 18 oktober 2011 @ 15:45:
Wat je regelmatig ook ziet zijn constructies als:

C:

if( object == nil ){
    @synchronized( self ){
        if( object == nil ){
            object = [[NSObject alloc] init];
        }
    }
}

Zo is het in de meeste gevallen niet nodig om te locken.

Ligt heel erg aan de taal, in oudere versies van Java (1.4 en eerder) is het bijvoorbeeld niet zo safe als jij denkt: http://en.wikipedia.org/wiki/Double-checked_locking

[.oisyn]

Ja dat zeg ik toch net . De vraag is of je de garantie hebt dat er pas naar object wordt geschreven nadat alle side-effects van [[NSObject alloc] init] helemaal zijn afgerond. En dan kun je wel denken: "duh, het is een functie die wordt aangeroepen, die is al klaar als ie returnt", maar het staat de compiler vrij om alle operaties die gedaan moeten worden te herordenen.

Moderne C en C++ compilers hebben als regel dat een write naar een volatile release semantics heeft, en een read van een volatile acquire semantics. Dat houdt in dat iig alle writes voor de write naar de volatile gegarandeerd zijn afgerond, en alle reads die je doet na een volatile read pas daadwerkelijk plaatsvinden ná die volatile read. In C++-11 is dit opgenomen in de standaard, C loopt wat dat betreft nog wat achter. Hoe het met Objective-C implementaties zit weet ik niet.

[ Voor 37% gewijzigd door .oisyn op 19-10-2011 10:55 ]

[Jegorex]

Remus schreef op woensdag 19 oktober 2011 @ 09:40:
[...]

Ligt heel erg aan de taal, in oudere versies van Java (1.4 en eerder) is het bijvoorbeeld niet zo safe als jij denkt: http://en.wikipedia.org/wiki/Double-checked_locking

Ik dacht altijd dat Java(6) alles gegarandeerd in het geheugen zette als je een synchronized block verliet
Volgens die link moet ik dus alsnog volatile gebruiken.

[ Voor 6% gewijzigd door Jegorex op 19-10-2011 15:11 ]

[ctrlaltdelbe]

Deze hoort wel thuis in het topic: signs that you are a bad programmer

[.oisyn]

Jegorex schreef op woensdag 19 oktober 2011 @ 15:08:
[...]

Ik dacht altijd dat Java(6) alles gegarandeerd in het geheugen zette als je een synchronized block verliet

Klopt, doet het ook.

Volgens die link moet ik dus alsnog volatile gebruiken.

Klopt ook. Het enige dat Java garandeert is dat alle writes voor het einde van het synchronized block zijn gedaan. Wat het niet garandeert is in welke volgorde die writes plaatsvinden. De referentie naar het object kan al geschreven worden voordat de constructor er daadwerkelijk mee klaar is. Een andere thread kan dus theoretisch een half geconstruct object zien. De volatile zorgt ervoor dat alle writes voor de volatile write (en dus alle sideeffects van de ctor) gedaan zijn.

Daarnaast wil je ook dat de read volatile is, omdat je anders een gecachede kopie kunt krijgen die wellicht nog null is, waardoor je 2x het object construct. Wel zou je zoiets kunnen doen:

Java:

class Singleton
{
    private volatile Singleton myObj;
    private Singleton myFastObj;
    private final Object sync = new Object();

    public static Singleton getInstance()
    {
        if (myFastObj == null)
        {
            synchronized(sync)
            {
                if (myObj == null)
                    myObj = new Singleton();
            }
            myFastObj = myObj;
        }
        return myFastObj;
    }

    private Singleton() { /* ... */ }
}

[Dwarrelegel]

C++:

 for(size_t idx = 0 ; idx < 3 ; i++)
  {
    angle[idx] = atoi(d_string);
    pos = d_string.find_first_of(" :");
    if(angle[idx] == 0 || pos == string::npos)
    {
      return false;
    }
    d_string = d_string.substr(pos + 1);
  }

Nog een mooie .....

[.oisyn]

Dat behoeft iets meer uitleg. Ik zie een nutteloze substring constructie elke keer, maar dat noem ik nou niet echt een slecht programmeervoorbeeld.

[Montaldo]

Typo. De iterator idx wordt niet opgehoogd, maar i.

[YopY]

Montaldo schreef op donderdag 20 oktober 2011 @ 01:43:
Typo. De iterator idx wordt niet opgehoogd, maar i.

Dat zou een compilerfout moeten opleveren, daar i niet in de scope staat (voor zover ik kan zien).

En als dit slechts een onderdeel is van een grotere method: doe eens een Extract Method, .

[Remus]

Jegorex schreef op woensdag 19 oktober 2011 @ 15:08:
[...]

Ik dacht altijd dat Java(6) alles gegarandeerd in het geheugen zette als je een synchronized block verliet
Volgens die link moet ik dus alsnog volatile gebruiken.

Ja, maar dat wil niet zeggen dat andere threads die unsynchronised dezelfde variabele lezen dan ook de juiste waarde uit de heap gebruiken of uit de lokale L1 t/m L3 cache of een register. In dat geval kunnen ze dus bijvoorbeeld nog null zien in de eerste if(). Volatile zorgt ervoor dat de wijziging ook unsynchronised zichbaar is voor de andere threads.

[.oisyn]

Dat is een van de punten die ik daarnet al noemde ja, en dan vergeet je even het andere punt, dat de write naar de variabele niet per se plaatsvindt ná het runnen van de ctor. De VM kan instructies herordenen, en de CPU kan memory access intern ook nog eens herordenen. Alleen een compiler barrier is dus niet afdoende, een speciale memory barrier instructie is ook nog eens van belang (maar dan weer niet op x86 CPU's, want die herordenen geen memory access, maar da's een implementatiedetail waar je je als Java programmeur niet mee bezig hoeft te houden)

[ Voor 71% gewijzigd door .oisyn op 20-10-2011 12:10 ]

[Michali]

Nikolas schreef op woensdag 19 oktober 2011 @ 23:18:
Deze hoort wel thuis in het topic: signs that you are a bad programmer

Pinball Programming

One Try-Catch block wrapping the entire body of Main() and resetting the program in the Catch clause (the pinball gutter)

Schitterend

[tiesmaster]

Aloys schreef op zaterdag 15 oktober 2011 @ 21:19:
[...]

Niet als je version control gebruikt nee, maar dan vraag ik mij af of ze wel hebben begrepen wat ze nou eigenlijk doen met version control .

Dat is inderdaad wat ik ook heel veel zie, de echte kracht van scm wordt heel vaak nauwelijks gebruikt. Het wordt dan alleen gebruikt om de laatste versie van een source tree te hebben, dus eigenlijk gewoon een synchronisatie tooltje. De functionaliteit van het leveren van documentatie en historie is vaak onbekend terrein. Vaak krijg ik de vraag, "hoe kan dit nou?" en als je dan in de geschiedenis kijkt dan zie je binnen enkele tellen waarom iets zo is, of wie verantwoordelijk is geweest.

[alex3305]

Michali schreef op donderdag 20 oktober 2011 @ 17:26:
[...]

[...]

Schitterend

Laatst gebruikt bij een Android programma welke, als deze crashte, automatisch voor de klant opnieuw opgestart diende te worden. Was dus een programma op een dedicated telefoon. Dus het kan wel degelijk nut hebben ,

Overigens hadden we het alleen nodig voor het verwerken van Bitmaps in Android, dat is namelijk een draak, aangezien die niet automatisch gerecycled worden . Erg irritant in een managed omgeving.

[YopY]

Uiteindelijk is een zichzelf opnieuw startende applicatie niet eens zo'n gek idee, zeker niet in de grotere / geclusterde omgevingen. Ja, je wilt liever software schrijven die gewoon niet kan crashen, maar zoals Alex al aangeeft, soms heb je daar gewoon geen invloed over.

Zeker als het lichtgewicht software is moet dat niet een al te groot drama zijn. Je kunt bijv. een viertal NodeJS processen op een server met een loadbalancer ervoor draaien (allemaal op dezelfde machine) (NodeJS is singlethreaded, vier processen kunnen een quadcore beter gebruiken), die elk door een programma als Supervisor of één van de twintig alternatieven opnieuw opgestart worden indien er toch iets stuq gaat.

[smeetsmeister]

Ik ben van de week toch wel een erg puntje tegengekomen. Er was een website die door een voorganger was gemaakt. Hij had bij een else (als je niet ingelogd was op een pagina om dingen te bewerken) een echo staan: 'Rot op kut mongool'. Niet zo slim natuurlijk, maar je kunt mijn verbaasde hoofd voorstellen toen deze klant me opbelde dat hij niet tevreden was met wat er in z'n site stond.

[RomeoJ]

Sowieso niet slim om dat soort teksten te gebruiken, ook niet om even snel iets te testen.

Collega van mij had een keer snel wat linkjes aangemaakt op een website met xxx als href, bij het testen kwamen er een aantal personen op de blacklist van onze proxy, omdat ze die linkjes aangeklikt hadden.
Toen mochten deze personen bij hun leidinggevenden uit gaan leggen waarom ze een pornografische site wilden bekijken

[YopY]

Jeuj bugfixxen. Eerste bug gefixed:

C:

+(BOOL)ShowHSL {
    return [[NSUserDefaults standardUserDefaults] boolForKey:@"yearly_subscription_preference"];
}

+(BOOL)YearlySubscription {
    return [[NSUserDefaults standardUserDefaults] boolForKey:@"hsl_preference"];
}

[urk_forever]

Ik kom net deze tegen:

C#:

int volgNummer = 1;
//Doe iets met volgnummer
string foo = string.Format("{0}", volgNummer.ToString());

[Noxious]

urk_forever schreef op vrijdag 21 oktober 2011 @ 11:58:
Ik kom net deze tegen:

C#:

int volgNummer = 1;
//Doe iets met volgnummer
string foo = string.Format("{0}", volgNummer.ToString());

Whut

[Verwijderd]

urk_forever schreef op vrijdag 21 oktober 2011 @ 11:58:
Ik kom net deze tegen:

C#:

int volgNummer = 1;
//Doe iets met volgnummer
string foo = string.Format("{0}", volgNummer.ToString());

Die valt toch wel mee? Hij lijkt misschien nogal stom, maar:

Wie zegt dat het volgnummer altijd een integer zal zijn of is geweest? (Dat blijkt niet uit de code zo). Volgens mij is iets dergelijks een paar pagina's geleden ookal voorbij gekomen... Dit is eerder een gebrek aan documentatie dan een slecht voorbeeld van programmeren.

Er zitten wel paar kleine dingetjes in: "ToString()" is natuurlijk niet nodig en eigenlijk (heel puristisch gezien) zou je ook de Culture moeten opgeven bij de format.

[.oisyn]

Er zitten wel paar kleine dingetjes in: "ToString()" is natuurlijk niet nodig

Het hele punt is dat een string.Format("{0}", x.ToString()) hetzelfde is als gewoon x.ToString()

[ Voor 3% gewijzigd door .oisyn op 21-10-2011 13:02 ]

[Verwijderd]

Deze week voor de zoveelste keer van een aanleverende partij een XSD-schema gehad voor de XML die zij gaan aanleveren. Op zich hartstikke mooi natuurlijk, kunnen wij fijn de XML valideren bij binnenkomst . Beetje jammer dat de aanleverende partij de XSD zelf niet gebruikt en hij dus vol met fouten stond . En helaas lijkt dat tegenwoordig meer regel dan uitzondering te zijn...

[Verwijderd]

.oisyn schreef op vrijdag 21 oktober 2011 @ 12:47:
[...]

Het hele punt is dat een Format("{0}", x.ToString()) doorgaans hetzelfde is als gewoon x.ToString()

Klopt, maar wie zegt dat het volgnummer niet uit meerdere parameters heeft kunnen bestaan of moeten bestaan? Verder maakt string.Format of .ToString() weinig uit inderdaad, zolang je het maar consequent doet. Format geeft je echter wel meer mogelijkheden.

[.oisyn]

Verwijderd schreef op vrijdag 21 oktober 2011 @ 12:50:
[...]


Klopt, maar wie zegt dat het volgnummer niet uit meerdere parameters heeft kunnen bestaan of moeten bestaan?

Hoe is dat relevant dan?

Format geeft je echter wel meer mogelijkheden.

Maar die worden niet gebruikt.

[ Voor 14% gewijzigd door .oisyn op 21-10-2011 13:03 ]

[Verwijderd]

.oisyn schreef op vrijdag 21 oktober 2011 @ 13:00:
[...]

Hoe is dat relevant dan?

[...]

Maar die worden niet gebruikt.

Ik zeg alleen dat het helemaal niet zo'n raar slecht voorbeeld is als je er een seconde langer over nadenkt. Dat de schrijver het wat makkelijker had kunnen refactoren omdat het eenvoudig was dan hij van te voren had bedacht (Want dat mag je wel hieruit opmaken naar mijn mening), ja dat klopt.

Maar er zijn in dit geval legio (legacy/extensibility) redenen te vinden en te bedenken waarom men hiervoor heeft gekozen. En laten we eerlijk zijn, dan is dit helemaal niet zo raar of slecht.... Hooguit wat ongelukkig...

[ Voor 17% gewijzigd door Verwijderd op 21-10-2011 13:15 ]

[.oisyn]

Verwijderd schreef op vrijdag 21 oktober 2011 @ 13:10:
[...]


Ik zeg alleen dat het helemaal niet zo'n raar slecht voorbeeld is als je er een seconde langer over nadenkt.

Nee, je zei dat volgnummer wellicht wel meer was dan een int. Waarom is dát relevant? Dat er op de plek van de Format wellicht eerst wat anders stond is wel relevant, maar op die manier kun je 99% van de geposte voorbeelden wel naar de prullenbak verwijzen. Bottom line is, de code zoals ie er nu staat, dus een format van een string (en dus geen ander object!) als "{0}", is een beetje suf.

[Verwijderd]

.oisyn schreef op vrijdag 21 oktober 2011 @ 13:24:
[...]

Nee, je zei dat volgnummer wellicht wel meer was dan een int. Waarom is dát relevant? Dat er op de plek van de Format wellicht eerst wat anders stond is wel relevant, maar op die manier kun je 99% van de geposte voorbeelden wel naar de prullenbak verwijzen. Bottom line is, de code zoals ie er nu staat, dus een format van een string (en dus geen object!) als "{0}", is een beetje suf.

Ok, als je dat volgnummer zo had geinterpreteerd dan heb je daarin gelijk. Alhoewel ik niet op het volgnummer doelde. Tweede zijn we het overeens .

[SPee]

Zelfs als was het "vroeger" anders, dan nog zou zoiets niet mogen.
De ontwikkelaar die het zo heeft aangepast, heeft dan er een andere betekenis aan gegeven.
Wat zijn grote fout is geweest, is dat hij niet goed of onvoldoende de code heeft gerefactored, maar "lekker makkelijk" alleen de kleine aanpassingen heeft gedaan. Ook een hele goede manier om spaghetti-code te maken.

regel: ALS JE REFACTORED, MOET JE HET GOED DOEN!

[Grijze Vos]

Nu we het toch over refactoren hebben. Iemand enig idee hoe je je collega's dat kan aanleren?