[alg] Slechtste programmeervoorbeelden deel 5

[Janoz]

Oh, en nu ik toch bezig was @CurlyMo

Java:

    LocalDate nu = LocalDate.of(2019,6,1);

    LocalDate olderThan18 = LocalDate.of(nu.getYear()-19,12,31);

    private boolean isDitEenKind(LocalDate geboortedatum) {
        return geboortedatum.isAfter(olderThan18);
    }

    private int leeftijd(LocalDate geboorteDatum) {
        return Period.between(geboorteDatum,nu).getYears();
    }

    private void printPersoon(String naam, LocalDate geboorteDatum) {
        System.out.println(String.format("%s is %s jaar oud.", naam, leeftijd(geboorteDatum)));
        System.out.println(String.format("%s is %s een kind.", naam, isDitEenKind(geboorteDatum)?"wel":"niet"));

    }

    @Test
    public void testPersonen() {
        printPersoon("Jan", LocalDate.of(2001,1,1));
        printPersoon("Piet", LocalDate.of(2001,7,1));
        printPersoon("Klaas", LocalDate.of(2000,12,31));
    }

Output:

Jan is 18 jaar oud.
Jan is wel een kind.
Piet is 17 jaar oud.
Piet is wel een kind.
Klaas is 18 jaar oud.
Klaas is niet een kind.


En dat sluit weer precies aan bij het kalenderjaar verhaal

[Matis]

Merethil schreef op vrijdag 15 november 2019 @ 10:58:
Dat is toch gewoon verwacht gedrag? Je telt er een maand bij op, dus ga je naar 31-02-2019, wat niet bestaat en dus overflowt hij. Wat had je zelf verwacht dat 'ie zou doen dan?

Het is meer dat ik er, toen ik er voor het eerst tegenaan liep, geen verklaring voor had. Als je het fenomeen zoals jij het nu omschrijft uitlegt snap ik het wel.
Maar als je medio juni een stukje code schrijft en het jaar er op gaat het fout, dan moet je toch wel weer even graven.

Voor nu zit deze werking altijd in mijn hoofd geprent.

[CurlyMo]

Janoz schreef op vrijdag 15 november 2019 @ 11:23:
Oh, en nu ik toch bezig was @CurlyMo

En dat sluit weer precies aan bij het kalenderjaar verhaal

Maar ik heb @Haan helemaal niet zien refereren aan kalenderjaar, @JeroenE inderdaad wel.

Ik heb het zelf ook even gedaan in PostgreSQL:

SQL:

select
    max(h),
    min(g),
    max(g)
from
    (select
        a.a > (extract('YEAR' from now()) - 19 || '-12-31')::date as a,
        extract('year' from age(now()::date, a.a)) as f,
        a.a as g,
        now()::date as h
    from
        (select
            generate_series('2001-01-01', '2002-01-01', interval '1 day')::date as a
        ) as a
    ) as a
where
    f != 18
and
    a is true

Output:

code:

2019-11-15     2001-11-16     2002-01-01

Dus op de huidige datum van 15 november 2019 wordt iedereen tussen 16 november 2001 en 1 januari 2002 geboren onterecht als 18 aangemerkt.

Als je voorwaarde is dat je selecteert op het jaar waarin iemand 18 wordt dan gaat het inderdaad wel prima. Maar dan zou ik van beide datums het jaar extraheren en die met elkaar vergelijken. Dan ziet iedereen dat je alleen geïnteresseerd bent in het kalenderjaar en dat de dag en maand geen enkele rol spelen.

[Janoz]

CurlyMo schreef op vrijdag 15 november 2019 @ 11:44:

Maar ik heb @Haan helemaal niet zien refereren aan kalenderjaar, @JeroenE inderdaad wel.

Daarom verwees ik ook naar Jeroen, en niet naar Haan ;):

Janoz schreef op donderdag 14 november 2019 @ 16:16:
Mwah, lees het stukje van @JeroenE nog even een keertje .

Als je voorwaarde is dat je selecteert op het jaar waarin iemand 18 wordt dan gaat het inderdaad wel prima. Maar dan zou ik van beide datums het jaar extraheren en die met elkaar vergelijken. Dan ziet iedereen dat je alleen geïnteresseerd bent in het kalenderjaar en dat de dag en maand geen enkele rol spelen.

Oh, maar ik denk dat we het er allemaal wel over eens zijn dat de code waar Haan mee aankwam slechte naamgeving, slechte documentatie en een slechte implementatie heeft.

[ Voor 22% gewijzigd door Janoz op 15-11-2019 11:56 ]

[Merethil]

Janoz schreef op vrijdag 15 november 2019 @ 11:09:
[...]

Nope

Java:

    public void telMaandOp() {
        LocalDate datum = LocalDate.of(2020,1,31);
        System.out.println(datum.plusMonths(1));
    }

output:

2020-02-29


--edit--
Oh, en nu ik toch bezig ben, dit is dan wel weer grappig:

Java:

    @Test
    public void telMaandOp() {
        LocalDate datum = LocalDate.of(2020,1,31);
        System.out.println(datum.plusMonths(1));
        System.out.println(datum.plusMonths(2));
        System.out.println(datum.plusMonths(1).plusMonths(1));
    }

Output:
2020-02-29
2020-03-31
2020-03-29

Ik zou zweren dat het wel zo was maar blijkbaar niet. Bijzonder. Bedankt voor de rectificatie!

[Janoz]

Merethil schreef op vrijdag 15 november 2019 @ 12:21:
[...]


Ik zou zweren dat het wel zo was maar blijkbaar niet. Bijzonder. Bedankt voor de rectificatie!

In de oude Calendar implementatie werkte het wel zo, maar dat was zo'n draak om mee te werken dat iedereen al snel voor JodaTime koos. Wel jammer dat het nogal lang heeft moeten duren voor er wat fatsoenlijks in Java zelf kwam.

Java:

    @Test
    public void telMaandOpOud() {
        Calendar datum = new GregorianCalendar(2020, 1, 31);
        datum.add(Calendar.MONTH,1);
        System.out.println(datum.get(Calendar.YEAR) + "-" + datum.get(Calendar.MONTH) + "-" + datum.get(Calendar.DAY_OF_MONTH));
    }

geeft:
2020-3-2

[Tjolk]

En daarom zijn datums dus niet zo gemakkelijk als mensen wel eens denken.

Er staat bij ons al een tijd lang een ticket open vanwege precies dat. De essentie van de vraag is in hoeverre het resultaat afwijkt van verwacht gedrag. Immers: 31 januari + 1 maand kan niet leiden tot 31 februari omdat dit geen bestaande datum is. Eigenlijk moet er dan een arbitraire keuze gemaakt worden:
1. Tel je 3 dagen bij 28 februari op (PHP doet met de geclaimde implementatie van ISO 8601)
2. Ga je uit van 'de laatste dag van de maand' (leidt tot wisselende datums)
3. Laat je maanden met minder dan 31 dagen achterwege (wat ongetwijfeld ook bezwaren oplevert)

En bij optie 1 kun je je dan ook weer afvragen of je bij een repeterende interval moet kiezen voor:
31 januari
3 maart
3 april

of
31 januari
3 maart
31 maart

Eigenlijk doe je het altijd voor een aanzienlijk deel van de gebruikers fout.

't is net alsof je het over friet of patat hebt

[Merethil]

Janoz schreef op vrijdag 15 november 2019 @ 13:03:
[...]


In de oude Calendar implementatie werkte het wel zo, maar dat was zo'n draak om mee te werken dat iedereen al snel voor JodaTime koos. Wel jammer dat het nogal lang heeft moeten duren voor er wat fatsoenlijks in Java zelf kwam.

Java:

    @Test
    public void telMaandOpOud() {
        Calendar datum = new GregorianCalendar(2020, 1, 31);
        datum.add(Calendar.MONTH,1);
        System.out.println(datum.get(Calendar.YEAR) + "-" + datum.get(Calendar.MONTH) + "-" + datum.get(Calendar.DAY_OF_MONTH));
    }

geeft:
2020-3-2

Ik wist dat ik het ergens gezien zou moeten hebben (doe veel Java maar nauwelijks datum/tijd-manipulatie). Bedankt Wel gek dat het nog in mijn hoofd zit, laatste jaren gebruik ik Java 8 dus geen oude calenderzut meer maar blijkbaar dus ook sindsdien geen echte datum/tijd-manipulatie hoeven doen...

[Crazy D]

Tjolk schreef op vrijdag 15 november 2019 @ 14:38:
En daarom zijn datums dus niet zo gemakkelijk als mensen wel eens denken.

Er staat bij ons al een tijd lang een ticket open vanwege precies dat. De essentie van de vraag is in hoeverre het resultaat afwijkt van verwacht gedrag. Immers: 31 januari + 1 maand kan niet leiden tot 31 februari omdat dit geen bestaande datum is. Eigenlijk moet er dan een arbitraire keuze gemaakt worden:
1. Tel je 3 dagen bij 28 februari op (PHP doet met de geclaimde implementatie van ISO 8601)
2. Ga je uit van 'de laatste dag van de maand' (leidt tot wisselende datums)
3. Laat je maanden met minder dan 31 dagen achterwege (wat ongetwijfeld ook bezwaren oplevert)

En bij optie 1 kun je je dan ook weer afvragen of je bij een repeterende interval moet kiezen voor:
31 januari
3 maart
3 april

of
31 januari
3 maart
31 maart

Eigenlijk doe je het altijd voor een aanzienlijk deel van de gebruikers fout.

't is net alsof je het over friet of patat hebt

Plus, is 1 maand optellen bij 31 januari, dan 31 dagen erbij tellen, of 30?

Daarom wordt er best vaak (in ieder geval in het bedrijfsleven) als je het hebt over iets dat maandelijks gebeurt, vaker over de 1e of laatste van de maand, want dan is het altijd simpel: laatste dag van de betreffende maand. Of desnoods "1 week voor de laatste dag van de maand" dan wordt dat dus gewoon 24 januari en 21 februari.

Maar het ei dat bedacht heeft dat niet elke maand even veel dagen heeft, heeft niet echt een vooruitziende blik gehad...

[Vaan Banaan]

^^^ Bovenstaand bericht is goedgekeurd door Asterix en Obelix ^^^

[mcDavid]

Crazy D schreef op vrijdag 15 november 2019 @ 15:14:
[...]

Maar het ei dat bedacht heeft dat niet elke maand even veel dagen heeft, heeft niet echt een vooruitziende blik gehad...

Wat is jouw voorstel dan, om een jaar van (ietsje minder dan) 365,25 dagen in gelijke porties te verdelen?

[Jerrythafast]

Ik heb een beter idee wat redelijk dicht ligt bij wat we nu doen. Afwisselend een jaar met 12 maanden van 30 dagen en een jaar met 12 maanden van 31 dagen. 1x in de 16 jaar we doen we ipv 31 dagen gewoon 30 dagen per maand (dan heb je dus 3 jaar achter elkaar 12x30).

Hiermee behouden we het concept van 12 maanden per jaar, met vertrouwde lengte van 30 of 31 dagen per maand, en met een periodieke gekkigheid om op een gemiddelde van 365,25 dagen per jaar te eindigen. Je kunt bijvoorbeeld de even jaartallen 31 dagen per maand doen, behalve als het jaartal deelbaar is door 16. Lekker makkelijk te programmeren ook.

Dat tezamen met het afschaffen van de zomer/wintertijd maakt dat we in dit topic in ieder geval geen rare datum/tijdmanipulaties meer hoeven te verwachten

[ Voor 11% gewijzigd door Jerrythafast op 17-11-2019 10:53 ]

[ThomasG]

Jerrythafast schreef op zondag 17 november 2019 @ 10:50:

Dat tezamen met het afschaffen van de zomer/wintertijd maakt dat we in dit topic in ieder geval geen rare datum/tijdmanipulaties meer hoeven te verwachten

De meeste willen dan de zomertijd als tijd voor het hele jaar, terwijl de wintertijd juist de normale tijd is. En de wintertijd loopt al 40 minuten voor op wat het werkelijk zou moeten zijn.

[downtime]

Jerrythafast schreef op zondag 17 november 2019 @ 10:50:
Ik heb een beter idee wat redelijk dicht ligt bij wat we nu doen. Afwisselend een jaar met 12 maanden van 30 dagen en een jaar met 12 maanden van 31 dagen. 1x in de 16 jaar we doen we ipv 31 dagen gewoon 30 dagen per maand (dan heb je dus 3 jaar achter elkaar 12x30).

Hiermee behouden we het concept van 12 maanden per jaar, met vertrouwde lengte van 30 of 31 dagen per maand, en met een periodieke gekkigheid om op een gemiddelde van 365,25 dagen per jaar te eindigen. Je kunt bijvoorbeeld de even jaartallen 31 dagen per maand doen, behalve als het jaartal deelbaar is door 16. Lekker makkelijk te programmeren ook.

Dat tezamen met het afschaffen van de zomer/wintertijd maakt dat we in dit topic in ieder geval geen rare datum/tijdmanipulaties meer hoeven te verwachten

Veel te ingewikkeld.

Even out of the box denken: Het probleem met onze kalender is dat die gebaseerd is op twee fenomenen die niet in de pas lopen. Het is alsof je een meter wilt uitdrukken in een heel aantal inches (i.p.v. centimeters) en het dan maar oplost door 40 inches in een meter te stoppen waarbij elke derde meter een schrikkelmeter van 39 inch is. (de realiteit zou nog ingewikkelder zijn)

Bij de kalender speelt dat ook. We proberen een dag, de periode waarin de aarde om zijn as draait, te passen in een ongerelateerde waarde, het astronomische jaar, de periode waarin de aarde om de zon draait (dit komt overeen met de 4 seizoenen). Dat past niet en dus bedenken we daar complexe workarounds voor.
En dan hebben we ook nog de week, die weliswaar uit 7 dagen bestaat, maar geen relatie met maanden en jaren heeft.

De oplossing is dan ook simpel: Definieer een maand als 28 dagen, een jaar als 364 dagen (13 maal 28 dagen), introduceer een extra maand, en accepteer dat de seizoenen op de lange duur uit de pas met het kalenderjaar lopen. Na een paar eeuwen kunnen we in augustus schaatsen.
Daar staat tegenover dat er nu exact 4 weken in een maand passen en 52 weken in een jaar. Elke maand en elk jaar start daardoor ook op dezelfde dag van de week.

Nu nog even een naam voor de extra maand verzinnen.

[.oisyn]

mcDavid schreef op zondag 17 november 2019 @ 10:06:
[...]


Wat is jouw voorstel dan, om een jaar van (ietsje minder dan) 365,25 dagen in gelijke porties te verdelen?

Het is trouwens 365,2425. Daarom hebben hele eeuwen geen schrikkeldag, behalve als het jaartal deelbaar is door 400 .

[mcDavid]

Jerrythafast schreef op zondag 17 november 2019 @ 10:50:
Ik heb een beter idee wat redelijk dicht ligt bij wat we nu doen. Afwisselend een jaar met 12 maanden van 30 dagen en een jaar met 12 maanden van 31 dagen. 1x in de 16 jaar we doen we ipv 31 dagen gewoon 30 dagen per maand (dan heb je dus 3 jaar achter elkaar 12x30).

Hiermee behouden we het concept van 12 maanden per jaar, met vertrouwde lengte van 30 of 31 dagen per maand, en met een periodieke gekkigheid om op een gemiddelde van 365,25 dagen per jaar te eindigen. Je kunt bijvoorbeeld de even jaartallen 31 dagen per maand doen, behalve als het jaartal deelbaar is door 16. Lekker makkelijk te programmeren ook.

Dat tezamen met het afschaffen van de zomer/wintertijd maakt dat we in dit topic in ieder geval geen rare datum/tijdmanipulaties meer hoeven te verwachten

ik zou dan liever 13 maanden van 28 dagen doen. Loopt het ook netjes gelijk met de weken. Doe je bij de jaarwisseling 1 á 2 blanco dagen invoegen om te zorgen dat je in sync blijft lopen met de omlooptijd om de zon. Als je die bedrijfsvrij maakt is heel Nederland in één klap voorstander ook.

[downtime]

mcDavid schreef op zondag 17 november 2019 @ 13:55:
[...]

Doe je bij de jaarwisseling 1 á 2 blanco dagen invoegen om te zorgen dat je in sync blijft lopen met de omlooptijd om de zon.

Waarom? Dat is ooit verzonnen toen de meerderheid van Europa van het land leefde, het hele leven van die mensen draaide om de seizoenen, maar vandaag de dag is dat voor niemand meer belangrijk.
Als je een jaar gewoon 364 dagen maakt zal niemand echt merken dat de seizoenswisselingen niet meer in de pas lopen met het kalenderjaar. Daarvoor gaat het te langzaam.

[mcDavid]

Dat lijkt me juist uitermate onpraktisch. Dan moet er (by design) jaarlijks van alles aangepast worden. Zoals vakantieperiodes, seizoensgebonden werk, lesstof, etc. We mogen dan niet meer "van het land leven", maar de seizoenen zijn toch behoorlijk verweven met vrijwel iedere leven.

[downtime]

mcDavid schreef op zondag 17 november 2019 @ 14:52:
Dat lijkt me juist uitermate onpraktisch. Dan moet er (by design) jaarlijks van alles aangepast worden. Zoals vakantieperiodes, seizoensgebonden werk, lesstof, etc. We mogen dan niet meer "van het land leven", maar de seizoenen zijn toch behoorlijk verweven met vrijwel iedere leven.

Valt wel mee. De eerste jaren gaat het maar om een paar dagen verschil. En daar staan ook voordelen tegenover. Vakantieperiodes vallen nu elk jaar op een iets andere datum, omdat vakanties nu eenmaal altijd van weekend tot weekend lopen, en is soms ook per regio verschillend. Dat kan dan 7 jaar hetzelfde blijven en dan verschuif je het een week. Hetzelfde geldt voor seizoensgebonden werk.

Lesstof aanpassen is triviaal. Dat materiaal wordt toch geregeld herzien en herdrukt. En de eerste paar jaar kan meester of juffrouw zelf wel even vertellen dat het boekje niet meer klopt.

Het raarste is juist die dertiende maand erbij. Opeens zit er een maand tussen Kerst en Nieuwjaar. Of doen we Kerst dan pas aan het einde van de dertiende maand? Het is vooral die extra maand waar mensen aan moeten wennen.

[Jerrythafast]

downtime schreef op zondag 17 november 2019 @ 12:42:
[...]
Nu nog even een naam voor de extra maand verzinnen.

Downtime natuurlijk

mcDavid schreef op zondag 17 november 2019 @ 13:55:
[...]

ik zou dan liever 13 maanden van 28 dagen doen. Loopt het ook netjes gelijk met de weken. Doe je bij de jaarwisseling 1 á 2 blanco dagen invoegen om te zorgen dat je in sync blijft lopen met de omlooptijd om de zon. Als je die bedrijfsvrij maakt is heel Nederland in één klap voorstander ook.

Oké, jullie pleiten beide voor 13x28, zit inderdaad ook wat in. Ik zou wel graag in de pas blijven lopen met de zon, dus dat betekent inderdaad ieder jaar één extra dag en in de schrikkeljaren twee. In eerste instantie vond ik je voorstel om die dagen bedrijfsvrij te maken een goed idee (het werkt dus! je kunt zo de politiek in). Maar toen ging ik nadenken... onze politiek kennende wordt "Nieuwjaarsdag" dan een eenmalige 8ste dag van de week die gewoon aan het weekend wordt geplakt (zaterdag, zondag, Nieuwjaarsdag, maandag). En dan hebben we netto nog steeds geen extra vrije dag gescoord, want Nieuwjaarsdag is nu ook al bedrijfsvrij wanneer het doordeweeks valt

Ik stel trouwens voor om Nieuwjaarsdag en Schrikkeldag aan het einde van het jaar te doen, zodat programmeertechnisch 1 Januari altijd de eerste dag van het jaar is en we van daaruit kunnen doortellen. Wat wordt het leven dan makkelijk

Python:

dagVanHetJaar = 0 # 1 januari
if dagVanHetJaar < 364:
    dagVanDeMaand = dagVanHetJaar % 28 + 1
    maand = maanden[dagVanHetJaar // 28]
    dagVanDeWeek = weekdagen[dagVanHetJaar % 7]
elif dagVanhetJaar == 364:
    dagVanDeWeek = "Nieuwjaarsdag"
elif dagVanHetJaar == 365:
    dagVanDeWeek = "Schrikkeldag"

downtime schreef op zondag 17 november 2019 @ 15:23:
[...]
Het raarste is juist die dertiende maand erbij. Opeens zit er een maand tussen Kerst en Nieuwjaar. Of doen we Kerst dan pas aan het einde van de dertiende maand? Het is vooral die extra maand waar mensen aan moeten wennen.

Als we nog kans willen maken op een witte Kerst moeten we dat gaan vieren op 25 Downtime ipv 25 December...

[ Voor 14% gewijzigd door Jerrythafast op 17-11-2019 15:45 ]

[kenneth]

Hoe perfect het nieuwe systeem ook is, je moet dan werken met een nieuw systeem vanaf datum X en met het oude systeem vóór datum X. En dat opent een nieuw blik met wormen Dit soort problemen: https://stackoverflow.com...s-giving-a-strange-result

De beste oplossing lijkt me om te accepteren dat het ingewikkeld is en blijft, en zo min mogelijk te veranderen.

[downtime]

kenneth schreef op zondag 17 november 2019 @ 16:38:
Hoe perfect het nieuwe systeem ook is, je moet dan werken met een nieuw systeem vanaf datum X en met het oude systeem vóór datum X. En dat opent een nieuw blik met wormen Dit soort problemen: https://stackoverflow.com...s-giving-a-strange-result

De beste oplossing lijkt me om te accepteren dat het ingewikkeld is en blijft, en zo min mogelijk te veranderen.

Je hebt gelijk natuurlijk. Er is nu een standaard, die wereldwijd wordt gebruikt, en we zijn er helemaal op ingesteld. Zelfs delen van de wereld met een eigen kalender hanteren meestal zonder problemen de westerse kalender ernaast.

Maar het blijft ingewikkeld.

[mcDavid]

Jerrythafast schreef op zondag 17 november 2019 @ 15:34:
[...]

Oké, jullie pleiten beide voor 13x28, zit inderdaad ook wat in. Ik zou wel graag in de pas blijven lopen met de zon, dus dat betekent inderdaad ieder jaar één extra dag en in de schrikkeljaren twee. In eerste instantie vond ik je voorstel om die dagen bedrijfsvrij te maken een goed idee (het werkt dus! je kunt zo de politiek in). Maar toen ging ik nadenken... onze politiek kennende wordt "Nieuwjaarsdag" dan een eenmalige 8ste dag van de week die gewoon aan het weekend wordt geplakt (zaterdag, zondag, Nieuwjaarsdag, maandag). En dan hebben we netto nog steeds geen extra vrije dag gescoord, want Nieuwjaarsdag is nu ook al bedrijfsvrij wanneer het doordeweeks valt

Het moet ook weer niet te gek duur worden he 1x in de 4 jaar een extra dag is prima. Dan doen we idd een extra blanco dag aan het einde van het jaar, en oud-en-nieuw vieren we de nacht vóór die dag.

Die 13e maand noemen we natuurlijk mcDavidember, naar de bedenker

kenneth schreef op zondag 17 november 2019 @ 16:38:
Hoe perfect het nieuwe systeem ook is, je moet dan werken met een nieuw systeem vanaf datum X en met het oude systeem vóór datum X. En dat opent een nieuw blik met wormen Dit soort problemen: https://stackoverflow.com...s-giving-a-strange-result

De beste oplossing lijkt me om te accepteren dat het ingewikkeld is en blijft, en zo min mogelijk te veranderen.

Ik vind het juist stom om aan een beslissing uit het verleden vast te blijven houden, terwijl er objectief betere keuzes gemaakt kunnen worden.

Wat dat betreft heb ik nog wel een paar ideeën. Laten we bijvoorbeeld eens ophouden met dat domme decimale getallen stelsel. Octaal rekenen maakt veel meer sense.

[kenneth]

mcDavid schreef op zondag 17 november 2019 @ 20:22:
[...]

Ik vind het juist stom om aan een beslissing uit het verleden vast te blijven houden, terwijl er objectief betere keuzes gemaakt kunnen worden.

Als je de omschakelingsproblemen meerekent en het feit dat je nog altijd terug in de tijd moet rekenen met het oude systeem heb ik mijn ernstige twijfels bij "objectief beter". Je vervangt niets, er komt gewoon iets bij.

Wat dat betreft heb ik nog wel een paar ideeën. Laten we bijvoorbeeld eens ophouden met dat domme decimale getallen stelsel. Octaal rekenen maakt veel meer sense.

De Sumeriërs hadden al ontdekt dat een zestigtallig stelsel de meeste voordelen biedt

[.oisyn]

mcDavid schreef op zondag 17 november 2019 @ 20:22:
Octaal rekenen maakt veel meer sense.

Waarom?

[orf]

mcDavid schreef op zondag 17 november 2019 @ 13:55:
[...]

ik zou dan liever 13 maanden van 28 dagen doen. Loopt het ook netjes gelijk met de weken. Doe je bij de jaarwisseling 1 á 2 blanco dagen invoegen om te zorgen dat je in sync blijft lopen met de omlooptijd om de zon. Als je die bedrijfsvrij maakt is heel Nederland in één klap voorstander ook.

Dit idee: https://infomongo.com/posts/proposal-for-a-saner-calendar

[Reptile209]

mcDavid schreef op zondag 17 november 2019 @ 20:22:

[...]
Ik vind het juist stom om aan een beslissing uit het verleden vast te blijven houden, terwijl er objectief betere keuzes gemaakt kunnen worden.

Wat dat betreft heb ik nog wel een paar ideeën. Laten we bijvoorbeeld eens ophouden met dat domme decimale getallen stelsel. Octaal rekenen maakt veel meer sense.

Recent wat meegekregen van discussies over (zwarte) Piet, 100/130 km/h, zomer/wintertijd, AOW? Dan heb je een idee van hoe bereid men is om tradities te laten varen... En anders moet je vaker buiten komen .

[Crazy D]

mcDavid schreef op zondag 17 november 2019 @ 10:06:
[...]


Wat is jouw voorstel dan, om een jaar van (ietsje minder dan) 365,25 dagen in gelijke porties te verdelen?

Je zou natuurlijk van het concept maanden af kunnen stappen Gewoon dag 1 t/m dag 365. Voorkomt ook meteen gedoe met dag-maand-jaar of maand-dag-jaar datum opmaak en -invoer

[CurlyMo]

Dan blijft de vraag hoeveel er nu eigenlijk mis gaat en in welke proporties als je met 365 dagen rekent, 365,25 of 365,2425? Specifieke toepassingen daargelaten natuurlijk. Rekenen met datums blijft nu eenmaal klote (kuch, DST) dus laten we het gewoon simpel bij 365 houden. Als je rekent met leeftijden valt dat volgens mij sowieso buiten de levensduur van een persoon.

[boe2]

Deze discussie doet me denken aan deze mooie video van Tom Scott

En hij adresseert dan nog niet eens sommige van de dilemma's die hier genoemd worden.

[mcDavid]

orf schreef op zondag 17 november 2019 @ 22:17:
[...]


Dit idee: https://infomongo.com/posts/proposal-for-a-saner-calendar

Ja ongeveer behalve dat 1 januari natuurlijk wel gewoon een maandag is.

wie begint zijn week nou op zondag.

[ThomasG]

.oisyn schreef op zondag 17 november 2019 @ 22:07:
[...]

Waarom?

Het verschil tussen decimaal en octaal is niet zo groot, waardoor het nauwelijks voordeel heeft. Base-12 (of dozenal) is beter dan zowel decimaal als octaal. Bijvoorbeeld omdat het meer delers heeft (2, 3, 4, en 6) terwijl decimaal enkel 2 en 5 heeft en octaal ook enkel 2 en 4.

[CurlyMo]

boe2 schreef op maandag 18 november 2019 @ 09:45:
Deze discussie doet me denken aan deze mooie video van Tom Scott
[YouTube: The Problem with Time & Timezones - Computerphile]
En hij adresseert dan nog niet eens sommige van de dilemma's die hier genoemd worden.

Dan kan de video van CGP grey ook niet ontbreken:

[mcDavid]

ThomasG schreef op maandag 18 november 2019 @ 10:33:
[...]
Het verschil tussen decimaal en octaal is niet zo groot, waardoor het nauwelijks voordeel heeft. Base-12 (of dozenal) is beter dan zowel decimaal als octaal. Bijvoorbeeld omdat het meer delers heeft (2, 3, 4, en 6) terwijl decimaal enkel 2 en 5 heeft en octaal ook enkel 2 en 4.

Het voordeel van 8 is dat het een macht van 2 is, zodat het makkelijker omrekent naar binair, en er prettig breuken mee te maken zijn. Plus je kunt het nog steeds prima op je vingers tellen, moet je alleen je duimen overslaan.

[Janoz]

Als je alleen met je computerbril kijkt snap ik het. Getallen worden alleen op veel meer plekken gebruikt. En dan blijkt dat 12 eigenlijk veel handiger is. Wist je, dat je in een twaaftallig stelsel tot 144 kunt tellen op je handen?

[.oisyn]

ThomasG schreef op maandag 18 november 2019 @ 10:33:
[...]
Het verschil tussen decimaal en octaal is niet zo groot, waardoor het nauwelijks voordeel heeft.

Maar "nauwelijks" betekent nog steeds een klein beetje. Wat is dat voordeel dan? Imho heeft 8 een nadeel tov 10: het heeft maar 1 priemfactor: 2.

mcDavid schreef op maandag 18 november 2019 @ 10:52:
en er prettig breuken mee te maken zijn.

Overal zijn toch prettig breuken mee te maken

[ Voor 22% gewijzigd door .oisyn op 18-11-2019 11:06 ]

[mcDavid]

Janoz schreef op maandag 18 november 2019 @ 10:57:
Als je alleen met je computerbril kijkt snap ik het. Getallen worden alleen op veel meer plekken gebruikt. En dan blijkt dat 12 eigenlijk veel handiger is. Wist je, dat je in een twaaftallig stelsel tot 144 kunt tellen op je handen?

Waar zitten mijn 11e en 12e vinger dan?

[Janoz]

mcDavid schreef op maandag 18 november 2019 @ 11:28:
[...]


Waar zitten mijn 11e en 12e vinger dan?

12 kootjes per hand, en een vrije duim om aan te wijzen waar je gebleven bent met tellen.

[dragonhaertt]

mcDavid schreef op maandag 18 november 2019 @ 11:28:
[...]


Waar zitten mijn 11e en 12e vinger dan?

Binair tellen

[PageFault]

dragonhaertt schreef op maandag 18 november 2019 @ 11:39:
[...]


Binair tellen

Als God gewild had dat we met computers om konden gaan, had Hij ons wel 16 vingers gegeven...

[Brummetje]

PageFault schreef op maandag 18 november 2019 @ 11:41:
[...]


Als God gewild had dat we met computers om konden gaan, had Hij ons wel 16 vingers gegeven...

Om er later achter te komen dat het toch te weinig is en we er 32 64 128 256 etc.. hadden moeten hebben ?

[.oisyn]

PageFault schreef op maandag 18 november 2019 @ 11:41:
[...]


Als God gewild had dat we met computers om konden gaan, had Hij ons wel 16 vingers gegeven...

Hij heeft ons er 10 gegeven zodat we tot 1024 kunnen tellen.

[ThomasG]

.oisyn schreef op maandag 18 november 2019 @ 11:50:
[...]

Hij heeft ons er 10 gegeven zodat we tot 1024 kunnen tellen.

Maar kunnen we ook floating points op onze vingers?

[.oisyn]

ThomasG schreef op maandag 18 november 2019 @ 11:55:
[...]
Maar kunnen we ook floating points op onze vingers?

3 bits exponent + 7 bits mantissa?

[R4gnax]

.oisyn schreef op maandag 18 november 2019 @ 12:02:
[...]

3 bits exponent + 7 bits mantissa?

Damn it! Nu zit ik met het beeld in m'n kop van iemand die het ook nog aan het proberen is ook.
(Hm... hier moet een IT-geek web-comic toch ooit een setje panelen aan gewijd hebben, of niet?)

[Matis]

ThomasG schreef op maandag 18 november 2019 @ 11:55:
Maar kunnen we ook floating points op onze vingers?

Een aantal mensen die met vuurwerk stuntte wel

[CurlyMo]

Ach ja, de evolutie gaat in sommige families nou eenmaal harder dan bij anderen:

[Xantios]

PageFault schreef op maandag 18 november 2019 @ 11:41:
[...]


Als God gewild had dat we met computers om konden gaan, had Hij ons wel 16 vingers gegeven...

Chernobyl kindjes kunnen dus prima programmeren ?

[Sandor_Clegane]

PageFault schreef op maandag 18 november 2019 @ 11:41:
[...]


Als God gewild had dat we met computers om konden gaan, had Hij ons wel 16 vingers gegeven...

2 is voldoende.

[Matis]

Sandor_Clegane schreef op dinsdag 14 januari 2020 @ 07:14:
2 is voldoende.

Daar is het verplichte plaatje weer

[eagle00789]

Tja. en dan vind je in een codereview de volgende code van een een collega:

code:

if (1==0)
{
    #meer code die juist altijd uitgevoerd dient te worden
}
else
{
    #meer code die nooit uitgevoerd mag worden in deze context
}

[Firesphere]

eagle00789 schreef op dinsdag 14 januari 2020 @ 08:02:
Tja. en dan vind je in een codereview de volgende code van een een collega:

code:

if (1==0)
{
    #meer code die juist altijd uitgevoerd dient te worden
}
else
{
    #meer code die nooit uitgevoerd mag worden in deze context
}

Huh??!! Hoe werkt dat, waarom is die else daar, wtf, huh?

[bwerg]

Beetje (heel) laat, maar toch ben ik benieuwd:

.oisyn schreef op maandag 18 november 2019 @ 11:04:
Imho heeft 8 een nadeel tov 10: het heeft maar 1 priemfactor: 2.

Om een befaamde belg te citeren: wat is daar het praktisch nut van?

eagle00789 schreef op dinsdag 14 januari 2020 @ 08:02:
Tja. en dan vind je in een codereview de volgende code van een een collega:

code:

if (1==0)
{
    #meer code die juist altijd uitgevoerd dient te worden
}
else
{
    #meer code die nooit uitgevoerd mag worden in deze context
}

"Ja misschien hebben we die branch ooit nog nodig dus ik dacht ik laat hem er wel staan?"

[ Voor 43% gewijzigd door bwerg op 14-01-2020 09:56 ]

[Giesber]

Firesphere schreef op dinsdag 14 januari 2020 @ 09:16:
[...]

Huh??!! Hoe werkt dat, waarom is die else daar, wtf, huh?

Ik gok op:
- De andere branch dient om lokaal te testen.
- De andere branch dient in de nabije toekomst geïmplementeerd te worden

Allemaal geldige redenen om daar een if test te hebben, maar geen geldige redenen om die effectief te committen.

[eagle00789]

eagle00789 schreef op dinsdag 14 januari 2020 @ 08:02:
Tja. en dan vind je in een codereview de volgende code van een een collega:

code:

if (1==0)
{
    #meer code die juist altijd uitgevoerd dient te worden
}
else
{
    #meer code die nooit uitgevoerd mag worden in deze context
}

Ik heb de collega gevraagd en hij geeft aan dat het geweest is om iets te testen, echter heeft hij de test nooit terug gedraaid. Heb hem ook gevraag waarom dan de rare if-statement, maar hij kan zelf geen geldige reden meer bedenken waarom hij dat op deze manier gedaan had...
If Else er uit en code opnieuw gecommit met changelog....

[DaCoTa]

Necromancer level 9000

[Twitter: https://twitter.com/jtech63/status/1234600045787394048]

[Postman]

DaCoTa schreef op dinsdag 3 maart 2020 @ 00:04:
Necromancer level 9000

[Twitter]
[Afbeelding]

Zou een erg domme fout zijn als het echt waar is, maar als je de reacties leest op Twitter zie je al dat de hele API er uit ligt en daar dus de problemen daadwerkelijk vandaan komen.

[DaCoTa]

Postman schreef op dinsdag 3 maart 2020 @ 00:53:
[...]

Zou een erg domme fout zijn als het echt waar is, maar als je de reacties leest op Twitter zie je al dat de hele API er uit ligt en daar dus de problemen daadwerkelijk vandaan komen.

API is wellicht down als kill-switch en ze kunnen hier sneller omheen werken als ze het serverside oplossen. Nieuwe versies van apps uitsturen duurt een tijdje.

[WK100]

En hij is sinds een tweetal minuten weer online volgens het Twitteraccount
Daar zal wel meer gebeurd zijn dan het puur vergeten van een functie-implementatie.

[fonsoy]

Tsjongejonge. Ik draai een view via een linked server. En erger me groen en geel aan het feit dat 100 regels ophalen wel 5 minuten duurt. Bedrijf waar ik werk staat nu niet bekend om state-of-the-art hardware.

Maarja, wat verwacht je, voor elk record een stuk of 16 subselects en CASTS waar het de vraag is of dat echt wel moet. Bizar gewoon

SQL:

use archive
go

SELECT CAST(objid AS varchar(50)) AS [ELO Object ID], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 18)) AS varchar(50)) AS [Document No_], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_4
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 4)) AS varchar(50)) AS [Document Status], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_7
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 8)) AS varchar(50)) AS Country, CAST(ISNULL
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_2
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 16)), '') AS varchar(250)) AS [WF Status Intern], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_3
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 13)) AS varchar(50)) AS [Document Type], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_3
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 3)) AS varchar(250)) AS Comment, SUBSTRING
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_6
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 28)), 7, 2) + '.' + SUBSTRING
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_5
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 28)), 5, 2) + '.' + SUBSTRING
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_4
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 28)), 1, 4) AS [Approval Date String], CONVERT(Datetime, SUBSTRING
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_3
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 28)), 0, 9)) AS [Approval Date], CAST
                          ((SELECT     (CASE COUNT(okeydata) WHEN 0 THEN 0 ELSE 1 END) AS Expr1
                              FROM         dbo.objkeys AS OK7
                              WHERE     (okeyname = 'ELO_XLINK') AND EXISTS
                                                        (SELECT     parentid, okeyno, okeyname, okeydata, okeysdata, recid
                                                          FROM          dbo.objkeys AS OK8
                                                          WHERE      (okeyname = 'ELO_XLINK') AND (REPLACE(REPLACE(okeydata, '+', ''), '-', '') = REPLACE(REPLACE(OK7.okeydata, '+', ''), '-', '')) AND
                                                                                     ((SELECT     objstatus
                                                                                         FROM         dbo.objekte AS OB
                                                                                         WHERE     (objid = OK8.parentid)) = 0) AND (parentid <> dbo.objekte.objid)) AND (parentid = dbo.objekte.objid)) AS int) 
                      AS Attachment
FROM         dbo.objekte
WHERE     (objstatus = 0) AND (objmask = 8) AND
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_1
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 13)) = 'Purchase Request' OR
                          (SELECT     okeydata
                            FROM          dbo.objkeys AS objkeys_1
                            WHERE      (parentid = dbo.objekte.objid) AND (okeyno = 13)) = 'Purchase Order')

[Voutloos]

Lol. Daar dacht iemand dat de afkorting stond voor SubQuery Language.

[Knutselsmurf]

fonsoy schreef op dinsdag 21 april 2020 @ 14:41:
Tsjongejonge. Ik draai een view via een linked server. En erger me groen en geel aan het feit dat 100 regels ophalen wel 5 minuten duurt. Bedrijf waar ik werk staat nu niet bekend om state-of-the-art hardware.

Maarja, wat verwacht je, voor elk record een stuk of 16 subselects en CASTS waar het de vraag is of dat echt wel moet. Bizar gewoon

SQL:

use archive
go

SELECT CAST(objid AS varchar(50)) AS [ELO Object ID], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 18)) AS varchar(50)) AS [Document No_], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_4
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 4)) AS varchar(50)) AS [Document Status], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_7
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 8)) AS varchar(50)) AS Country, CAST(ISNULL
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_2
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 16)), '') AS varchar(250)) AS [WF Status Intern], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_3
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 13)) AS varchar(50)) AS [Document Type], CAST
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_3
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 3)) AS varchar(250)) AS Comment, SUBSTRING
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_6
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 28)), 7, 2) + '.' + SUBSTRING
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_5
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 28)), 5, 2) + '.' + SUBSTRING
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_4
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 28)), 1, 4) AS [Approval Date String], CONVERT(Datetime, SUBSTRING
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_3
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 28)), 0, 9)) AS [Approval Date], CAST
                          ((SELECT     (CASE COUNT(okeydata) WHEN 0 THEN 0 ELSE 1 END) AS Expr1
                              FROM         dbo.objkeys AS OK7
                              WHERE     (okeyname = 'ELO_XLINK') AND EXISTS
                                                        (SELECT     parentid, okeyno, okeyname, okeydata, okeysdata, recid
                                                          FROM          dbo.objkeys AS OK8
                                                          WHERE      (okeyname = 'ELO_XLINK') AND (REPLACE(REPLACE(okeydata, '+', ''), '-', '') = REPLACE(REPLACE(OK7.okeydata, '+', ''), '-', '')) AND
                                                                                     ((SELECT     objstatus
                                                                                         FROM         dbo.objekte AS OB
                                                                                         WHERE     (objid = OK8.parentid)) = 0) AND (parentid <> dbo.objekte.objid)) AND (parentid = dbo.objekte.objid)) AS int) 
                      AS Attachment
FROM         dbo.objekte
WHERE     (objstatus = 0) AND (objmask = 8) AND
                          ((SELECT     okeydata
                              FROM         dbo.objkeys AS objkeys_1
                              WHERE     (parentid = dbo.objekte.objid) AND (okeyno = 13)) = 'Purchase Request' OR
                          (SELECT     okeydata
                            FROM          dbo.objkeys AS objkeys_1
                            WHERE      (parentid = dbo.objekte.objid) AND (okeyno = 13)) = 'Purchase Order')

Typisch gevalletje inner-platform. Met dit soort queries is direct helder waarom dat een slecht idee is

[Haan]

In een ASP.NET MVC applicatie gevonden (niet letterlijk dit natuurlijk, maar wel de structuur):

C#:

var controller = new FooControler(); 
var bar = controller.GetBar(); 

1. dit zit in een andere controller..
2. er wordt dependency injection gebruikt, om bovenstaande mogelijk te maken daarom maar een default constructor aan de FooController toegevoegd
3. de aanroep GetBar heeft geen last van de ontbrekende dependencies omdat in die method gebruik gemaakt wordt van een ServiceLocator om z'n eigen dependencies op te halen

* Haan is een beetje verdrietig

[Mugwump]

Haan schreef op vrijdag 15 mei 2020 @ 08:50:
In een ASP.NET MVC applicatie gevonden (niet letterlijk dit natuurlijk, maar wel de structuur):

C#:

var controller = new FooControler(); 
var bar = controller.GetBar(); 

1. dit zit in een andere controller..
2. er wordt dependency injection gebruikt, om bovenstaande mogelijk te maken daarom maar een default constructor aan de FooController toegevoegd
3. de aanroep GetBar heeft geen last van de ontbrekende dependencies omdat in die method gebruik gemaakt wordt van een ServiceLocator om z'n eigen dependencies op te halen

* Haan is een beetje verdrietig

Kennelijk per ongeluk het front controller design pattern geïmplementeerd.

[R4gnax]

Haan schreef op vrijdag 15 mei 2020 @ 08:50:
In een ASP.NET MVC applicatie gevonden (niet letterlijk dit natuurlijk, maar wel de structuur):

Hey; composition over inheritance, toch?


(Maar inderdaad; veel achterlijker dan dat moet het niet worden...)

[ Voor 12% gewijzigd door R4gnax op 15-05-2020 18:37 ]

[Voutloos]

Klinkt alsof het nog wel uit de knoop te halen is. Of zit stiekem alle domeinkennis ook in de C ipv M?

[whoami]

Haan schreef op vrijdag 15 mei 2020 @ 08:50:
In een ASP.NET MVC applicatie gevonden (niet letterlijk dit natuurlijk, maar wel de structuur):

C#:

var controller = new FooControler(); 
var bar = controller.GetBar(); 

1. dit zit in een andere controller..
2. er wordt dependency injection gebruikt, om bovenstaande mogelijk te maken daarom maar een default constructor aan de FooController toegevoegd
3. de aanroep GetBar heeft geen last van de ontbrekende dependencies omdat in die method gebruik gemaakt wordt van een ServiceLocator om z'n eigen dependencies op te halen

* Haan is een beetje verdrietig

Dit is gewoon een kans om te refactoren

[BezurK]

eagle00789 schreef op dinsdag 14 januari 2020 @ 08:02:
Tja. en dan vind je in een codereview de volgende code van een een collega:

code:

if (1==0)
{
    #meer code die juist altijd uitgevoerd dient te worden
}
else
{
    #meer code die nooit uitgevoerd mag worden in deze context
}

Ik denk dat in dit geval ook de juiste code niet altijd uitgevoerd gaat worden. En die andere code juist wel

[WernerL]

De applicatie die ik nu onderhoud zit vol met prachtige voorbeelden, maar deze vond ik toch wel heel bijzonder. Iemand moet zijn kennis over data structuren even bijspijkeren.

JavaScript:

export interface IDictionary<T, U = string> extends Array<IKeyValue<T, U>> {
    
}

export interface IKeyValue<T, U> {
    key: U;
    value: T;
}

Dit had ook gewoon een type-definitie kunnen zijn:

JavaScript:

export type Dictionary<T,U = string> = Array<IKeyValue<T, U>>

Maar nog beter zou zijn om de Map te gebruiken. (Javascript hashmap)

Verder is een Array sowieso geen Map of Dictionary maar whatever..

[ Voor 39% gewijzigd door WernerL op 16-10-2020 14:16 ]

[diondokter]

Ik was het ooit zat dat ik voor C++ enum classes zelf de flag operations moest definiëren. Daar heb ik toen twee macros voor geschreven:

C++:

// Enum flags

// Creates an operator override for type T, with operator X, and return value R
#define FlagEnumOperator(T,X,R) inline R operator X (T lhs, T rhs) { return (R) (static_cast<std::underlying_type_t <T>>(lhs) X static_cast<std::underlying_type_t <T>>(rhs)); }

// Makes a new enum class with the correct functions to use it as such
#define FlagsEnumClass(T) \
enum class T; \
inline T operator ~ (T t) { return (T) (~static_cast<std::underlying_type_t <T>>(t)); } \
FlagEnumOperator(T,|,T) \
FlagEnumOperator(T,^,T) \
FlagEnumOperator(T,&,bool) \
inline T& operator |= (T& lhs, T rhs) { return lhs = lhs | rhs; } \
enum class T


// Implementation
FlagsEnumClass(Foo)
{
    None = 0,
    Bit0 = (1 << 0),
    Bit1 = (1 << 1),
    Bit2 = (1 << 2),
    Bit3 = (1 << 3),
};

Foo bar() {
    // This now works!
    Foo::Bit1 | Foo::Bit3
}

Ergere macros bestaan, maar dit is ook geen pretje
Het is in het hele project maar liefst 5 keer gebruikt, verder niet. Misschien maar goed ook...

[BugBoy]

Kwam vandaag dit pareltje tegen:

C#:

var ts = DateTime.Now.AddMinutes(1).Subtract(DateTime.Now)
await Task.Delay(ts, cancellationToken);

Ik denk dat ze gewoon dit bedoelden:

C#:

await Task.Delay(TimeSpan.FromMinutes(1), cancellationToken);

[NESFreak]

BugBoy schreef op donderdag 12 november 2020 @ 13:14:
Kwam vandaag dit pareltje tegen:

C#:

var ts = DateTime.Now.AddMinutes(1).Subtract(DateTime.Now)
await Task.Delay(ts, cancellationToken);

Ik denk dat ze gewoon dit bedoelden:

C#:

await Task.Delay(TimeSpan.FromMinutes(1), cancellationToken);

Nu heb ik zelf ook wel eens ruzie gehad met timespans. Je kunt pas sinds gisteren ze vermenigvuldigen met of delen door een double.

https://docs.microsoft.co....op_multiply?view=net-5.0

code:

var drieMinutenOud = TimeSpan.FromTicks((Int64)(Math.Round(TimeSpan.FromMinutes(1).Ticks * 3.0)));
var drieMinutenNieuw =TimeSpan.FromMinutes(1) * 3.0;

[Gomez12]

NESFreak schreef op donderdag 12 november 2020 @ 13:45:
[...]
Nu heb ik zelf ook wel eens ruzie gehad met timespans. Je kunt pas sinds gisteren ze vermenigvuldigen met of delen door een double.

Persoonlijk hadden ze het er van mij uit mogen laten, ik voorzie nu al een shitzooi aan fouten van mensen die in de knoei gaan komen met een kwartier of een half uur etc.

Waardoor je pareltjes gaat krijgen als TimeStamp.FromMinutes(1)*0.30 onder het motto van 1/2 uur is toch 30 minuten...

[RagingPenguin]

Gomez12 schreef op donderdag 12 november 2020 @ 14:45:
[...]

Persoonlijk hadden ze het er van mij uit mogen laten, ik voorzie nu al een shitzooi aan fouten van mensen die in de knoei gaan komen met een kwartier of een half uur etc.

Waardoor je pareltjes gaat krijgen als TimeStamp.FromMinutes(1)*0.30 onder het motto van 1/2 uur is toch 30 minuten...

Ik heb het ook niet zo op al die operator magic in C# (ook met xml met XmlNameSpace + string bv.). Iets van een expliciete Scale method met een argument factor zou al een stuk duidelijker zijn en is nu ook al weer niet zo heel langer dan een *.

[OverloadOfRed]

Noemen we HTML nog code?

HTML:

<label for="nee">Ja</label>

Ik moest een klein beetje huilen toen ik dit zag

[NESFreak]

RagingPenguin schreef op donderdag 12 november 2020 @ 18:11:
[...]


Ik heb het ook niet zo op al die operator magic in C# (ook met xml met XmlNameSpace + string bv.). Iets van een expliciete Scale method met een argument factor zou al een stuk duidelijker zijn en is nu ook al weer niet zo heel langer dan een *.

Wat vind je van de volgende operator magic in VB.net dan? Onlangs introduceerde ik een bug van de volgende vorm omdat een bitmask nodig was in oude deels automatisch vanuit vb6 geimporteerde code:

code:

Dim a as UInteger = &B11 & &B100
Console.WriteLine("a = {0}", a)

spoiler:

a = 34

[Voutloos]

In vb6 code zitten nooit bugs.

spoiler:

On Error Resume Next

[Carharttguy]

Voutloos schreef op donderdag 12 november 2020 @ 20:56:
In vb6 code zitten nooit bugs.

spoiler:

On Error Resume Next

Ik vrees dat ik daar ook aan gezondigd heb als ik 12 was.
Was er überhaupt iets zoals exception handling in VB6?

[RayNbow]

Carharttguy schreef op zaterdag 14 november 2020 @ 23:40:
[...]


Ik vrees dat ik daar ook aan gezondigd heb als ik 12 was.
Was er überhaupt iets zoals exception handling in VB6?

Het is wat cru, maar wat denk je dat On Error GoTo <label> is?

[R4gnax]

NESFreak schreef op donderdag 12 november 2020 @ 13:45:
Nu heb ik zelf ook wel eens ruzie gehad met timespans. Je kunt pas sinds gisteren ze vermenigvuldigen met of delen door een double.

Uhmm... nee. Dat kan al sinds .NET Core 2.0

[Tk55]

Java:

protected void addSteps( List < Things > things, Date date )
{
    if (allSteps || _stepA) {
        things.add(buildThingConfig("A", date, "somethings", "aaa", true,
                new someProvider(), new newSomeOtherProvider()));
    }
    if (allSteps || _stepB) {
        things.add(buildThingConfig("B", date, "somethings", "bbb", true));
    }
    if (allSteps || _stepC) {
        things.add(buildThingConfig("C", date, "somethings", "ccc", true,
                new someProvider(), newSomeOtherProvider()));
    }
    if (allSteps || _stepD) {
        things.add(buildThingConfig("D", date, "somethings", "ddd", true, new someProvider()));
    }
    if (allSteps || _stepE) {
        things.add(buildThingConfig("E", date, "somethings", "eee", true, new someProvider()));
    }
    if ((allSteps || _stepF) && !someVar) {
        things.add(buildThingConfig("F", date, "somethings", "fff", true, new someProvider()));
    }
    if (allSteps || _stepG) {
        things.add(buildThingConfig("G", date, "somethings", "ggg", true, new someProvider())
                .withThing(SPECIAL_THING));
    }
    if (date.getDayOfWeek() == "Saturday" && (allSteps || _stepH)) {
        things.add(buildThingConfig("H", date, "somethings", "hhh", true, new someProvider()));
    }
    if (date.plusDays(1).getDayOfMonth() == 1 && (allSteps || _stepI)) {
        things.add(buildThingConfig("I", date, "somethings", "iii", true, new someProvider())
                .withThing(SPECIAL_THING));
    } 
}

[Reptile209]

Tk55 schreef op donderdag 4 februari 2021 @ 16:16:

Java:

protected void addSteps( List < Things > things, Date date )
{
    if (allSteps || _stepA) {
        things.add(buildThingConfig("A", date, "somethings", "aaa", true,
                new someProvider(), new newSomeOtherProvider()));
    }
    if (allSteps || _stepB) {
        things.add(buildThingConfig("B", date, "somethings", "bbb", true));
    }
    if (allSteps || _stepC) {
        things.add(buildThingConfig("C", date, "somethings", "ccc", true,
                new someProvider(), newSomeOtherProvider()));
    }
    if (allSteps || _stepD) {
        things.add(buildThingConfig("D", date, "somethings", "ddd", true, new someProvider()));
    }
    if (allSteps || _stepE) {
        things.add(buildThingConfig("E", date, "somethings", "eee", true, new someProvider()));
    }
    if ((allSteps || _stepF) && !someVar) {
        things.add(buildThingConfig("F", date, "somethings", "fff", true, new someProvider()));
    }
    if (allSteps || _stepG) {
        things.add(buildThingConfig("G", date, "somethings", "ggg", true, new someProvider())
                .withThing(SPECIAL_THING));
    }
    if (date.getDayOfWeek() == "Saturday" && (allSteps || _stepH)) {
        things.add(buildThingConfig("H", date, "somethings", "hhh", true, new someProvider()));
    }
    if (date.plusDays(1).getDayOfMonth() == 1 && (allSteps || _stepI)) {
        things.add(buildThingConfig("I", date, "somethings", "iii", true, new someProvider())
                .withThing(SPECIAL_THING));
    } 
}

Gevalletje: "organische groei van functionaliteit" zonder de boel eens op een handige en logische manier te refactoren? En wordt het origineel ook niet verstoord door allemaal van die onhandige comments die je alleen maar afleiden van de code?

[thlst]

Tk55 schreef op donderdag 4 februari 2021 @ 16:16:

Java:

    if (date.getDayOfWeek() == "Saturday" 

Java kan ik amper spellen , maar waarom werkt dit ?

[heuveltje]

thlst schreef op donderdag 4 februari 2021 @ 23:52:
[...]


Java kan ik amper spellen , maar waarom werkt dit ?

ik kan het nog niet eens spellen, maar waarom zou het niet werken ?

[ Voor 9% gewijzigd door heuveltje op 04-02-2021 23:58 ]

[Haan]

heuveltje schreef op donderdag 4 februari 2021 @ 23:56:
[...]

ik kan het nog niet eens spellen, maar waarom zou het niet werken ?

Omdat getDayOfWeek een enum returnt, en er wordt vergeleken met een string.

[Merethil]

Haan schreef op vrijdag 5 februari 2021 @ 08:36:
[...]

Omdat getDayOfWeek een enum returnt, en er wordt vergeleken met een string.

En nog eens op een verkeerde manier ook als je met Strings wil vergelijken in Java. Nu is het aardig door de poster beschreven code met random naamgeving en variabelen, dus kans is aanwezig dat het een copy-paste-foutje is en in de echte code er nog een .name() achter de getDayOfWeek() staat, en er een .equals() wordt gebruikt ipv ==.

[heuveltje]

https://www.geeksforgeeks...dayofweek-method-in-java/

code:

program 1:

filter_none
edit
play_arrow

brightness_4
// Program to illustrate the getDayOfWeek() method 
  
import java.util.*; 
import java.time.*; 
  
public class GfG { 
    public static void main(String[] args) 
    { 
        // Parses the date 
        LocalDate dt = LocalDate.parse("2018-11-27"); 
  
        // Prints the day 
        System.out.println(dt.getDayOfWeek()); 
    } 
}

Output:
TUESDAY

[Tk55]

Reptile209 schreef op donderdag 4 februari 2021 @ 23:06:
[...]
Gevalletje: "organische groei van functionaliteit" zonder de boel eens op een handige en logische manier te refactoren? En wordt het origineel ook niet verstoord door allemaal van die onhandige comments die je alleen maar afleiden van de code?

Ja, aan de git history te zien is het over meerdere jaren toegevoegd. Er zijn wel meer van dit soort voorbeelden in deze codebase

thlst schreef op donderdag 4 februari 2021 @ 23:52:
[...]
Java kan ik amper spellen , maar waarom werkt dit ?

Merethil schreef op vrijdag 5 februari 2021 @ 08:42:
[...]
En nog eens op een verkeerde manier ook als je met Strings wil vergelijken in Java. Nu is het aardig door de poster beschreven code met random naamgeving en variabelen, dus kans is aanwezig dat het een copy-paste-foutje is en in de echte code er nog een .name() achter de getDayOfWeek() staat, en er een .equals() wordt gebruikt ipv ==.

Ik heb de code nogal fanatiek anoniem gemaakt en niet gekeken naar of de syntax helemaal correct is In het origineel wordt het vergeleken met een SATURDAY variabele uit een joda-time package, wat gewoon een int is.

[NESFreak]

Tk55 schreef op vrijdag 5 februari 2021 @ 10:06:
[...]

Ik heb de code nogal fanatiek anoniem gemaakt en niet gekeken naar of de syntax helemaal correct is In het origineel wordt het vergeleken met een SATURDAY variabele uit een joda-time package, wat gewoon een int is.

Gaat het in het origineel dan wel om

code:

List < Things > things

of

code:

List < Thing > things

Een van mijn pet peeves is toch echt dat als je een lijst van dingen hebt, hetgeen wat er in zit toch echt niet een dingen is.

[Merethil]

heuveltje schreef op vrijdag 5 februari 2021 @ 09:19:
https://www.geeksforgeeks...dayofweek-method-in-java/

code:

program 1:

filter_none
edit
play_arrow

brightness_4
// Program to illustrate the getDayOfWeek() method 
  
import java.util.*; 
import java.time.*; 
  
public class GfG { 
    public static void main(String[] args) 
    { 
        // Parses the date 
        LocalDate dt = LocalDate.parse("2018-11-27"); 
  
        // Prints the day 
        System.out.println(dt.getDayOfWeek()); 
    } 
}

Output:
TUESDAY

De reden dat dat werkt is omdat de enum dat als name heeft, en die zit in de toString. In de code waar het nu om gaat wordt vergeleken met een String die "Saturday" is, en dat is dus niet vol uppercase. Daar bovenop wordt vergeleken met == wat niet kan want het zijn niet exact dezelfde Stringobjecten, ze verwijzen naar andere geheugenlocaties en dus werkt ook dát niet.

Als er .name() en .equalsIgnoreCase() werd gebruikt kan je wél met een String comparen, maar dat gebeurt er dus niet. Zoals de poster zegt gebeurt er wél een comparison met iets als LocalDateTime.SATURDAY of hoe die syntax ook is.

[Tk55]

NESFreak schreef op vrijdag 5 februari 2021 @ 10:27:
[...]


Gaat het in het origineel dan wel om

code:

List < Things > things

of

code:

List < Thing > things

Een van mijn pet peeves is toch echt dat als je een lijst van dingen hebt, hetgeen wat er in zit toch echt niet een dingen is.

De tweede. Mooi dat mijn slechte programmeervoorbeeld uiteindelijk zelf een slecht programmeervoorbeeld blijkt

[.oisyn]

NESFreak schreef op vrijdag 5 februari 2021 @ 10:27:
[...]


Gaat het in het origineel dan wel om

code:

List < Things > things

of

code:

List < Thing > things

Een van mijn pet peeves is toch echt dat als je een lijst van dingen hebt, hetgeen wat er in zit toch echt niet een dingen is.

Analoog daaraan, enkelvoudige tablenames

[Reptile209]

.oisyn schreef op vrijdag 5 februari 2021 @ 11:31:
[...]


Analoog daaraan, enkelvoudige tablenames

Wat wil je dan? Tables_2, NewTables, enz?

[thlst]

Tk55 schreef op vrijdag 5 februari 2021 @ 11:20:
[...]

De tweede. Mooi dat mijn slechte programmeervoorbeeld uiteindelijk zelf een slecht programmeervoorbeeld blijkt

_step[A-I] zaten ook gewoon in een of andere collection natuurlijk

[Ruud2001]

.oisyn schreef op vrijdag 5 februari 2021 @ 11:31:
[...]


Analoog daaraan, enkelvoudige tablenames

Niks mis mee toch? Het wordt pas vervelend als naamgeving niet consistent is doorgevoerd, dus soms enkelvoudig en soms meervoudig

[.oisyn]

Ruud2001 schreef op vrijdag 5 februari 2021 @ 16:48:
[...]


Niks mis mee toch?

Niets mis mee? Waarom noem je iets dat meerdere auto's opslaat, een Car? Hetzelfde als enkelvoudige namen gebruiken voor containers in een programmeertaal: list<Thing> thing, vector<Apple> apple, Person person[].

[ Voor 24% gewijzigd door .oisyn op 05-02-2021 16:53 ]

[Ruud2001]

.oisyn schreef op vrijdag 5 februari 2021 @ 16:51:
[...]


Niets mis mee? Waarom noem je iets dat meerdere auto's opslaat, een Car? Hetzelfde als enkelvoudige namen gebruiken voor containers in een programmeertaal: list<Thing> thing, vector<Apple> apple, Person person[].

Voor tabel naamgeving maakt het mij niet uit, zolang het maar consistent wordt toegepast. Wellicht dat enkelvoudig zelfs mijn voorkeur heeft als we kijken naar zaken als koppeltabellen; tabel Car en tabel ParkingSpot met koppeltabel CarParkingSpot.

Qua naamgeving voor containers in programmeertalen ben ik het volledig met je eens. List<thing> things is de enige juiste toepassing

Waarom ik verschil maak tussen tabellen en containers? No idea... waarschijnlijk ben ik gewoon enorm gewend aan projecten met enkelvoudige naamgeving. Overigens niet alleen in maatwerk software, maar ook in commerciele pakketten zoals MS Dynamics en Oracle suites.

[.oisyn]

Ruud2001 schreef op vrijdag 5 februari 2021 @ 17:08:
[...]


zolang het maar consistent wordt toegepast.

[..]

Waarom ik verschil maak tussen tabellen en containers? No idea...

Oh the irony...

[MBV]

.oisyn schreef op vrijdag 5 februari 2021 @ 17:09:
[...]


Oh the irony...

Ik zal zijn stelling even verdedigen. In een database heb je het over lijsten van items, waarbij tabellen 'normaal' genoemd worden naar het item dat erin zit. In imperative of functionele programmeertalen heb je List<Car> cars, dus cars.first is een Car met eigenschappen als doorCount. In een database heb je een tabel waarin een Car voorkomt: de tabel is de lijst. Als je dit als imperatieve code hebt:

code:

List<Car> cars;
Car car = cars.first;
printf(car.doorCount);

Volgens mij is iedereen het er wel over eens dat dat normale naamgeving is qua meervoud etc. Als je denkt dat Cars een goede tabelnaam is, krijg je dit:

SQL:

SELECT Cars.doorCount
FROM Cars
WHERE Cars.Id = MIN(Cars.Id)

Cars.doorCount, je geeft toch per rij het aantal deuren van 1 instantie? Ook als je daar SUM(Cars.doorCount) zet klopt het niet: je telt het aantal deuren op dat voor elke rij (instantie) van de tabel wordt teruggegeven. Een tabelnaam in enkelvoud vind ik dus 100x zo logisch.

Having said that: de laatste keer dat ik serieus met SQL bezig was is denk ik 15 jaar geleden

[.oisyn]

@MBV Jij valt dus wel over gekunstelde naamgeving die je ook kan ontwijken door dingen anders op te schrijven, maar dat je vervolgens iets enkelvoudigs specificeert in FROM heb je geen enkele moeite mee?

SQL:

SELECT Car.doorCount
FROM Car -- hier dus
WHERE Car.Id = MIN(Car.Id)

Je selecteert niet iets van een auto, je selecteert iets uit de tabel met auto's.

Alternatieven:

SQL:

SELECT doorCount
FROM Cars
WHERE Id = MIN(Id)

Of:

SQL:

SELECT Car.doorCount
FROM Cars AS Car
WHERE Car.Id = MIN(Car.Id)

(Even afgezien van dat het feit je MIN() hier niet zo kan gebuiken)


En ja, dit is een heuvel waarop ik bereid ben te sterven

[ Voor 18% gewijzigd door .oisyn op 05-02-2021 18:40 ]