[alg] Slechtste programmeervoorbeelden deel 2

[Marcj]

BalusC schreef op woensdag 16 mei 2007 @ 13:24:
Apart trouwens dat de compiler accepteert dat een static final property bij elke instantatie aangepast mag worden.

De property zelf wordt natuurlijk niet aangepast, deze is nog steeds hetzelfde object. Alleen de inhoud van het object wordt aangepast. Hiertegen bescherm het final keyword niet

[BalusC]

Ik doelde ook meer op de combinatie static + final. Dan zou je denken dat dit in totaal maar 1x gevuld mag worden en dan alleen hetzij direct of anders in een static initializer block.

[ Voor 57% gewijzigd door BalusC op 16-05-2007 13:33 ]

[Marcj]

Hoe moet java dan weten welke functies je dan wel en niet mag aanroepen? Daarnaast zegt static alleen maar dat de variabele bij een klasse hoort en niet bij een instantie. De final geeft aan dat die variabele (dus de pointer naar een object, of een primitieve) niet veranderd mag worden.

Je kunt dan ook overal binnen het object toegang krijgen tot die variabele (en elke instantie krijg de verwijzing naar dezelfde variabele), maar wat binnen die variabele gebeurt kan natuurlijk niet gegarandeerd worden.

[BalusC]

Daarnaast zegt static alleen maar dat de variabele bij een klasse hoort en niet bij een instantie.

Er is dus maar 1 van. En ondanks de 'final' mag het toch bij elke instantatie aangepast worden. Dát vind ik dus apart

[JKVA]

Marcj schreef op woensdag 16 mei 2007 @ 13:40:
Hoe moet java dan weten welke functies je dan wel en niet mag aanroepen? Daarnaast zegt static alleen maar dat de variabele bij een klasse hoort en niet bij een instantie. De final geeft aan dat die variabele (dus de pointer naar een object, of een primitieve) niet veranderd mag worden.

Je kunt dan ook overal binnen het object toegang krijgen tot die variabele (en elke instantie krijg de verwijzing naar dezelfde variabele), maar wat binnen die variabele gebeurt kan natuurlijk niet gegarandeerd worden.

Toch moet ik wel zeggen dat ik BalusC een punt vind hebben. Eigenlijk zou een initializer block gekoppeld moeten zijn aan een property (die geinitialiseerd wordt). Daarmee zou dan het blok dezelfde scoping (klasse/instantie) moeten krijgen als de property waar het bij hoort. Tenslotte is een initializer block bedoelt voor initialisatie, dus een static variabele instantiëren op instance niveau is raar.

Niet dat ze zomaar de Java compiler zullen aanpassen, maar toch.

[Janoz]

De staticfinal zorgt ervoor dat je verderop niet een

code:

LIST = new ArrayList<String>();

kunt doen. Dat is de enige beperking. Het niet mogen wijzigen van die lijst is in java onmogelijk af te dwingen. Bij C++ heb je nog het 'const' keyword. Hiermee geef je aan dat die parameter of die methode het object niet veranderd. Hierdoor kun je een verschil maken tussen de get (die niks veranderd) en de set (die wel wat veranderd) methode. In java is iets dergelijks niet. De compiler kan niet weten of de aanroep van een methode het object wel of niet veranderd.

@hierinder: Yep idd....lompe typo..

[ Voor 4% gewijzigd door Janoz op 16-05-2007 14:07 ]

[BalusC]

Janoz schreef op woensdag 16 mei 2007 @ 13:48:
De static zorgt ervoor dat je verderop niet een

code:

LIST = new ArrayList<String>();

kunt doen.

Daar zorgt de 'final' modifier voor.

[.oisyn]

Ik weet het, C++ roeleert

[BalusC]

Ik heb even overheen gekeken dat in dit specifieke geval de inhoud van een collectie wordt aangepast en niet de instantie van de collectie zelf. Dan mag het inderdaad wel Gevaarlijk

[YopY]

.oisyn schreef op woensdag 16 mei 2007 @ 14:04:
Ik weet het, C++ roeleert

totdat je je eerste buffer overflow krijgt en geen flauw idee hebt waar dat weg komt .

[Janoz]

Ik zei eerder via de msn ook al tegen /oisyn dat het nu van 123412 tegen 0 naar 123412 tegen 1 ging

[Anoniem: 143331]

YopY schreef op woensdag 16 mei 2007 @ 14:44:
[...]

totdat je je eerste buffer overflow krijgt en geen flauw idee hebt waar dat weg komt .

Ach, als je programmeert in een taal waarin buffer overflows mogelijk zijn, dan houd je daar tijdens het programmeren toch rekening mee? Kwestie van discipline. Wil of kan je dat niet: kies dan een andere taal, waarin dit soort zaken voor je geregeld worden.

Daarnaast is (iig voor C/C++ achtige talen) een simpele aanpak om het probleem op te sporen, de bewuste buffer uit te breiden met een paar bytes aan weerszijden. Start dan de debugger, zet een paar breakpoints op die controle-bytes, en gaan met die handel. Het zal mogelijk een tijdje duren, maar vroeger of later worden een of meer van die bytes gewijzigd, waarna de debugger ogenblikkelijk stopt. En je dus de plaats in je code gevonden hebt.

Is het gebruik van een debugger niet mogelijk of te omslachtig: zet dan in je code op strategische plaatsen een assert waarin de waarden van die extra bytes gecontroleerd worden. Wordt er een overflow geconstateerd, geef dan een log-msg, en doe een exit(1) oid.

Het wordt natuurlijk een andere kwestie als het probleem op lijkt te treden in een 3th-party lib, waar je niet (goed) met een debugger doorheen kunt lopen. Dan is het een kwestie van proberen het probleem te isoleren in een zo klein mogelijk programma, en dan contact op te nemen met de leverancier.

.oisyn schreef op woensdag 16 mei 2007 @ 14:04:
Ik weet het, C++ roeleert

. Maar goed, ieder heeft zijn persoonlijke favorieten, en elke taal zijn specifieke toepassingen.

[DaCoTa]

Janoz schreef op woensdag 16 mei 2007 @ 13:48:
Het niet mogen wijzigen van die lijst is in java onmogelijk af te dwingen.

Voor dit soort dingen lijkt me dan de Enum wel op zijn plek.

[schoene]

Janoz schreef op woensdag 16 mei 2007 @ 14:47:
Ik zei eerder via de msn ook al tegen /oisyn dat het nu van 123412 tegen 0 naar 123412 tegen 1 ging

hahaha. maak er maar 2 van

[Soultaker]

Janoz schreef op woensdag 16 mei 2007 @ 13:48:
De staticfinal zorgt ervoor dat je verderop niet een

code:

LIST = new ArrayList<String>();

kunt doen. Dat is de enige beperking. Het niet mogen wijzigen van die lijst is in java onmogelijk af te dwingen.

Jawel; je kunt een list wrappen in een unmodifiable list (moet je wel zorgen dat externe code geen referentie naar de oorspronkelijke list meer heeft).
Zie: java.util.Collections.unmodifiableList. (En vergelijkbare methoden voor andere collectie-klassen.)

[Anoniem: 49627]

Soultaker schreef op woensdag 16 mei 2007 @ 16:40:
Jawel; je kunt een list wrappen in een unmodifiable list (moet je wel zorgen dat externe code geen referentie naar de oorspronkelijke list meer heeft).

Ik neem toch maar even voor het gemak aan dat Janoz dat echt wel begrijpt. Maar dat was dan ook zijn punt niet. Het punt is dat je met keywords onmogelijk kunt afdwingen dat de onderliggende data structuur ongewijzigd blijft.

[.oisyn]

Anoniem: 143331 schreef op woensdag 16 mei 2007 @ 15:40:
Is het gebruik van een debugger niet mogelijk of te omslachtig: zet dan in je code op strategische plaatsen een assert waarin de waarden van die extra bytes gecontroleerd worden. Wordt er een overflow geconstateerd, geef dan een log-msg, en doe een exit(1) oid.

Of:

C++:

template<class T> checked_access
{
public:
    typedef T::value_type value_type;
    typedef T::reference reference;
    typedef T::const_reference const_reference;

    /* constructor zut e.d. */

    reference operator[](size_t i)
    {
    #if _DEBUG
        assert(i < m_data.size());
    #endif
        return m_data[i];
    }

    const_reference operator[](size_t i) const
    {
    #if _DEBUG
        assert(i < m_data.size());
    #endif
        return m_data[i];
    }

private:
    T m_data;
};

Wellicht nog specializations for T[N] en T* (of je maakt een mooie Array concept als je elite bent en al van ConceptGCC gebruik maakt ), maar you get the point. In debug krijg je een mooie assert als je buiten de oevers treedt, in release wordt het mooi weggeoptimaliseerd.

[ Voor 4% gewijzigd door .oisyn op 16-05-2007 19:38 ]

[Swaptor]

Tijdens het reviewen van wat PHP-code van een klasgenootje kwam ik de volgende constructie tegen:

PHP:

 $aantal_reacties = 
mysql_num_rows(
mysql_query(
"SELECT * FROM nieuwsreacties WHERE nieuws_id = '$nieuws[id]'"
)
);

Ik zou toch zweren dat ook hij heeft opgelet tijdens de colleges over SQL, maar kennelijk is COUNT 'm ontschoten

(Dat naast de mogelijke SQL-injection, maar dat terzijde)

[PrisonerOfPain]

.oisyn schreef op woensdag 16 mei 2007 @ 19:36:
[...]
In debug krijg je een mooie assert als je buiten de oevers treedt, in release wordt het mooi weggeoptimaliseerd.

Dat doet het default al, waarom staat er dan nog #if _DEBUG omheen?

Een persoonlijke van mij;

code:

cat $1 | egrep "([[:space:]]*function[^[:alpha:]]+)|(abstract[[:space:]]+)?class[[:space:]]+[A-Za-z][A-Za-z0-9]+|interface[[:space:]]+|((private|public|var|protected)[[:space:]]+\\$)" | sed 's/\/\/.\{0,\}/ /g' | sed 's/[[:space:]]\{0,\}[{;][[:space:]]\{0,\}$//' | sed 's/^[[:space:]]\{1,\}/     /'

En

code:

OUTPUT=`cat $1 | egrep -n "\/\/.{0,}(TODO|NOTE|FIXME|DONE|HACK|BUG)" | sed "s/[[:space:]]\{0,\}\([[:digit:]]\{1,\}\).\{0,\}\/\/[[:space:]]\{0,\}\([A-Z]\{1,\}\)\([^[:alpha:]]\{1,\}\)\(.\{0,\}\)[[:space:]]\{0,\}$/\\\\\e[1;31m\2\\\\\e[0m \4\\\\\n/"`
echo -en "" $OUTPUT | sort -r;

Ondanks de source zijn het toch twee nuttige shell scripts.

[Erkens]

Swaptor schreef op zaterdag 09 juni 2007 @ 20:55:
(Dat naast de mogelijke SQL-injection, maar dat terzijde)

Dat kan je adhv dit fragment niet zien afgezien, de in mijn ogen, ranzige manier om variabelen in een string te zetten

[brama]

PrisonerOfPain schreef op zaterdag 09 juni 2007 @ 22:57:
[...]

Dat doet het default al, waarom staat er dan nog #if _DEBUG omheen?

Een persoonlijke van mij;

..

Ondanks de source zijn het toch twee nuttige shell scripts.

En de useless use of cat award gaat naar...

[Anoniem: 37526]

Swaptor schreef op zaterdag 09 juni 2007 @ 20:55:
Tijdens het reviewen van wat PHP-code van een klasgenootje kwam ik de volgende constructie tegen:

PHP:

 $aantal_reacties = 
mysql_num_rows(
mysql_query(
"SELECT * FROM nieuwsreacties WHERE nieuws_id = '$nieuws[id]'"
)
);

Ik zou toch zweren dat ook hij heeft opgelet tijdens de colleges over SQL, maar kennelijk is COUNT 'm ontschoten

(Dat naast de mogelijke SQL-injection, maar dat terzijde)

Toch zie ik niet hoe je dit met een count in een single-line kan stoppen

[Creepy]

Het gaat er dan ook hoe je dat in een single lijn kan stoppen. Maar je haalt nu altijd de gehele tabel op en die komt dus ook in het geheugen van je programma. Vervolgens haal je hier een num_rows overeen. Als je een count gebruikt gebeurt dat niet en krijg je als result direct het aantal terug. Je gaat wel een verschil merken met een flink aantal rijen

[Erkens]

brama schreef op zondag 10 juni 2007 @ 00:02:
[...]


En de useless use of cat award gaat naar...

Zo useless is het in dit geval niet, het zorgt hier namelijk voor een betere leesbaarheid van de "code".

[T-MOB]

Anoniem: 37526 schreef op zondag 10 juni 2007 @ 00:13:
[...]
Toch zie ik niet hoe je dit met een count in een single-line kan stoppen

Nu, ja, hetzelfde eigenlijk, alleen met een andere functie.

PHP:

$aantal_reacties = 
mysql_fetch_field (
  mysql_query(
    "SELECT count(*) FROM nieuwsreacties WHERE nieuws_id = '$nieuws[id]'"
  ), 0, 0
);

Maar waarom je het in een regel zou willen is me een raadsel...

[.oisyn]

PrisonerOfPain schreef op zaterdag 09 juni 2007 @ 22:57:
[...]

Dat doet het default al, waarom staat er dan nog #if _DEBUG omheen?

Omdat wij asserts aan hebben staan in release builds

[Soultaker]

Assertions zijn aan als NDEBUG niet gedefinieerd is. Is het dan niet handiger om drie projecten te maken: debug, release, en release-met-assertions (waarbij de laatste twee dezelfde instellingen hebben, behalve dat bij de release-build NDEBUG gedefinieerd wordt).

I.m.o niet netjes om te verwachten dat dat elke keer netjes handmatig toegevoegd wordt. (Sowieso kun je dan nog beter voor het includen een check doen, en NDEBUG definiëren als _DEBUG niet gedefinieerd is). Of was het als slecht programmeervoorbeeld bedoeld?

Ook deze reactie even meenemen:

Anoniem: 49627 schreef op woensdag 16 mei 2007 @ 17:46:
Ik neem toch maar even voor het gemak aan dat Janoz dat echt wel begrijpt. [..] Het punt is dat je met keywords onmogelijk kunt afdwingen dat de onderliggende data structuur ongewijzigd blijft.

Onzin, hij zei gewoon dat het in Java niet kon (niet dat er geen syntax support voor was), en ik gaf aan hoe het gewoon wel kan. Je hebt er in Java inderdaad geen specifieke syntax voor, maar dat is dus ook niet nodig.

[Janoz]

Wat ik bedoelde is dat de Java 'final' niet hetzelfde is als de C++ 'const'. Het ging dus inderdaad om de keywords. Natuurlijk is er omheen te werken, maar het toevoegen van een keyword lijkt me ene stuk makkelijker dan het compleet implementeren van een apparte interface/proxy. Goed, ze bestaan wel voor de collecties, maar vaak wil je ook je eigen classes unmodifiable maken.

[.oisyn]

Soultaker schreef op zondag 10 juni 2007 @ 15:27:
Assertions zijn aan als NDEBUG niet gedefinieerd is. Is het dan niet handiger om drie projecten te maken: debug, release, en release-met-assertions (waarbij de laatste twee dezelfde instellingen hebben, behalve dat bij de release-build NDEBUG gedefinieerd wordt).

Ik geloof dat ik nergens beweer dat "debug" en "release" onze enige twee configuraties zijn, noch dat "release" de config is die uiteindelijk wordt gereleased (we hebben debug (optimalisaties uit, asserts aan), release (asserts aan), profile (asserts uit, timing code aan), master (zeg maar de release voor lokaal gebruik) en goldmaster (release zoals het op disc komt)

I.m.o niet netjes om te verwachten dat dat elke keer netjes handmatig toegevoegd wordt.

Dat wat handmatig wordt toegevoegd? _DEBUG wordt idd nauwelijks gebruikt, daar hebben we weer subsystem-specifieke defines voor (CDC_BUILD_ARRAY_ENABLE_CHECK zou hij in dit geval bijvoorbeeld kunnen heten). Maar ik denk dat je inmiddels wel begrijpt dat dit gewoon een voorbeeld was

[ Voor 10% gewijzigd door .oisyn op 10-06-2007 22:07 ]

[Spinal]

Dit kwam ik laatst tegen in een (PHP) pokerscript

PHP:

function store() {
    global $players;
    for ($m=1; $m<=$players; $m++) {
        global ${"hand$m"};
        mysql_query("INSERT INTO poker_cards VALUES('$m','".implode("," ,${"hand$m"})."')");
    }
}

PHP:

global ${"hand$n"};
unset ($pairs, $threes, $fours, $straight, $flush);

for ($i=0; $i<4; $i++) {
    ${"suits$n"}[$i] = 0; // Initialise suits array to zero
}
for ($i=0; $i<13; $i++) {
    ${"matched$n"}[$i] = 0; // Initialise matched array to zero
}

${"orghand$n"} = ${"hand$n"}; // Make a copy ofthe initial hand

En zo gaat het nog 271 regels verder...

[Anoniem: 49627]

ZanderZ schreef op maandag 11 juni 2007 @ 10:13:
Dit kwam ik laatst tegen in een (PHP) pokerscript
[..]

Ik nie snap nie: wat is nu het bezwaar?

[Janoz]

Mwah, de paar dingen die ik zie zijn en compleet niet genormaliseerde database en variabele variabelen. Dat laatste is sowieso verwonderlijk aangezien de ontwikkelaar wel weet wat arrays zijn. (Blijkbaar niet begrepen dat ze ook meer dimensionaal gebruikt kunnen worden)

[Creepy]

Ik gok het gebruik van de globals in combinatie met variabele variabelen.

PHP:

global ${"hand$m"};

Dus maak een globale variabele aan die als naam hand<nummer> heeft.
Vervolgens worden in het tweede deel op dezelfde manier suits<nummer>, matched<nummer> en orghand<nummer> gemaakt.

offtopic:
Snelle Janoz

[ Voor 5% gewijzigd door Creepy op 11-06-2007 10:23 ]

[bobo1on1]

Ik ben in vba iets vreemds tegengekomen, stel je doet dit:

Visual Basic:

Dim test As String
test = False
MsgBox test

Dan zou je een msgbox verwachten met een melding als "False", wat ik te zien kreeg was iets anders:

[Alex)]

Zou Word/VBA niet gewoon een error moeten triggeren zoals 'invalid type' o.i.d.? (Een boolean toepassen op een string is een type mismatch)

[.oisyn]

Office is ruk wat dat betreft. Alles is gelocalized, tot aan de functienamen in Excel aan toe. Enorm irritant als je CSV files genereert om geimporteerd te laten worden door Excel

[HawVer]

.oisyn schreef op maandag 11 juni 2007 @ 19:22:
Office is ruk wat dat betreft. Alles is gelocalized, tot aan de functienamen in Excel aan toe. Enorm irritant als je CSV files genereert om geimporteerd te laten worden door Excel

Net zo ruk als de taal Nederlands in Visual Studio. Dan krijg je allemaal vage errormeldingen van mensen die zich in allerlei bochten moesten wringen om er een nederlandse melding uit te krijgen.

[.oisyn]

HawVer schreef op maandag 11 juni 2007 @ 19:50:
[...]

Net zo ruk als de taal Nederlands in Visual Studio

Ik wist niet eens dat dat bestond
Verder snap ik je laatste zin niet zo

[ Voor 11% gewijzigd door .oisyn op 11-06-2007 19:54 ]

[Jaap-Jan]

.oisyn schreef op maandag 11 juni 2007 @ 19:53:
[...]

Ik wist niet eens dat dat bestond
Verder snap ik je laatste zin niet zo

Dat de compiler in het Nederlands wazige foutmeldingen uitschijt. Maargoed, dat is C++ toch al niet vreemd.

C++ doesn't have a compiler, it has a complainer.

Tot zover mijn rant op C++ .

[Robtimus]

Alex) schreef op maandag 11 juni 2007 @ 19:20:
Zou Word/VBA niet gewoon een error moeten triggeren zoals 'invalid type' o.i.d.? (Een boolean toepassen op een string is een type mismatch)

Dat is het punt (probleem?) in een aantal programmeertalen zoals VB, maar ook Java: alles is te converteren naar een string.

In Java bv werkt het volgende gewoon:

Java:

String s = 4 + 5.6 + "string" + new Object() + true + null;

Dit geeft als output 9.6stringjava.lang.Object@87816dtruenull (de substring tussen @ en true kan verschillen). Het wordt nml van links naar rechts opgeteld, en zodra een van de operands een string is wordt het geheel daarna een string. Voor objecten houdt dat in dat String.valueOf() wordt aangeroepen voor dat object. Deze geeft de string "null" terug als het object null is, anders de return waarde van de toString() method van het object.

In VB werkt het op een soortgelijke manier.

[Anoniem: 63780]

Zo, vandaag eens had zitten werken om een php-website aan te passen, kwam ik het volgende tegen:

PHP:

    function GetUserId()
    {
        $rs=@mysql_query("select max(user_id) from users");
        if(@mysql_num_rows($rs)==0)
        {
            return 1;
        }   
        else
        {
            $uid=@mysql_result(0,0)+1;  
            return uid;
        }   
    }

    function AddUser()
    {       
        @mysql_query("insert into users set user_id='".$this->GetUserId()."',user_name='".$_REQUEST['Username']."',pwd='".$_REQUEST['Passwd']."'") or die(@mysql_error());
        $this->CheckUserExists();
    }

Geen idee van wie deze code is, en na wat (geautomatiseerd ) zoeken bleek echter dat deze ongelooflijke constructie 14 keer gebruikt wordt in de website Niet dat ik het aanpas, wordt ik (nog) niet voor betaald

[Devion]

Onder het mom van vage code gebruik:
(Dit is een commercieel project waar toch 6 devs op zitten)

C#

code:

 if (null == <var>) { ... }

Is natuurlijk beetje mieren<peep> maarja, standaard is 't niet tegenover andere class files.

En dan nog zo'n geintje met Datasets...

code:

  DataSet a1 = DAL.FetchSet("<SP>");
  List<DataSet> Sets = new List<DataSet>;
  foreach (DataRow dR in A1.Tables[0].Rows) 
  {
      DataSet tmp = DAL.FetchSet(dR["tableid"].ToString());
      Sets.Add(tmp);
  }

Normale code eh? Probleem was met dit dat het bijna 3 gig naar binnen aan het halen was, werkt perfect op een workstation met 4GB, Op de server (ook maar 4GB ) samen met MSSQL was het swap file'tje zo vol =)

[.oisyn]

Jaap-Jan schreef op maandag 11 juni 2007 @ 20:00:
[...]
Dat de compiler in het Nederlands wazige foutmeldingen uitschijt. Maargoed, dat is C++ toch al niet vreemd.

[...]
Tot zover mijn rant op C++ .

Elke compiler bij elke taal geeft foutmeldingen bij code die niet klopt (en anders werk je in een kuttaal). Als je in C++ slechts die features gebruikt die andere talen ook ondersteunen zijn de foutmeldingen niet waziger dan bij die andere talen. Het is een beetje loos om C++ foutmeldingen (die al heel zinnig zijn bij het gebruik van STL-Filt en goede toepassing van SFINAE) af te rekenen op de manier waarop ongekende features zoals templates nou eenmaal werken.

Overigens krijgt C++09 concepts, een manier om in de taal te specificeren wat men nu doet met dmv documentatie (bijv: het template argument voor std::set moet less-than-comparable zijn), wat naast het feit dat de taal hier nóg beter van wordt , uiteraard zorgt voor cleanere code en betere foutmeldingen

[JKVA]

Devion schreef op dinsdag 12 juni 2007 @ 00:08:
Onder het mom van vage code gebruik:
(Dit is een commercieel project waar toch 6 devs op zitten)

C#

code:

if (null == <var>) { ... }

Je doelt op dat de null voor de == staat? Dat is een vrij gangbare conventie hoor. Ik vind het persoonlijk niet echt duidelijk, maar het idee eracter is dat als je per ongeluk één = typt, er geen assignment gedaan wordt, maar de compiler gaat klagen.

[Anoniem: 26306]

JKVA schreef op dinsdag 12 juni 2007 @ 07:38:

Je doelt op dat de null voor de == staat? Dat is een vrij gangbare conventie hoor. Ik vind het persoonlijk niet echt duidelijk, maar het idee eracter is dat als je per ongeluk één = typt, er geen assignment gedaan wordt, maar de compiler gaat klagen.

Ik vind het ook geen slechte code. Dat is best vergelijkbaar met bijvoorbeeld:

Java:

if ("tekst".equals(str)) {
   // doe iets
}

Om zonder extra controle een NullPointerException te voorkomen. Het ziet er in eerste instantie apart uit, maar het is eigenlijk een heel simpel standaard trucje.

[JKVA]

Anoniem: 26306 schreef op dinsdag 12 juni 2007 @ 08:26:
[...]

Ik vind het ook geen slechte code. Dat is best vergelijkbaar met bijvoorbeeld:

Java:

if ("tekst".equals(str)) {
   // doe iets
}

Om zonder extra controle een NullPointerException te voorkomen. Het ziet er in eerste instantie apart uit, maar het is eigenlijk een heel simpel standaard trucje.

Idd, dat is ook een handige manier. Ik vind het alleen een beetje aparte syntax, als je het op zijn Nederlands leest:
"Als tekst lijkt op de invoer..." ofwel "Als de invoer lijkt op deze tekst...".
Dan vind ik de tweede beter.

Maar als ik eenmaal op nullwaarden ga checken, dan zijn dit de eerste dingen die ik verander.

[MBV]

waarom doe je niet str.equals("tekst"), ik mag toch aannemen dat dat ook werkt? Klinkt logischer imho

edit:
en dat om 3 uur 's middags Naja, vannacht voor geen meter geslapen omdat het zo warm/benauwd was

[ Voor 37% gewijzigd door MBV op 12-06-2007 15:16 ]

[BalusC]

Als str null is, dan krijg je geheid een NPE.

[JeroenTheStig]

Ik kwam vanmiddag ook een leuke tegen:

Java:

if ((oldValue==null)?true:(!oldValue.equals(newValue))) {
  // etc
}

ik moest even heel goed kijken wat hier nou gebeurde, maar het is gewoon een if-else-clause in een if-clause

waarschijnlijk wist de programmeur niet dat de tweede clause van een OR (||) statement niet uitgevoerd wordt wanneer de eerste clause al true oplevert.

Ik zou het in ieder geval als volgt hebben geschreven:

Java:

if (oldValue == null || !(oldValue.equals(newValue))) {
  // etc
}

edit

zoals mijn onderbuurman ook al zei

[ Voor 42% gewijzigd door JeroenTheStig op 12-06-2007 16:24 ]

[Soultaker]

Het is equivalent aan:

Java:

if (oldValue == null || !oldValue.equals(newValue)) {
    // etc
}

Oftewel: doe iets als oldValue verschilt van newValue. Inderdaad een vrij hopeloze manier om dat te schrijven.

[Zyppora]

Ik heb wel eens een vraag gehad van iemand hoe hij in PHP '/dev/random' fatsoenlijk uit kon lezen (blijkbaar hingen daar nogal wat haken en ogen aan, ivm. EOF etc.). Toen ik hem vroeg waar hij dat uberhaupt voor nodig had, antwoordde hij doodserious dattie een pokerscript ging maken en uit ALLE (!!!) mogelijke decks een random selectie maakte! Daar had-ie dan een random getal tussen 1 en (ik dacht) 8 * 10^67 voor nodig of zo, en rand() ging maar tot MAX_INTEGER (wat neerkomt op 4.2 * 10^9).

Ik heb mijn lach gelukkig in kunnen houden, en hem verteld hoe je dat beter aan kon pakken (dus bijhouden welke kaarten er al gegeven zijn).

[Anoniem: 37526]

Is MAX_INTEGER niet 1 * 2^32?

[Creepy]

Aangezien een standaard integer in PHP signed is, is MAX_INTEGER dus niet 2^32 Ook draait PHP op andere systemen dan i386 clones zoals 64bit machines..... wat is MAX_INTEGER dan?

[Salandur]

Boktor schreef op dinsdag 12 juni 2007 @ 16:16:
Ik kwam vanmiddag ook een leuke tegen:

Java:

if ((oldValue==null)?true:(!oldValue.equals(newValue))) {
  // etc
}

ik moest even heel goed kijken wat hier nou gebeurde, maar het is gewoon een if-else-clause in een if-clause

waarschijnlijk wist de programmeur niet dat de tweede clause van een OR (||) statement niet uitgevoerd wordt wanneer de eerste clause al true oplevert.

Ik zou het in ieder geval als volgt hebben geschreven:

Java:

if (oldValue == null || !(oldValue.equals(newValue))) {
  // etc
}

edit

zoals mijn onderbuurman ook al zei

Met goede utility classes zoals org.apache.commons.lang.ObjectUtils kan je het volgende doen:

Java:

if (ObjectUtils.equals(oldValue, newValue)) {
  // etc
}

geen last van eventuele NPE's

[Anoniem: 37526]

Creepy schreef op dinsdag 12 juni 2007 @ 16:56:
Aangezien een standaard integer in PHP signed is, is MAX_INTEGER dus niet 2^32 Ook draait PHP op andere systemen dan i386 clones zoals 64bit machines..... wat is MAX_INTEGER dan?

Dat is correct, maar de door Zyppora aangehaalde 4.2 * 10^9 is basicly 2^32, met eventueel een bit minder (LSB).

[Voutloos]

Tja, ik neem aan dat iedereen in dit topic wel weet waar bepaalde grenswaardes vandaan komen, dus dat je weet dat 4,nogiets miljard overeenkomt met 2³² is niet zo heel stoer.

[.oisyn]

Overigens vergeten jullie voor het gemak nu even de -1

max 32 bits unsigned int = 2³²-1 (4.294.967.295)
max 32 bits signed (two's complement) int = 2³¹-1 (2.147.483.647)

[ Voor 8% gewijzigd door .oisyn op 12-06-2007 17:41 ]

[Anoniem: 37526]

.oisyn schreef op dinsdag 12 juni 2007 @ 17:29:
Overigens vergeten jullie voor het gemak nu even de -1

max 32 bits unsigned int = 2³²-1 (4.294.967.295)
max 32 bits signed (two's complement) int = 2³¹-1 (2.147.483.647)

Anoniem: 37526 schreef op dinsdag 12 juni 2007 @ 17:14:
[...]
met eventueel een bit minder.

[EdwinG]

Anoniem: 37526 schreef op dinsdag 12 juni 2007 @ 18:06:
[...]

[...]

Die bit is niet -1, maar het halveren (signed of niet)

[roy-t]

Visual Basic:

For i = 0 to i = list.listcount
'doe iets
Next i

Vandaag gepresteert om deze geweldige code te schrijven, er een half uur naar te kijken, en er toen pas achter te komen wat ik fout deed. Mooie is dat dit in zowel C# als VB6 geen foutmelding geeft, maarja het is natuurlijk valid code, alleen gebeurt er niks

Ook heb ik er af en toe een handje van om in VB het geweldige volgende te doen

Visual Basic:

'nu gaan we sorteren op datum, maar soms zit er een leeg record in het bestand waardoor datum_
' 00:00:00 is, wat natuurlijk niet valid is, en daarom een error geeft
'En daarom:
On error resume next  ':P eigenlijk zouden ze dit zinnetje moeten verbieden
'Doe nog wat dingen met een mogelijk niet bestaande datum

echt slecht, en soms doe ik het ook iets te veel (oops databaseconnectie reset, ach on error resume next, huppa wegschrijven dat lege bestand )

[ Voor 0% gewijzigd door een moderator op 12-06-2007 18:31 . Reden: Code tags gefix0red ]

[Anoniem: 198895]

On error resume next is idd niet zo netjes maar zelfs op msdn van microsoft staan er genoeg voorbeelden waarbij ze het functioneel gebruiken om een probleem op te lossen dus je bent in ieder geval niet de enigste die het misbruikt.

[flowerp]

.oisyn schreef op dinsdag 12 juni 2007 @ 00:32:
Overigens krijgt C++09

offtopic:
De grote vraag blijft echter, welke twee cijfers komen er voor die 09? Wordt de 20 of 30?

[Zyppora]

@diegenen met opmerkingen over MAX_INTEGER:
Het kwam er in elk geval op neer dat de MAX_INTEGER (zelfs op 128-bits systemen ) niet genoeg was voor de app van die persoon (waar mijn alternatieve oplossing aan een int tot 52 genoeg had). Wat de precieze waarde van MAX_INTEGER is, tja, da's inderdaad om over te speculeren.

Anoniem: 198895 schreef op dinsdag 12 juni 2007 @ 18:56:
On error resume next is idd niet zo netjes maar zelfs op msdn van microsoft staan er genoeg voorbeelden waarbij ze het functioneel gebruiken om een probleem op te lossen dus je bent in ieder geval niet de enigste die het misbruikt.

[insert flauwe windows grap]

[Kwistnix]

Salandur schreef op dinsdag 12 juni 2007 @ 16:58:
[...]


Met goede utility classes zoals org.apache.commons.lang.ObjectUtils kan je het volgende doen:

Java:

if (ObjectUtils.equals(oldValue, newValue)) {
  // etc
}

geen last van eventuele NPE's

Ik ga er altijd (onterecht?) vanuit dat wanneer equals() overridden wordt, dat dit ook correct gedaan wordt en er in de implementatie tegen een NPE gewaakt wordt.

[ Voor 38% gewijzigd door Kwistnix op 13-06-2007 10:10 ]

[Anoniem: 49627]

@FallenAngel666
Kijk nog eens goed


edit:
Was dan vast iets met 'koffie' en 'gebrek'


edit2:

FallenAngel666 schreef op woensdag 13 juni 2007 @ 10:08:
Ik ga er altijd (onterecht?) vanuit dat wanneer equals() overridden wordt, dat dit ook correct gedaan wordt en er in de implementatie tegen een NPE gewaakt wordt.

Waar je alleen niet tegen kunt waken bij een correcte implementatie van equals is dat instantie null is. Dus de instantie waar je equals over aanroept ('oldValue' in het eerder genoemde voorbeeld). En dat probleem heb je niet bij de oplossing van salandur

[ Voor 118% gewijzigd door Anoniem: 49627 op 13-06-2007 10:17 ]

[Kwistnix]

Anoniem: 49627 schreef op woensdag 13 juni 2007 @ 10:10:
@FallenAngel666
Kijk nog eens goed

Verkeerde persoon gequote

Edit: koffie infuus aanleggen staat nog op m'n TODO lijstje

Edit 2: Helemaal waar natuurlijk, maar dat is dan tenminste wel je eigen domme fout
Wat betreft utility classes heb ik nogal gauw last van het NIH complex

[ Voor 39% gewijzigd door Kwistnix op 13-06-2007 10:23 ]

[Creepy]

De || zit erin om te voorkomen dat je geen NPE krijgt op oldValue. Als oldValue null is kan je equals() niet eens aanroepen
Dat je een null value aan equals() moet kunnen doorgeven lijkt mij niet meer dan logisch.

edit: lekker overbodig dus gezien de verkeerde quote die nu is aangepast.

offtopic:
Damn.. ik moet ook aan de koffie.. spuit 11 met 25 minuten......

[ Voor 26% gewijzigd door Creepy op 13-06-2007 10:37 ]

[Kwistnix]

Nou OT dan maar weer:

Java:

public void someMethod(Type param...){
  assert param != null : "Parameter 'param' may not be null!";
}

Wordt in ons huidige project gebruikt als pre-condition guard, omdat "gegarandeerd wordt dat onze code ten alle tijden wordt uitgevoerd met assertions enabled".

[Woy]

FallenAngel666 schreef op woensdag 13 juni 2007 @ 11:04:
Nou OT dan maar weer:

Java:

public void someMethod(Type param...){
  assert param != null : "Parameter 'param' may not be null!";
}

Wordt in ons huidige project gebruikt als pre-condition guard, omdat "gegarandeerd wordt dat onze code ten alle tijden wordt uitgevoerd met assertions enabled".

Als het een public functie in een library is dan zie ik je punt. Maar anders zie ik er het probleem niet echt van. Al is het waarschijnlijk netter om gewoon iets van een InvalidParameterException te gooien.

[remco_k]

therat10430 schreef op dinsdag 12 juni 2007 @ 18:29:
Ook heb ik er af en toe een handje van om in VB het geweldige volgende te doen

Visual Basic:

...
On error resume next  ':P eigenlijk zouden ze dit zinnetje moeten verbieden
...

echt slecht, en soms doe ik het ook iets te veel (oops databaseconnectie reset, ach on error resume next, huppa wegschrijven dat lege bestand )

Slecht indeed. Ik noem dat struisvogel code.
'Heeej, daar gaat iets mis, weet je wat, ik steek m'n kop in het zand en doe net alsof het toch goed ging'.
Waardeloos. Ik zie in andermans projecten regelmatig dit:

C++:

try {
         // doe iets mateloos complex op deze plek, liefst met 300 regels watervalcode achter elkaar en 20 levels if () genest.
} catch (...) {
         //ach, er ging iets fout
         return;
}

Waardeloos, om te beginnen is het voor de gebruiker van de software niet duidelijk dat er iets fout gaat, laat staan wat er fout gaat.
Zelfs iemand die dit debugged zal toch echt eerst even echte foutafvanging moeten maken:

C++:

try {
         // doe iets mateloos complex op deze plek, liefst met 300 regels waterval code achter elkaar en 20 levels if () genest.
} catch (Exception &e) {
         //ach, er ging iets fout
         // toon de e.Message aan de gebruiker of save in rapport
}

[Kwistnix]

rwb schreef op woensdag 13 juni 2007 @ 11:09:
[...]

Als het een public functie in een library is dan zie ik je punt. Maar anders zie ik er het probleem niet echt van. Al is het waarschijnlijk netter om gewoon iets van een InvalidParameterException te gooien.

Wij zijn een framework aan't ontwikkelen.

[remco_k]

Owja, iets stouts wat ik vroeger veel fout deed met de meest vreemde gevolgen:

C++:

struct MyStruct {
    AnsiString asText;
    int iDit,iDat;
    short sZus, sZo;
    ...
}

// even verderop in een functie:
MyStruct sVanMij;
ZeroMemory(&sVanMij, sizeof(MyStruct) );  

Als je je fout dus niet door hebt is er geen compiler die je hiervoor behoed en het lijkt ook nog eens gewoon goed te werken. Je krijgt de meest vreemde problemen (elders in je app) omdat je een VCL object hebt 'gezeromemoried'.

[ Voor 35% gewijzigd door remco_k op 13-06-2007 11:28 ]

[.oisyn]

flowerp schreef op dinsdag 12 juni 2007 @ 22:13:
[...]

offtopic:
De grote vraag blijft echter, welke twee cijfers komen er voor die 09? Wordt de 20 of 30?

Die 09 staat voor het 9e millennium .
Seriously though, het committee snapt een nieuwe update erg belangrijk is en daardoor worden er al erg veel knopen doorgehakt. Ik heb er iig het volste vertrouwen in dat C++0x ook echt in 2009 komt (en ik kan niet wachten, want het is V.E.T . Concepts, variadic templates, constant expressions, rvalue references, inheriting/delegating ctors, custom initializer lists, threading...)

[ Voor 42% gewijzigd door .oisyn op 13-06-2007 11:49 ]

[brama]

remco_k schreef op woensdag 13 juni 2007 @ 11:25:
Owja, iets stouts wat ik vroeger veel fout deed met de meest vreemde gevolgen:

C++:

struct MyStruct {
    AnsiString asText;
    int iDit,iDat;
    short sZus, sZo;
    ...
}

// even verderop in een functie:
MyStruct sVanMij;
ZeroMemory(&sVanMij, sizeof(MyStruct) );  

Als je je fout dus niet door hebt is er geen compiler die je hiervoor behoed en het lijkt ook nog eens gewoon goed te werken. Je krijgt de meest vreemde problemen (elders in je app) omdat je een VCL object hebt 'gezeromemoried'.

Wat is hier fout aan? Je kunt een structje toch gewoon overschrijven met nullen? Nou ontgaat de afkorting 'VCL' hier mij volkomen, dus ik neem aan dat het daar mee te maken heeft.

[.oisyn]

POD types kun je overschrijven met nullen ja, objecten met non-trivial constructors echter niet. Zoals je wel kunt raden heeft AnsiString geen trivial constructor.

C++:

struct Foo
{
    int * ptr;

    Foo() { ptr = new int[123]; }
};

int main()
{
    Foo foo;  // roept Foo::Foo() aan, foo.ptr wijst naar een array van 123 ints
    memset(&foo, 0, sizeof(foo)); // oeps, foo.ptr is nu weer 0, memory leak en foo werkt voor de rest waarschijnlijk niet meer.
}

[ Voor 66% gewijzigd door .oisyn op 13-06-2007 11:54 ]

[remco_k]

brama schreef op woensdag 13 juni 2007 @ 11:41:
[...]


Wat is hier fout aan? Je kunt een structje toch gewoon overschrijven met nullen? Nou ontgaat de afkorting 'VCL' hier mij volkomen, dus ik neem aan dat het daar mee te maken heeft.

AnsiString is een VCL object (lees: klasse).
Die kan je op zich prima naar 0 overschrijven, maar of dat object dat nou echt leuk vind...
Neem eens een klasse (met functies e.d.) die je zelf hebt gemaakt, doe eens een ZeroMemory daarop... Afhankelijk van de manier waarop je die klasse hebt maakt is de kans redelijk hoog dat je bij gebruik van die klasse daarna wat vreemde problemen krijgt. Daarbij, je hoort dat gewoon niet te doen... :-)

[ Voor 4% gewijzigd door remco_k op 13-06-2007 12:48 ]

[Robtimus]

FallenAngel666 schreef op woensdag 13 juni 2007 @ 11:04:
Nou OT dan maar weer:

Java:

public void someMethod(Type param...){
  assert param != null : "Parameter 'param' may not be null!";
}

Wordt in ons huidige project gebruikt als pre-condition guard, omdat "gegarandeerd wordt dat onze code ten alle tijden wordt uitgevoerd met assertions enabled".

Ik mag hopen dat wie dat heeft geschreven nooit zijn SCJP heeft gehaald, of nog zal halen.

Regel 1 voor assertions: nooit gebruiken voor de invoer controle van public methods.

[Kwistnix]

IceManX schreef op woensdag 13 juni 2007 @ 13:51:
[...]

Ik mag hopen dat wie dat heeft geschreven nooit zijn SCJP heeft gehaald, of nog zal halen.

Regel 1 voor assertions: nooit gebruiken voor de invoer controle van public methods.

Precies. Wil je dat even komen uitleggen hier?

[JKVA]

FallenAngel666 schreef op woensdag 13 juni 2007 @ 14:15:
[...]


Precies. Wil je dat even komen uitleggen hier?

Nou, ik heb ook mijn SCJP gehaald (met 90% ofzo), maar wist dat ook niet meer op te dreunen. Maar goed, ik gebruik asserts nooit meer, simpelweg omdat het teveel gezeik is en mensen er niet mee overweg kunnen.

Ik heb liever code zoals een if die altijd draait, zowel in tests als in productie. Dat maakt de geldigheid van je unit tests ook beter. Net zoals dat je je unit tests altijd moet draaien op het fijnste loggingniveau. Naar mijn idee maken asserts het moeilijker om het runtime gedrag van de code te voorspellen.

[Anoniem: 49627]

JKVA schreef op woensdag 13 juni 2007 @ 14:50:
Net zoals dat je je unit tests altijd moet draaien op het fijnste loggingniveau.

Oh appart, ik heb juist ten tijde van de unit tests de logging volledig uit staan. Waarom ga je juist voor het fijnste niveau?

[Robtimus]

JKVA schreef op woensdag 13 juni 2007 @ 14:50:
Naar mijn idee maken asserts het moeilijker om het runtime gedrag van de code te voorspellen.

IMO gebruik je asserts dan verkeerd.

De hele bedoeling van asserts is controleren of aannamen die jij hebt gemaakt kloppen. Bijvoorbeeld een private method die een positieve integer verwacht, om te kijken of die niet per ongeluk een negatieve integer krijgt. Ik zie het dan ook vooral als manier om programeerfouten te kunnen opsporen.

Asserts horen dus de hele control flow niet aan te passen, met als uitzondering een error geven als een assert failed. Maar dat betekent dat een aanname fout is en je daar dus programmatisch (is dat een woord? ) omheen moet werken, bv met ifs.


Zelf heb ik trouwens ook nog nooit een assert gebruikt, ondanks een 100% score op SCJP 1.4.

offtopic:
Ik wil 1.5 ook nog halen, heb het boek ook al, maar die wil ik bijna tegelijk doen met SCWCP. En daar ben ik nog niet goed genoeg in.

[Janoz]

Anoniem: 49627 schreef op woensdag 13 juni 2007 @ 14:56:
[...]
Oh appart, ik heb juist ten tijde van de unit tests de logging volledig uit staan. Waarom ga je juist voor het fijnste niveau?

Met logging uit heb je niet een volledige coverage. Je mist namelijk een boel loging code. Denk aan de spullen die je binnen een ifje met " log.isDebugEnabled() " hebt staan.

[ Voor 10% gewijzigd door Janoz op 13-06-2007 20:33 ]

[JKVA]

Anoniem: 49627 schreef op woensdag 13 juni 2007 @ 14:56:
[...]
Oh appart, ik heb juist ten tijde van de unit tests de logging volledig uit staan. Waarom ga je juist voor het fijnste niveau?

Voor statements als if (log.isDebugEnabled()) { /* code die potentieel fout kan gaan NPE ofzo */ }

[JKVA]

IceManX schreef op woensdag 13 juni 2007 @ 17:17:
[...]

IMO gebruik je asserts dan verkeerd.

De hele bedoeling van asserts is controleren of aannamen die jij hebt gemaakt kloppen. Bijvoorbeeld een private method die een positieve integer verwacht, om te kijken of die niet per ongeluk een negatieve integer krijgt. Ik zie het dan ook vooral als manier om programeerfouten te kunnen opsporen.

Asserts horen dus de hele control flow niet aan te passen, met als uitzondering een error geven als een assert failed. Maar dat betekent dat een aanname fout is en je daar dus programmatisch (is dat een woord? ) omheen moet werken, bv met ifs.


Zelf heb ik trouwens ook nog nooit een assert gebruikt, ondanks een 100% score op SCJP 1.4.

offtopic:
Ik wil 1.5 ook nog halen, heb het boek ook al, maar die wil ik bijna tegelijk doen met SCWCP. En daar ben ik nog niet goed genoeg in.

SCWCD is niet moeilijk. Je moet ff kijken in de goals wat er vereist is. Ze verwachten niet dat je die dikke pil van Head First uit je hoofd kent.

http://www.sun.com/training/catalog/courses/CX-310-081.xml

Mijn ervaring is, tenminste dat werkte met SCBCD en SCDJWS goed, is het lezen van de spec. De onderwerpen komen qua terminologie vrij goed overeen met elkaar en bovendien is er bij dergelijke zaken maar one and only holy thing; de spec.

En nee, specs van Sun zijn prima te lezen, in tegenstelling tot die van o.a. W3C en zo.

[Anoniem: 49627]

JKVA schreef op woensdag 13 juni 2007 @ 21:21:
Voor statements als if (log.isDebugEnabled()) { /* code die potentieel fout kan gaan NPE ofzo */ }

Ja ik denk dan toch dat je teveel in je debug statements hebt staan. Ik ben van mening dat je het uit moet hebben staan omdat je anders je debugging als onderdeel van je programma moet gaan zien en dus dient op te nemen in je test. Dat kan volgens mij niet de bedoeling zijn.

edit: Sterker nog: je zult elke log level appart als test-case op moet nemen. Wanneer je namelijk het fijnste log-level als maat aan houdt dan is je applicatie enkel getest op dat log-level en dat is hoogstwaarschijnlijk ongelijk aan productie log-levels. Ik denk dat ik het dus zeer oneens moet zijn met je eerdere stelling.

[ Voor 25% gewijzigd door Anoniem: 49627 op 13-06-2007 22:21 ]

[NetForce1]

Anoniem: 49627 schreef op woensdag 13 juni 2007 @ 22:17:
[...]
Ja ik denk dan toch dat je teveel in je debug statements hebt staan. Ik ben van mening dat je het uit moet hebben staan omdat je anders je debugging als onderdeel van je programma moet gaan zien en dus dient op te nemen in je test. Dat kan volgens mij niet de bedoeling zijn.

edit: Sterker nog: je zult elke log level appart als test-case op moet nemen. Wanneer je namelijk het fijnste log-level als maat aan houdt dan is je applicatie enkel getest op dat log-level en dat is hoogstwaarschijnlijk ongelijk aan productie log-levels. Ik denk dat ik het dus zeer oneens moet zijn met je eerdere stelling.

Als het goed is doorlopen je tests al die paden al, dus daar hoef je dan geen extra tests voor te schrijven toch? Het is alleen maar makkelijk om dat soort fouten zsm te zien.
Ik snap ook niet waarom je elk level apart zou moeten testen, als je je logger instelt op het laagste level pakt ie toch ook alle bovenliggende levels mee .

[Anoniem: 49627]

NetForce1 schreef op woensdag 13 juni 2007 @ 22:33:
Als het goed is doorlopen je tests al die paden al, dus daar hoef je dan geen extra tests voor te schrijven toch? Het is alleen maar makkelijk om dat soort fouten zsm te zien.
Ik snap ook niet waarom je elk level apart zou moeten testen, als je je logger instelt op het laagste level pakt ie toch ook alle bovenliggende levels mee .

Omdat je er vanuit gaat dat door je verschillende loglevels je state van je applicatie anders is. Zet je logging minder fijn op een productie machine dan ten tijde van de uitvoer van de tests dan verschilt dus simpelweg de paden die doorlopen worden. Dat is met een unit test alles behalve de bedoeling, je krijgt dan immers niet meer de juiste feedback.

[NetForce1]

Anoniem: 49627 schreef op woensdag 13 juni 2007 @ 22:42:
[...]
Omdat je er vanuit gaat dat door je verschillende loglevels je state van je applicatie anders is. Zet je logging minder fijn op een productie machine dan ten tijde van de uitvoer van de tests dan verschilt dus simpelweg de paden die doorlopen worden. Dat is met een unit test alles behalve de bedoeling, je krijgt dan immers niet meer de juiste feedback.

Het lijkt me dat je de state van je applicatie niet, of zo weinig mogelijk, af wilt laten hangen van je loglevel. Op het moment dat dat het geval is kun je dat specifieke deel van de code met verschillende loglevels testen en de rest gewoon op minimaal zetten.

edit: minimaal als in fijnste dus (of ALL bij gebruik van log4j)

[ Voor 4% gewijzigd door NetForce1 op 14-06-2007 09:46 ]

[JKVA]

NetForce1 schreef op woensdag 13 juni 2007 @ 22:56:
[...]

Het lijkt me dat je de state van je applicatie niet, of zo weinig mogelijk, af wilt laten hangen van je loglevel. Op het moment dat dat het geval is kun je dat specifieke deel van de code met verschillende loglevels testen en de rest gewoon op minimaal zetten.

Idd, met bijv log4j, maar ook met java logging of commons logging kun je gewoon het log level buiten je applicatie laten (maar dat wist je waarschijnlijk allang ). Debug code staat idd meestal niet veel zinnigs in, maar een regel zoals log.debug(collection.size()) kan in theorie een nullpointer geven, dus je wil die code a) meenemen en b) uitsluiten van de flow als het log level niet klopt. En dat laatste doe je dus met zo'n if statement.

Ik heb vroeger ook weleens voor debugging een soort XML print ding gemaakt die binnenkomende XML op een beetje fatsoenlijke manier wegschreef. Dat was een stuk code van 50 regels ofzo met een stel lussen en zo en daar kan vrij veel misgaan, zoals outofbounds en nullpointerexceptions.

Kwestie van op het fijnste niveau testen.

@mark Je hebt wel een punt dat je op productie niet in debugstand draait, daarom moet je ook gewoon op alle niveaus testen en dat is vrij gemakkelijk met continuum ofzo. Dan vind ik het geen probleem als hij de complete test suite doorloopt.

[Anoniem: 49627]

JKVA schreef op donderdag 14 juni 2007 @ 07:57:
[..]Debug code staat idd meestal niet veel zinnigs in, maar een regel zoals log.debug(collection.size()) kan in theorie een nullpointer geven, dus je wil die code a) meenemen en b) uitsluiten van de flow als het log level niet klopt. En dat laatste doe je dus met zo'n if statement..[..]

Ik vind het nog steeds niet zo'n sterk argument (en ik begrijp dat dit een triviaal voorbeeld is). Ik denk namelijk dat je in je debug statements eigenlijk altijd wel weet dat er geen exceptionele problemen optreden. Anders gezegd: debug statement mogen niet tot exceptionele situaties lijden. In je (triviale) voorbeeld 'log.debug(collection.size())' behoor je zeker te weten dat 'collection' niet null is. (Debug) logging blokken zijn statements die iets horen te zeggen over de state van je applicatie en behoren geen functionele calls te maken. Ze hebben dus geen plaats in een unit test.

Binnen de scope van een integratie test lijkt me logging enabled wel wenselijk. Maar fully enabled in een unit test klinkt echt als een bad-practise.

[Anoniem: 49627]

En deze kwam ik net tegen:

Java:

try {
    Integer id = new Integer(someString);
    if (id.intValue() == 0) {
        throw new NumberFormatException("0 (zero) value not allowed.");
    }
} catch (NumberFormatException e) {
    //doe dingen
}

[.oisyn]

Tja, opzich... het alternatief kan zijn:

Java:

boolean inputOk;

try
{
    inputOk = (Integer.valueOf(someString) != 0);
}
catch(NumberFormatException e)
{
    inputOk = false;
}

if (!inputOk)
   // doe dingen

[ Voor 1% gewijzigd door .oisyn op 14-06-2007 11:16 . Reden: true :) ]

[Anoniem: 49627]

.oisyn schreef op donderdag 14 juni 2007 @ 11:06:
Tja, opzich... het alternatief is kan zijn:
[..]

Er werd direct weer gesmeten...

Overigens is het logischer om na het parsen van de string (waar oorspronkelijk de numberformatexception uit komt) gewoon een if-je op te nemen met deze controle. Dus buiten de try-catch.

[JKVA]

Anoniem: 49627 schreef op donderdag 14 juni 2007 @ 10:21:
[...]
Ik vind het nog steeds niet zo'n sterk argument (en ik begrijp dat dit een triviaal voorbeeld is). Ik denk namelijk dat je in je debug statements eigenlijk altijd wel weet dat er geen exceptionele problemen optreden. Anders gezegd: debug statement mogen niet tot exceptionele situaties lijden. In je (triviale) voorbeeld 'log.debug(collection.size())' behoor je zeker te weten dat 'collection' niet null is. (Debug) logging blokken zijn statements die iets horen te zeggen over de state van je applicatie en behoren geen functionele calls te maken. Ze hebben dus geen plaats in een unit test.

En met een unit test ben je er zekerder van. Ik kom namelijk regelmatig code tegen die iets dergelijks zegt, bijvoorbeeld na het ophalen van een lijst uit een DAO. Als iemand iets in de DAO verandert waardoor deze null kan returnen, knalt je code.

Binnen de scope van een integratie test lijkt me logging enabled wel wenselijk. Maar fully enabled in een unit test klinkt echt als een bad-practise.

Ja, sorry, ik (en met mij veel te veel anderen) gebruiken de term weleens door elkaar. Met unit test doel ik doorgaans op JUnit. Als het gebruik integratietesten is, dan is het wel nuttig, in een (pure) unit test niet, daar heb je gelijk in.
Probleem is alleen dat ze vaak tegelijk gedraaid worden.

[roy-t]

Schreef net een leuk stukje code waarin ik 6 internet communication objecten moest controleren, ik weet niet of dit nu echt een slecht stukje code is, maar het ziet er iig leuk uit

Visual Basic 6:

'controle of de icFTPs klaar zijn
If frm_FTPTrans.icFTP.StillExecuting = False Then
    If frm_FTPTrans.icFTP2.StillExecuting = False Then
        If frm_FTPTrans.icFTP3.StillExecuting = False Then
           If frm_FTPTrans.icFTP4.StillExecuting = False Then
                If frm_FTPTrans.icFTP5.StillExecuting = False Then
                    If frm_FTPTrans.icFTP6.StillExecuting = False Then
                        bFTPReady = True
                    End If
                End If
            End If
        End If
    End If
End If

Hmm ik bedenk me nu dat ik het ook zo had kunnen oplossen omdat vb6 wel arrays van objecten toestaat!

Visual Basic 6:

bftpready = true
for i = 1 to 6
if frm_ftptrans.icftp(i).stillexecuting = true then bftpready = false
next i

Lang zo stoer niet natuurlijk

[brama]

Bovendien had je in het bovenste voorbeeld toch ook wel met *AND* kunnen werken, ipv 6 ifjes nesten?

In het onderste stukje code kun je verder nog breaken op het moment dat bftpready op false wordt gezet, om de volgende iteraties te besparen

En kun je in vbasic niet ipv 'bool = false' '!bool' (of 'not bool' ) gebruiken? Scheelt ook weer, en is een good practice.

[ Voor 20% gewijzigd door brama op 14-06-2007 13:17 ]

[Janoz]

De for constructie van VB laat het niet echt toe om er makkelijk eerder uit te springen. Een 'stoere' implementatie met c-style code (zoals java, C, C# en php) zou zijn:

code:

bftpready = true;
for (int i = 0;i<6 && bftpready;i++){
   bftpready = bftpready && !frm_ftptrans.icftp(i).stillexecuting;
}

Door de lazy evaluation zou je de test in de loop conditie ook weg kunnen laten omdat de laatste iteraties uberhaupt de stillexecuting niet meer aanroepen als er al een false gevonden is.

[.oisyn]

Die hele && is niet nodig, je kan ook wel assignen (aangezien de huidige waarde van bftpready altijd true is als die statement uitgevoerd wordt).

code:

for (int i = 0;i<6 && (bftpready = !frm_ftptrans.icftp(i).stillexecuting);i++)
   ;

[ Voor 51% gewijzigd door .oisyn op 14-06-2007 13:41 ]

[Janoz]

Klopt, is ook zo, maar normaal pas ik, voor de leesbaarheid, niet mijn if conditie aan. Daarnaast moet ik toegeven dat jouw voorstel zeker leuk is en een hog bikkel gehalte heeft ... Maar qua leesbaarheid toch wel ietsje te wensen over laat (misschien verdelen over meer regels ? )

Feit blijft dat Arrays grootschalig worden misbruikt in php (om eens even over iets heel anders te beginnnen)

[ Voor 16% gewijzigd door Janoz op 14-06-2007 13:52 ]

[.oisyn]

Janoz schreef op donderdag 14 juni 2007 @ 13:51:
(misschien verdelen over meer regels ? )

That kinda defeats the whole purpose