[alg] Slechtste programmeervoorbeelden deel 4

[Verwijderd]

Mwah, ik gebruik zelf al jaren Microsoft Dynamics AX (voorheen Axapta) en daarin is de datumafhandeling prima. Ook als je instelt dat je de ISO weeknummers wilt hebben.

Er zijn dus ook wel producten van Microsoft die het wel goed doen.

Outlook geeft bij mij volgens mij ook altijd de juiste weeknummers weer, of zitten daar ook nog leuke datum bugs in?

[ Voor 20% gewijzigd door Verwijderd op 10-03-2011 01:28 ]

[Freeaqingme]

Kijk eens of in Outlook een 29 februari 1900 is?

[ Voor 27% gewijzigd door Freeaqingme op 10-03-2011 02:05 ]

[Verwijderd]

Nope is er niet.

[.oisyn]

Is er iig niet in de windows time dialog

[burne]

Verwijderd schreef op donderdag 10 maart 2011 @ 01:27:
Mwah, ik gebruik zelf al jaren Microsoft Dynamics AX (voorheen Axapta) en daarin is de datumafhandeling prima.

Dat is dan ook extern ingekocht.

[Verwijderd]

burne schreef op donderdag 10 maart 2011 @ 02:47:
[...]

Dat is dan ook extern ingekocht.

Geniaal.

Maar er zijn vrij weinig zaken bij Microsoft niet extern ingekocht, dus in hoeverre is dat een factor?

[.Gertjan.]

Verwijderd schreef op donderdag 10 maart 2011 @ 01:27:
Mwah, ik gebruik zelf al jaren Microsoft Dynamics AX (voorheen Axapta) en daarin is de datumafhandeling prima. Ook als je instelt dat je de ISO weeknummers wilt hebben.

Dat is dan ook het enige wat prima werkt in Dynamics AX
Geintje, sommige dingen zijn best mooi in AX, maar toch mis ik geregeld mijn .NET/Visual studio...

burne schreef op donderdag 10 maart 2011 @ 02:47:
[...]
Dat is dan ook extern ingekocht.

Nadien heeft Microsoft toch behoorlijk zijn stempel gedrukt in AX, tegenwoordig leunt het behoorlijk zwaar op het .NET framework en Microsoft SQL Server. Het lijkt me dat inmiddels het afhandelen van datum structuren via .NET/SQL loopt.

[Guillome]

Nou ik heb er ook 1 hoor, een query van mezelf die ik tegen kwam. Hoe ik `m zo gemaakt heb is me een raadsel.
Nee ik blow en spuit en drink niet.

SQL:

..
WHERE g.ID IN (
  SELECT ID FROM groepen WHERE naam = (
  SELECT naam FROM groepen WHERE ID IN ($groep_ID))
                                 )

[PolarBear]

Freee!! schreef op woensdag 09 maart 2011 @ 23:41:
[...]

Ervaring.

[...]

Ik heb alle instellingen meermaals nagelopen. En het is niet de enige fout in Excel, als je het aantal dagen sinds 1 januari 1900 berekent voor een datum, kom je één dag te hoog uit (29-02-1900 wordt geaccepteerd als datum en meegenomen in de berekeningen ).

Dat is gedocumenteerd en een bug die uit Lotus 1-2-3 is overgenomen.

SQL 2008 heeft tegenwoordig ook ondersteuning voor ISO weeknummers in zich (standaard).

[ Voor 8% gewijzigd door PolarBear op 11-03-2011 09:56 ]

[Verwijderd]

burne schreef op donderdag 10 maart 2011 @ 02:47:
[...]

Dat is dan ook extern ingekocht.

Lol true.

[Gamebuster]

Freeaqingme schreef op donderdag 10 maart 2011 @ 02:05:
Kijk eens of in Outlook een 29 februari 1900 is?

1900 is geen schrikkeljaar

[ Voor 7% gewijzigd door Gamebuster op 11-03-2011 17:01 ]

[Apache]

Microsoft implementeert ook geen olsen database (Wikipedia: tz database)
waardoor date/time handling voor oude datums sowieso beyond pointless is aangezien dat vaak niet door regels herleid kan worden hoe laat het ergens exact was.

Het word pas echt vervelend als je een JVM hebt die het wel goed doet, en dan een frontend technologie die vertrouwd op de native os functies, krijg je verschillen in presentatie als je de datum tussen je backend en frontend stuurt ...

[Alex)]

Ik kwam net dit pareltje tegen:

C#:

public string NieuwsDatumDag
{
    get
    {
        return (NieuwsDatum.Day + 100).ToString().Substring(1) + "-" +
        (NieuwsDatum.Month + 100).ToString().Substring(1) + "-" + NieuwsDatum.Year;
    }
}

Toch maar even herschreven naar:

C#:

public string NieuwsDatumDag
{
    get { return NieuwsDatum.ToString("dd-MM-yyyy"); }
}

[ Voor 11% gewijzigd door Alex) op 12-03-2011 01:55 ]

[Freee!!]

Gamebuster schreef op vrijdag 11 maart 2011 @ 17:01:
[...]

1900 is geen schrikkeljaar

Volgens Excel wel hoor .

[Verwijderd]

Freee!! schreef op vrijdag 11 maart 2011 @ 17:34:
[...]

Volgens Excel wel hoor .

Excel faal dan

De gregoriaanse kalender lost de overcompensatie op door slechts eeuwjaren die deelbaar zijn door 400 (zoals 2000) als schrikkeljaar te behouden, en eeuwjaren die niet deelbaar zijn door 400 (zoals 1700, 1800, 1900) niet.

[Haan]

Alex) schreef op vrijdag 11 maart 2011 @ 17:30:
Ik kwam net dit pareltje tegen:

C#:

        public string NieuwsDatumDag
        {
            get
            {
                return (NieuwsDatum.Day + 100).ToString().Substring(1) + "-" +
                       (NieuwsDatum.Month + 100).ToString().Substring(1) + "-" + NieuwsDatum.Year;
            }
        }

Toch maar even herschreven naar:

C#:

        public string NieuwsDatumDag
        {
            get { return NieuwsDatum.ToString("dd-MM-yyyy"); }
        }

En die wat heb je met die +100 (waar dat ook goed voor mocht wezen) gedaan?

[_js_]

Die +100 is natuurlijk om te zorgen dat de substring goed werkt

[Alex)]

Haan schreef op vrijdag 11 maart 2011 @ 17:41:
[...]

En die wat heb je met die +100 (waar dat ook goed voor mocht wezen) gedaan?

Opgegeten. Die +100 zorgde er alleen maar voor dat 4 maart 2011 (4-3-2011) werd geprint als 04-03-2011.

[Avalaxy]

Pfff, schrikkeljaren stop je toch gewoon hard-coded in een array? Kan er ook niks fout gaan

[Freee!!]

Avalaxy schreef op vrijdag 11 maart 2011 @ 17:55:
Pfff, schrikkeljaren stop je toch gewoon hard-coded in een array? Kan er ook niks fout gaan

Beetje overdreven, tussen 1582 en 4000 (volgende uitzondering ) is het voor elke fatsoenlijke programmeur in een paar regels op te lossen. Gegeven een jaar EEJJ, test of JJ gelijk is aan nul, zoja, stop EE in hulpvariabele HH, anders JJ. Deel HH door 4 en bepaal of er een rest is. Indien er geen rest is, is het een schrikkeljaar.

Die tabel kost een hoop meer regels om te definiëren en te vullen en daarna moet je ook nog gaan zoeken.

[ Voor 9% gewijzigd door Freee!! op 11-03-2011 19:13 ]

[eamelink]

Apache schreef op vrijdag 11 maart 2011 @ 17:09:
Het word pas echt vervelend als je een JVM hebt die het wel goed doet, en dan een frontend technologie die vertrouwd op de native os functies, krijg je verschillen in presentatie als je de datum tussen je backend en frontend stuurt ...

Tsja, ik vind de fout in dat geval eerder liggen bij het OS dan bij de front-end technologie

[Avalaxy]

Freee!! schreef op vrijdag 11 maart 2011 @ 19:12:
[...]

Die tabel kost een hoop meer regels om te definiëren en te vullen en daarna moet je ook nog gaan zoeken.

Snapte je het sarcasme echt niet?

[Verwijderd]

Avalaxy schreef op zaterdag 12 maart 2011 @ 00:13:
[...]


Snapte je het sarcasme echt niet?

There's an array for that.

[real[B]art]

Freee!! schreef op vrijdag 11 maart 2011 @ 19:12:
Beetje overdreven, tussen 1582 en 4000 (volgende uitzondering ) is het voor elke fatsoenlijke programmeur in een paar regels op te lossen.

Dankzij mensen als jij kunnen we in 3999 dus bakken met geld uit gaan geven aan de Y4K-bug

[Jegorex]

real[B]art schreef op zondag 13 maart 2011 @ 02:03:
[...]

Dankzij mensen als jij kunnen we in 3999 dus bakken met geld uit gaan geven aan de Y4K-bug

Tenzij je programma in COBOL geschreven is hoef je je geen zorgen te maken dat je software dan nog werkt

[ReneDD]

real[B]art schreef op zondag 13 maart 2011 @ 02:03:
[...]

Dankzij mensen als jij kunnen we in 3999 dus bakken met geld uit gaan geven aan de Y4K-bug

Proef een stukje sarcasme. Het is misschien wat overdreven om te roepen dat er een kans is dat je het stukje software dan nog steeds gebruikt, maar helaas heb ik nog bijna dagelijks te maken met oude mainframe troep met documentatie ouder dan ik zelf 1980's. Waarschijnlijk hebben ze toen ook niet gedacht dat hun software nog overeind zou staan tot in de volgende eeuw ;p

[ Voor 50% gewijzigd door ReneDD op 13-03-2011 08:55 ]

[Freee!!]

real[B]art schreef op zondag 13 maart 2011 @ 02:03:
[...]

Dankzij mensen als jij kunnen we in 3999 dus bakken met geld uit gaan geven aan de Y4K-bug

Als ze die programmatuur van mij dan nog gebruiken, mogen ze me rond die tijd terugroepen

Jegorex schreef op zondag 13 maart 2011 @ 03:18:
[...]

Tenzij je programma in COBOL geschreven is hoef je je geen zorgen te maken dat je software dan nog werkt

Juist met COBOL zou het me niet verbazen als het dan nog wel werkt, die taal is al een aantal keren doodverklaard en nog steeds wordt er meer in geschreven.

[ Voor 38% gewijzigd door Freee!! op 13-03-2011 13:11 ]

[EdwinG]

Freee!! schreef op zondag 13 maart 2011 @ 13:10:
Juist met COBOL zou het me niet verbazen als het dan nog wel werkt, die taal is al een aantal keren doodverklaard en nog steeds wordt er meer in geschreven.

Dat is ook precies wat er gezegd werd.

Tenzij je programma in COBOL geschreven is hoef je je geen zorgen te maken dat je software dan nog werkt

Kun je ook lezen als 'alleen als je programma in COBOL geschreven is, hoef je je zorgen te maken dat je software dan nog werkt.'

[Z-Dragon]

[ Voor 100% gewijzigd door Z-Dragon op 13-03-2011 14:15 ]

[Verwijderd]

Ach ja, tegen die tijd zijn wij (die nu leven) allang dood Laat ze er in die tijd maar zorgen om maken

[ Voor 27% gewijzigd door Verwijderd op 13-03-2011 14:07 ]

[Freee!!]

EdwinG schreef op zondag 13 maart 2011 @ 13:24:
[...]
Dat is ook precies wat er gezegd werd.

Ooooops, my bad, niet helemaal goed gelezen

[Keeper]

Niet om nou weer over rare conventies in PHP te gaan beginnen, maar is dit niet raar of ben ik gek?

PHP:

$string = 'test';
var_dump(isset($string['foo'])); # true

Terwijl in een array het wel werkt.

PHP:

$array = array('foo' => 'bar', 'baz' => 2);
var_dump(isset($array['foo'])); # true
var_dump(isset($array['bat'])); # false

[kaesve]

haha, dat is een quirk die ik nog niet kende. blijkbaar accepteert een string alleen ints als index, wanneer je ze benadert als array. in jouw eerste voorbeeld word 'foo' dus eerst gecast naar een int, wat 0 oplevert. $string[0] levert daarna gewoon 't' op.

[FragFrog]

Keeper schreef op maandag 14 maart 2011 @ 12:12:
Niet om nou weer over rare conventies in PHP te gaan beginnen, maar is dit niet raar of ben ik gek?

Manual:

Non-integer types are converted to integer.

Gedocumenteerd gedrag enzo Wel een goede reden om ook in PHP te letten op types. Het mag dan wel een weak-typed taal zijn, er zit wel degelijk verschil in.

Overigens zul je er ook geen last van hebben als je gewoon de juistie functie hiervoor gebruikt

[ Voor 27% gewijzigd door FragFrog op 14-03-2011 14:11 ]

[Keeper]

FragFrog schreef op maandag 14 maart 2011 @ 14:09:
Gedocumenteerd gedrag enzo Wel een goede reden om ook in PHP te letten op types. Het mag dan wel een weak-typed taal zijn, er zit wel degelijk verschil in.

Dat dacht ik wel, maar het is intuïtief toch raar.

Overigens zul je er ook geen last van hebben als je gewoon de juistie functie hiervoor gebruikt

Dat heb ik dan ook maar meteen even aangepast ;-).

[Janoz]

Keeper schreef op maandag 14 maart 2011 @ 15:21:
Dat dacht ik wel, maar het is intuïtief toch raar.

Fixed it for ya.

[Morax]

Keeper schreef op maandag 14 maart 2011 @ 15:21:
[...]

Dat dacht ik wel, maar het is intuïtief toch raar.

[...]

Dat heb ik dan ook maar meteen even aangepast ;-).

Dan los je ook gelijk een ander probleem op met isset(), namelijk dat isset() FALSE teruggeeft wanneer de key wel bestaat maar de waarde NULL bevat

[Zoijar]

FragFrog schreef op maandag 14 maart 2011 @ 14:09:
Gedocumenteerd gedrag enzo

PHP -- it's not a bug; it's a feature

[YopY]

Zoijar schreef op maandag 14 maart 2011 @ 16:09:
[...]

PHP -- it's not a bug; it's a feature

PHP - It's not a bug, you just don't get it.

* YopY padumtish

[CyBeR]

Apache schreef op vrijdag 11 maart 2011 @ 17:09:
Het word pas echt vervelend als je een JVM hebt die het wel goed doet, en dan een frontend technologie die vertrouwd op de native os functies, krijg je verschillen in presentatie als je de datum tussen je backend en frontend stuurt ...

Dat probleem hebben wij ooit gehad met een conversie in MySQL tussen een DATETIME veld en iets anders (omdat DATETIME ergens niet goed mee om kan gaan, ik vergeet wat). Er was toen een verschil in hoe de conversie gedaan werd (fout) en hoe de weergave gedaan werd (goed) tussen de timestamp in onze database en de human-readable front-end string.

Na onderzoek merkten we dat dat kwam omdat de eerdere conversie geen rekening hield met de toen geldende regels voor DST en, in sommige gevallen zelfs met de 19.32 minuten offset van UTC die vroeger gold, en de latere conversie (naar strings) wél.

Resultaat was dat de geboorte- en sterfdata van een groot deel van de mensen op de betreffende site (gaat over de 2e wereldoorlog en de vermoorde joden) vaak een dag te vroeg (of te laat, ik vergeet welke) was.

Uiteindelijk konden we nog redelijk simpel achterhalen welke data 'getroffen' waren door die fout en ze herstellen.

[Crazy D]

Datums blijven een ramp. Had laatst een conversie vanuit een wat oudere versie van Microsoft CRM. Datum werd blijkbaar opgeslagen als CET time waardoor iemand die op 2 feb jarig was, volgens de database op 1 feb om 23.00 u al jarig was

[Haan]

Soms barst je spontaan in huilen uit als je een stukje code tegenkomt

JavaScript:

function Postcode1()
{
    Postcode("1");
}
function Postcode2()
{
    Postcode("2");
}
function Postcode(Field)
{
    var postalcodeField = "postalcode_1";
    if (Field == "2")
    {
        postalcodeField = "postalcode_2";
    }
    // rest van functie
}

[Woy]

Datums/Tijden zijn inderdaad soms flink irritant. Wij slaan alles gewoon altijd als UTC op en eventueel ergens een Timezone. Maar wij moeten ook weer berekeningen over die data doen, en dus is de berekening afhankelijk van de Timezone waar de gebruiker in zit . Om nog maar niet te spreken over DST

[Davio]

Woy schreef op dinsdag 15 maart 2011 @ 08:51:
Datums/Tijden zijn inderdaad soms flink irritant. Wij slaan alles gewoon altijd als UTC op en eventueel ergens een Timezone. Maar wij moeten ook weer berekeningen over die data doen, en dus is de berekening afhankelijk van de Timezone waar de gebruiker in zit . Om nog maar niet te spreken over DST

Ik denk dat datum/tijd altijd één van de lastigste dingen blijven voor programmeurs.

Ik heb ooit wel eens alternatieven gelezen voor internettijd of worldtime of iets dergelijks en ben daar wel voorstander van.

Maar hoe verander je iets wat zo ingebakken zit in een samenleving. Ik denk dat we in onderontwikkelde landen moeten beginnen, waar ze nog geen horloges hebben.

[CyBeR]

DST nu valt nog wel mee, maar vroeger had je dus dit soort grappen:

De wet maakte echter niet duidelijk naar welke meridiaan de ‘Amsterdamse Tijd’, zoals het in de praktijk werd genoemd, geregeld zou worden en het ontbreken van een hoofdstedelijke sterrenwacht maakte de keuze hiervan ietwat willekeurig. In het algemeen werd hiervoor de meridiaan van de Westertoren (4° 53' 01.95" oosterlengte) verstaan, overeenkomend met een tijdsverschil van 19 minuten 32.13 seconden met UT.

En bij de invoering van DST in Nederland was men ook niet het makkelijkst bezig. Dit komt uit de tz database:

# From 1926 through 1939 DST began 05-15, except that it was delayed by a week
# in years when 05-15 fell in the Pentecost weekend.

[Haan]

Gelukkig had je in die tijd nog geen computers en databases om je druk over te maken

[Verwijderd]

Super beveiliging:

PHP:

<?php
if (!$access) {
    echo '<script>alert("U heeft geen rechten om deze pagina te bekijken");</script>';
    echo '<script>document.location = "/";</script>';
}
?>
<html>
    <head>
        <!-- insert rest van 'beveiligde' pagina -->

Dus ....

[Alex)]

Gelukkig vernaggel je tenminste wel de renderingmode van degenen die geen toegang hebben en JS uitschakelen...

[noes]

Verwijderd schreef op dinsdag 15 maart 2011 @ 16:43:
Super beveiliging:

PHP:

<?php
if (!$access) {
    echo '<script>alert("U heeft geen rechten om deze pagina te bekijken");</script>';
    echo '<script>document.location = "/";</script>';
}
?>
<html>
    <head>
        <!-- insert rest van 'beveiligde' pagina -->

Dus ....

Als er nou een else bij had gestaan was het ineens niet zo'n probleem

[Verwijderd]

noes schreef op dinsdag 15 maart 2011 @ 16:58:
[...]


Als er nou een else bij had gestaan was het ineens niet zo'n probleem

Als ja, maar is dus niet het geval... Maar dit is gewoon een epic fail.

[ Voor 7% gewijzigd door Verwijderd op 15-03-2011 19:59 ]

[InZane]

noes schreef op dinsdag 15 maart 2011 @ 16:58:
[...]


Als er nou een else bij had gestaan was het ineens niet zo'n probleem

Dan was het alsnog een dikke fail.

1. JS alert gevolgd door document.location.. WTF
2. En dat dan ook nog eens boven <html>

[Gaius]

Had 'm al in de HK gepost en werd toen gewezen op het bestaan van dit topic. Dus bij deze hier.

C#:

public CustomObject New()
{
   return new CustomObject();
}

Ik moet met de hakbijl door de code heen waar (o.a.) ik aan werk en bovenstaande method kom ik net tegen. Je moet die class nota bene eerst instantiëren voordat je de method kunt aanroepen.

[Haan]

Miles Teg schreef op donderdag 17 maart 2011 @ 13:55:
Had 'm al in de HK gepost en werd toen gewezen op het bestaan van dit topic. Dus bij deze hier.

C#:

public CustomObject New()
{
   return new CustomObject();
}

Ik moet met de hakbijl door de code heen waar (o.a.) ik aan werk en bovenstaande method kom ik net tegen. Je moet die class nota bene eerst instantiëren voordat je de method kunt aanroepen.

Dus je moet dit doen?

C#:

CustomObject obj = new CustomObject();
CustomObject newObj = obj.New();

Het kan toch haast niet anders dan dat er eerst meer code in die functie zat, en/of dat het een soort mislukte poging tot factory model is ofzo.

[Gaius]

Haan schreef op donderdag 17 maart 2011 @ 14:51:
[...]

Dus je moet dit doen?

C#:

CustomObject obj = new CustomObject();
CustomObject newObj = obj.New();

Klopt.

Het kan toch haast niet anders dan dat er eerst meer code in die functie zat, en/of dat het een soort mislukte poging tot factory model is ofzo.

Dat denk ik niet. Ik ben het nu al meerdere keren tegengekomen en in een aantal gevallen staat er nog een method onder:

C#:

public CustomObject New(Hashtable defaultValues)
{
   return new CustomObject(defaultValues);
}

//Constructor is gewoon public...:
public CustomObject(Hashtable defaultValues)
{
   this.defaultValues = defaultValues;
}

Maar ja, wat kun je anders verwachten van programmeurs waarbij het aantal geschreven coderegels een metric is.

[Amras]

In iets minder erge vorm ook al weleens tegengekomen:

C#:

public Foo()
{
}

public static Foo Create()
{
    return new Foo();
}

Heel nuttig met die public constructor en verder geen logica in de factory method.

[CodeCaster]

Misschien zijn het overstappers van Delphi?

Delphi:

someObj := TSomeObj.Create();

[.oisyn]

Ja maar maak de method dan gewoon static

[Alex)]

static method, private constructor.

[jaapio88]

of deze mooie constructie met exceptions

C#: foo.cs

        public void SendMsg(string msgBuffer)
        {
            Logger.Instance.Log(Logger.Level.Debug, "Out: " + msgBuffer);

            byte[] msgByte = Encoding.ASCII.GetBytes(msgBuffer);
            uint len = (uint)msgByte.Length;
            byte[] msgLen = System.BitConverter.GetBytes(Tool.endian_swap(len));
            try
            {
                Socket tempSock = socket;
                if (tempSock != null)
                {
                    lock (tempSock)
                    {
                        socket.Send(msgLen);
                        socket.Send(msgByte);
                    }
                }
                else
                {
                    throw new Exception(FooException.CauseEnum.NoConnection);
                }
            }
            catch (Exception ex)
            {
                Exception fEx = FooException.ToFooException(ex);
                if (Ex != null)
                {
                    // Whether it is a bad thing nobody is listening depends on the situation. In case
                    // of a server, it is not always required that someone is listening.
                    Logger.Instance.Log(
                        server != null ? Logger.Level.Warning : Logger.Level.Error, 
                        "Trying to send while no connection is open");
                    throw Ex;
                }
                // We don't know what is going on, there is no sensible way to recover
               Logger.Instance.Log(Logger.Level.Error, "Exception occured: " + ex.Message);
                throw;
            }

        }

[CodeCaster]

Ik neem aan dat socket een membervariabele is die elders in de klasse (bijvoorbeeld bij Connect()) wordt geset? Er wordt wel behoorlijk omslachtig gedaan met die tempSocket en die exceptions, maar bijzonder slecht...? Of mis ik wat?

[ Voor 4% gewijzigd door CodeCaster op 18-03-2011 08:16 ]

[Verwijderd]

Die comments maken het weer ok

[Janoz]

Toch blijft het lomp. Bij java kun je meerdere catch blocks bij een enkel try block zetten. Ik neem aan dat dat in C# ook wel kan.

[ReneDD]

Haan schreef op donderdag 17 maart 2011 @ 14:51:
[...]

Dus je moet dit doen?

C#:

CustomObject obj = new CustomObject();
CustomObject newObj = obj.New();

Het kan toch haast niet anders dan dat er eerst meer code in die functie zat, en/of dat het een soort mislukte poging tot factory model is ofzo.

Dan snap ik het nog niet, want dan herschrijf je de constructor toch gewoon? Als het een static class was geweest had je die ene regel nog kunnen besparen. Het wordt er echter nog steeds niet goed/netjes/juist door ;p

[mithras]

Janoz schreef op vrijdag 18 maart 2011 @ 11:26:
Toch blijft het lomp. Bij java kun je meerdere catch blocks bij een enkel try block zetten. Ik neem aan dat dat in C# ook wel kan.

Zelfs php kan het

[roy-t]

Janoz schreef op vrijdag 18 maart 2011 @ 11:26:
Toch blijft het lomp. Bij java kun je meerdere catch blocks bij een enkel try block zetten. Ik neem aan dat dat in C# ook wel kan.

Ja dat kan

[Jan_V]

ReneDD schreef op vrijdag 18 maart 2011 @ 11:31:
[...]


Dan snap ik het nog niet, want dan herschrijf je de constructor toch gewoon? Als het een static class was geweest had je die ene regel nog kunnen besparen. Het wordt er echter nog steeds niet goed/netjes/juist door ;p

In sommige gevallen wil je dat juist niet, zie:
http://sourcemaking.com/r...uctor-with-factory-method
Wikipedia: Factory method pattern

Vind de voorbeelden nou niet echt iets wat ik in het echt zou gebruiken, maar het geeft in ieder geval een idee.

[CodeCaster]

Maar dan is de factory method nog steeds static, dus hoef je de factory niet te instantiëren. In de door Miles Teg geposte code is dat echter niet het geval.

[Avalaxy]

In die code van sourcemaking:

[code=java]
static Employee create(int type) {
switch (type) {
case ENGINEER:
return new Engineer();
case SALESMAN:
return new Salesman();
case MANAGER:
return new Manager();
default:
throw new IllegalArgumentException("Incorrect type code value");
}
}
[/]

Als je hier 'ENGINEER' mee geeft krijg je toch een Manager object terug?

Edit: oh laat maar... Door je return breekt je loop natuurlijk... Ik miste de breaks

[ Voor 8% gewijzigd door Avalaxy op 18-03-2011 14:59 ]

[YopY]

Janoz schreef op vrijdag 18 maart 2011 @ 11:26:
Toch blijft het lomp. Bij java kun je meerdere catch blocks bij een enkel try block zetten. Ik neem aan dat dat in C# ook wel kan.

* YopY zal blij zijn zodra Java 7 uitkomt, waar je meerdere exceptiontypes in één catch blok kunt pleuren en ze op dezelfde manier kunt afvangen. Natuurlijk is het gewoon wat syntactische suiker, maar toch is dat net weer een stukje netter.

[Sjaaky]

TryParse met defaultwaarde:

C#:

int result = int.TryParse("", out result) ? result : 0;

Leuk als je wilt veranderen naar:

C#:

return int.TryParse("", out result) ? result : 0;

Maar dan werkt het ineens niet meer .

[lier]

Sjaaky schreef op vrijdag 18 maart 2011 @ 15:58:
TryParse met defaultwaarde:

C#:

int result = int.TryParse("", out result) ? result : 0;

Leuk als je wilt veranderen naar:

C#:

return int.TryParse("", out result) ? result : 0;

Maar dan werkt het ineens niet meer .

Optimaliseren:

C#:

return 0;

TryParse() doet de out parameter toch standaard op 0 zetten als deze niet geparst kan worden!?

[ Voor 10% gewijzigd door lier op 18-03-2011 16:03 ]

[Sjaaky]

lier schreef op vrijdag 18 maart 2011 @ 16:01:
[...]
TryParse() doet de out parameter toch standaard op 0 zetten als deze niet geparst kan worden!?

Ja.
De constanten in mijn voorbeeld dienen slechts ter illustratie. Maar ik geef toe dat ik ze niet heel handig gekozen heb .

[Freeaqingme]

ik kom zojuist dit pareltje tegen. Nee, niet uit m'n eigen codebase:

code:

<?php
// ...

$query="SELECT MAX(id)+1 FROM pas ";

$resultaat = mysql_query($query);
while (list($pasid) = mysql_fetch_row($resultaat)){
$pasid=$id;
}

[Enfer]

Freeaqingme schreef op dinsdag 22 maart 2011 @ 22:47:
ik kom zojuist dit pareltje tegen. Nee, niet uit m'n eigen codebase:

code:

<?php
// ...

$query="SELECT MAX(id)+1 FROM pas ";

$resultaat = mysql_query($query);
while (list($pasid) = mysql_fetch_row($resultaat)){
$pasid=$id;
}

Undefined variable $id;?

[Woy]

Sjaaky schreef op vrijdag 18 maart 2011 @ 15:58:
TryParse met defaultwaarde:

C#:

int result = int.TryParse("", out result) ? result : 0;

Leuk als je wilt veranderen naar:

C#:

return int.TryParse("", out result) ? result : 0;

Maar dan werkt het ineens niet meer .

Ik zie even over het hoofd waarom het dan op eens niet meer werkt ( Op je constante lege string na natuurlijk, maar die zit ook in je eerste voorbeeld )

[.Gertjan.]

Woy schreef op woensdag 23 maart 2011 @ 08:59:
[...]

Ik zie even over het hoofd waarom het dan op eens niet meer werkt ( Op je constante lege string na natuurlijk, maar die zit ook in je eerste voorbeeld )

Misschien dat de waarde die uit de tryparse terugkomt (als out) pas na het uitvoeren van de regel in de result variabele wordt gestoken. Als je dus result teruggeeft is deze nog niet gevuld met de out waarde van de TryParse.

Out parameters zijn vrij bijzondere beestjes, dus waarschijnlijk wordt de instructie om result te vullen met de out variabele pas na deze regel uitgevoerd.

edit:
klopt niet helemaal, maar ik blijf erbij dat het bijzondere beestjes zijn maar wel verrekte handige beestjes

Dat zou de enige verklaring zijn die ik kan bedenken

Bij mij bugt hij niet overigens:

C#:

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(Option1());
            Console.WriteLine(Option2());
            Console.ReadLine();
        }

        static int Option1()
        {
            int result = int.TryParse("", out result) ? result : 0;
            return result;
        }
        static int Option2()
        {
            int result;
            return int.TryParse("", out result) ? result : 0;            
        }
    }

Komt gewoon 0 en 0 uit. Als ik de "" vervang voor een getal komt er ook gewoon het getal uit in beide gevallen

[ Voor 35% gewijzigd door .Gertjan. op 23-03-2011 09:18 ]

[Woy]

@.Gertjan.: out parameters zijn helemaal geen bijzondere beestjes, en nee, ze worden ook niet pas gezet na de assignment ( Anders zou het eerste voorbeeld immers ook niet werken ). Het result is gewoon netjes gezet op het moment dat de TryParse returnt ( Waarschijnlijk zelfs al iets eerder ).

Ik heb het even getest

C#:

public int TryParseWithDefault(string input)
{
    int result;
    return int.TryParse(input, out result) ? result : 0;
}
Assert.IsTrue(TryParseWithDefault("12") == 12);
Assert.IsTrue(TryParseWithDefault("xx12") == 0);

En die test pass't ook gewoon.

[.Gertjan.]

Woy schreef op woensdag 23 maart 2011 @ 09:14:
@.Gertjan.: out parameters zijn helemaal geen bijzondere beestjes, en nee, ze worden ook niet pas gezet na de assignment ( Anders zou het eerste voorbeeld immers ook niet werken ). Het result is gewoon netjes gezet op het moment dat de TryParse returnt ( Waarschijnlijk zelfs al iets eerder ).

Ik heb het even getest

C#:

public int TryParseWithDefault(string input)
{
    int result;
    return int.TryParse(input, out result) ? result : 0;
}
Assert.IsTrue(TryParseWithDefault("12") == 12);
Assert.IsTrue(TryParseWithDefault("xx12") == 0);

En die test pass't ook gewoon.

Inderdaad, zie ook mijn edit, het lijkt gewoon te werken. De out params zijn op zich wel bijzonder omdat je zo ook valuetypes by reference kunt meegeven, maar inderdaad de manier die ik beschreef is niet de manier waarop het werkte. Wat ik uit het boek begreep worden er wel speciale instructies geplaatst om de out/ref mogelijk te maken, dus had verwacht dat het daar mis ging.

Wat je zegt over het eerste statement klopt ook inderdaad, had ik niet eens bij stil gestaan, dat werkt op dezelfde manier... Mijn fout

[ Voor 6% gewijzigd door .Gertjan. op 23-03-2011 09:19 ]

[Woy]

.Gertjan. schreef op woensdag 23 maart 2011 @ 09:17:
[...]
De out params zijn op zich wel bijzonder omdat je zo ook valuetypes by reference kunt meegeven

Daar is natuurlijk niks speciaal aan. In plaats van een reference/valuetype by-value door te geven ( default ) geef je de reference/valuetype nu by-ref door. De waarde van result veranderd dus waarschijnlijk zelfs nog voordat de TryParse returnt ( Al zou het misschien kunnen dat de compiler daar optimalisaties op toe mag passen )

[ Voor 18% gewijzigd door Woy op 23-03-2011 09:23 ]

[.Gertjan.]

Woy schreef op woensdag 23 maart 2011 @ 09:22:
[...]

Daar is natuurlijk niks speciaal aan. In plaats van een reference/valuetype by-value door te geven ( default ) geef je de reference/valuetype nu by-ref door. De waarde van result veranderd dus waarschijnlijk zelfs nog voordat de TryParse returnt ( Al zou het misschien kunnen dat de compiler daar optimalisaties op toe mag passen )

ik vind ze wel speciaal
Maar value en reference types zijn binnen .NET toch in principe erg verschillend? Dat je inderdaad de reference in plaats van de value doorgeeft is logisch (anders zou het niet werken), maar ik was er van overtuigd dat er nog een slag extra was die de waarde daadwerkelijk toekende aan je variabele, maar ik denk dat ik iets heel anders in mijn hoofd had (boekje niet goed gelezen denk ik).

[jip_86]

Woy schreef op woensdag 23 maart 2011 @ 08:59:
[...]

Ik zie even over het hoofd waarom het dan op eens niet meer werkt ( Op je constante lege string na natuurlijk, maar die zit ook in je eerste voorbeeld )

En wat is er mis met op de volgende regel gewoon return result te doen

[ Voor 65% gewijzigd door jip_86 op 23-03-2011 09:35 . Reden: volgende keer eerst volgende pagina doen :p ]

[Woy]

.Gertjan. schreef op woensdag 23 maart 2011 @ 09:28:
[...]

ik vind ze wel speciaal
Maar value en reference types zijn binnen .NET toch in principe erg verschillend? Dat je inderdaad de reference in plaats van de value doorgeeft is logisch (anders zou het niet werken), maar ik was er van overtuigd dat er nog een slag extra was die de waarde daadwerkelijk toekende aan je variabele, maar ik denk dat ik iets heel anders in mijn hoofd had (boekje niet goed gelezen denk ik).

Ja die zijn inderdaad verschillend. Je moet je echter goed realiseren dat de default in C# is om parameters by-value te passen, echter is het bij ref-types zo dat de ref by-value doorgegeven word, en by value-types de value by-value. Door een out/ref parameter te specificeren geeft je of de reference of de value niet by-value, maar by-ref door.

jip_86 schreef op woensdag 23 maart 2011 @ 09:33:
[...]


En wat is er mis met op de volgende regel gewoon return result te doen

In principe niks, maar dat is gewoon een kwestie van smaakt. Maar er is geen noodzaak om het te doen.

[barfieldmv]

Helaas zie ik de in/out byref/byval paramters (bijna) altijd incorrect gebruikt.

Ja maar, dit is een groot array, die moet natuurlijk byref anders verdubbeld het geheugen gebruik.
Wat is er mis met mijn byref, ik new hem toch? (als het niet nodig is)
Ja dit veld moet als out anders kan het object niet aanpassen

[drm]

Amras:
In iets minder erge vorm ook al weleens tegengekomen:

C#:

public Foo()
{
}

public static Foo Create()
{
    return new Foo();
}

Heel nuttig met die public constructor en verder geen logica in de factory method.

Moet zeggen dat ik me in PHP aan iets dergelijks ook wel eens schuldig maak i.c.m. een fluent interface, maar dat is alleen omdat de fijne PHP parser niet generiek is, en het me dan een extra variabele scheelt

PHP:

class SqlSelectQuery {
    static function create() { 
        return new self();
    }
    /* ... */
}

$query = SqlSelectQuery::create()
    ->from('table')
    ->where(
        sprintf(
            'id IN(%s)', 
            SqlSelectQuery::create()
                ->select('foo')
                ->from('bar')
        )
    );

Maar dat is geheel te wijten aan het feit dat de parser zich hierin verslikt

PHP:

(new SqlSelectQuery())->from('w00t');

Ik heb overigens ook wel eens overwogen om dan gewoon een functie met dezelfde naam als de class te introduceren die gewoon een nieuwe instantie teruggeeft, maar dat ging me toch iets te ver

[Zsub]

Ik heb ook een klein pareltje gevonden, al zeg ik het zelf:

JavaScript:

// Controleren
naamBrowser    = navigator.appName;
versieBrowser  = parseInt(navigator.appVersion);

if ((naamBrowser == "Netscape" && versieBrowser >= 3) || (naamBrowser == "Microsoft Internet Explorer" && versieBrowser >=4)) { 
    gekeurdeBrowser = "yes";
}
else { 
    gekeurdeBrowser = "no";   
}

// Plaatjes preloaden
if (gekeurdeBrowser == "yes") {
//snip
}

[Davio]

Dan kun je beter zoiets programmeren:

JavaScript:

if (naamBrowser == "Netscape")
{
    alert("Hey grandpa, Marc Andreessen is calling from the year 1997, he wants his browser back!");
}

if (naamBrowser == "Microsoft Internet Explorer ")
{
    alert("This browser is not supported, even Lynx has better HTML5 support than IE!");
}

Haha, heb Netscape wel geprobeerd indertijd, maar snapte niet waarom ik een andere browser nodig had, heerlijk om zo newb te zijn. Sinds de overstap naar de eerste Phoenix bètas (dat is dus pre-Firefox en pre-Firebird) heb ik geen andere browser meer gebruikt.

Hier en daar een uitstapje naar Opera / Chrome / noem het maar, maar FF had toch de fijnste plug-in support voor wat ik wilde gebruiken.

[Paul]

Mja, waarschijnlijk staat onder die site ook "© 1995" of zo 'Vroeger' was dat een redelijk gebruikelijke manier, niet zo veel vreemds aan, tenzij je het nu als ontwikkelaar nog in productie brengt.

[FragFrog]

Paul Nieuwkamp schreef op donderdag 24 maart 2011 @ 10:31:
Mja, waarschijnlijk staat onder die site ook "© 1995" of zo 'Vroeger' was dat een redelijk gebruikelijke manier, niet zo veel vreemds aan, tenzij je het nu als ontwikkelaar nog in productie brengt.

Op zich is het gebruik van "yes" / "no" natuurlijk wel een klein beetje vreemd, ook vroeger

[Davio]

FragFrog schreef op donderdag 24 maart 2011 @ 14:36:
[...]

Op zich is het gebruik van "yes" / "no" natuurlijk wel een klein beetje vreemd, ook vroeger

Ja, je lacht erom, maar ik werk met een taal (Progress / 4GL / OpenEdge) waarin voor logicals (booleans dus) zowel de waarden TRUE en FALSE (en unknown: ?) geldig zijn, maar dus ook YES en NO.

En laat het nou zo zijn dat YES en NO kortere woorden zijn dan TRUE en FALSE.

[Jan_V]

Misschien stamt de code nog uit de tijd dat er nog geen booleans bestonden en alles nog met strings gedaan moest worden. Oh nee, wacht.....

[Verwijderd]

Davio schreef op donderdag 24 maart 2011 @ 14:54:

En laat het nou zo zijn dat YES en NO kortere woorden zijn dan TRUE en FALSE.

Sinds wanneer is het tikken van code meer werk dan het bedenken ervan?

[Erkens]

Davio schreef op donderdag 24 maart 2011 @ 14:54:
En laat het nou zo zijn dat YES en NO kortere woorden zijn dan TRUE en FALSE.

1 en 0 zijn nog korter

[ Voor 32% gewijzigd door Erkens op 24-03-2011 15:01 ]

[Avalaxy]

Verwijderd schreef op donderdag 24 maart 2011 @ 14:56:
[...]

Sinds wanneer is het tikken van code meer werk dan het bedenken ervan?

Los van dit heb je bij booleans geen quotes nodig, wat weer extra karakters zijn. Met strings kom je dus op meer karakters uit.

[dev10]

Davio schreef op donderdag 24 maart 2011 @ 14:54:
Ja, je lacht erom, maar ik werk met een taal (Progress / 4GL / OpenEdge) waarin voor logicals (booleans dus) zowel de waarden TRUE en FALSE (en unknown: ?) geldig zijn, maar dus ook YES en NO.

Objective C heeft gebruikt ook YES en NO voor logicals.

[FragFrog]

Davio schreef op donderdag 24 maart 2011 @ 14:54:
En laat het nou zo zijn dat YES en NO kortere woorden zijn dan TRUE en FALSE.

Het gaat me er niet om dat hij yes / no tikt in plaats van true / false. Mijn probleem met die code is dat hij strings en stringoperaties gebruikt in plaats van booleans voor booleaanse waardes. Dat is toch wel zo ongeveer een van de meest basic fouten die je kan maken.

Temeer omdat je op een gegeven moment tests krijgt als if (value == "yes" || value == "true" || value == "waar" || value == "ok"). Lach maar, ik heb het gezien

[Kaw]

FragFrog schreef op donderdag 24 maart 2011 @ 15:25:
[...]
Temeer omdat je op een gegeven moment tests krijgt als if (value == "yes" || value == "true" || value == "waar" || value == "ok"). Lach maar, ik heb het gezien

Vergeet niet de eerste letter als hoofdletter en allemaal hoofdletters. Ik heb ze dus nog wel groter gezien. Ook nog met 1 en 0.

[ Voor 4% gewijzigd door Kaw op 24-03-2011 17:07 ]

[Verwijderd]

Heb vandaag een site gezien die een admin username en wachtwoord ophaalde uit een database, die in Javascript stopte en dan op de form-submit keek of het ingevulde overeen kwam... Ja, het wachtwoord stond dus plain-text in de broncode. Indiaas outsource project van een klant dat weer terug kwam. Er is toch maar even een snelle htaccess op de admin gegooid ;-). In de Indiase code prutsen is niet te doen.

[Keeper]

FragFrog schreef op donderdag 24 maart 2011 @ 15:25:
Temeer omdat je op een gegeven moment tests krijgt als if (value == "yes" || value == "true" || value == "waar" || value == "ok"). Lach maar, ik heb het gezien

Dat kan je natuurlijk optimaliseren met:

PHP:

if(in_array(strtolower($value), array('yes', 'true', 'waar', 'ok'))) { }

.

[drm]

Keeper:
Dat kan je natuurlijk optimaliseren met:

PHP:

if(in_array(strtolower($value), array('yes', 'true', 'waar', 'ok'))) { }

.

Als je dan toch gaat "optimaliseren", maak er dan een functie van. Wat zeg ik, twee! is_true() en is_false(). Hoewel je dan misschien ook weer aliases aan moet maken met is_yes() en is_no()... Oh, en is_not_true() en is_not_false() dan ook maar meteen. Is wel zo leesbaar.

[ Voor 0% gewijzigd door drm op 25-03-2011 00:41 . Reden: typo ]

[Kaw]

Eigenlijk is het gewoon beter om geen php te gebruiken wanneer je geeft om nette code. Om toch cheap webhosting te kunnen aanbieden zou ook Mono ASP.net gebruikt kunnen worden. Als ik om mij heen kijk dan zijn veruit de meeste grotere projecten met PHP keurig begonnen, maar uiteindelijk allemaal ontaard in chaos.