[alg] Slechtste programmeervoorbeelden deel 4

[Dnomaid]

jAnO! schreef op donderdag 15 oktober 2009 @ 15:50:
[...]

nee, want bij een exception wordt een nieuwe exception gegooid en bereik je nooit het return statement.

Over gekeken
Het is m'n dag niet.

[Standeman]

BobbyD82 schreef op donderdag 15 oktober 2009 @ 15:46:

code:

result = dao.addBar(bar);

als addBar een exception throwt, geef je gewoon true terug, en dat kan de bedoeling niet zijn?

Edit: verduidelijkt.

We have a winner, soort van
Als je method zo ziet verwacht je dat false wordt meegegeven indien er iets faalt. (alle clients van de class gaan daar ook vanuit).

Je mag verwachten dat wanneer er een method een boolean retourneerd ook false kan kan retourneren. Maar dat gaat in dit geval dus nooit gebeuren.

Ik ga 'm maar even aanpassen, kan ik gelijk die extra rollback eruit gooien!

[ Voor 13% gewijzigd door Standeman op 15-10-2009 15:57 ]

[Nick_S]

Als het goed gaat, geef je true terug, als het verkeerd gaat false en als het compleet fout gaat true?
* Nick_S is laat...

[ Voor 18% gewijzigd door Nick_S op 15-10-2009 15:56 ]

[YopY]

Ik voel me vies .

Java:

final String sql = "UPDATE Ranking_Rankings SET " +
        "@qcol = @question," +
        "@descol = @description," +
        "@endatecol = @enddate," +
        "@imagecol = @imageid," +
        "@displaycol = @display " +
        "WHERE @idcol = @id"
        .replace("@idcol", ID)
        .replace("@qcol", QUESTION)
        .replace("@descol", DESCRIPTION)
        .replace("@endatecol", ENDDATE)
        .replace("@imagecol", IMAGEID)
        .replace("@displaycol", DISPLAY_AFTER_VOTE)
        .replace("@id", Long.toString(ranking.getId()))
        .replace("@question", ranking.getQuestion().replace("'", "''"))
        .replace("@description", ranking.getDescription().replace("'", "''"))
        .replace("@enddate", dateFormat.format(ranking.getEndDate()))
        .replace("@imageid", Integer.toString(ranking.getImageId()))
        .replace("@display", (ranking.getDisplayAfterVote()) ? "1" : "0");

Heb geen zin om met regex te werken, en prepared statement werkt niet goed bij de insert - de getGeneratedKeys geeft daarbij een exception.

Maar dan nog.

[.oisyn]

Er mist een log error en/of exception als addBar() false retourneert.
En verder zal het wel alleen maar duidelijk zijn als je überhaupt de context snapt van het stuk code...

.edit:
ah de oplossing is al gepost

Standeman schreef op donderdag 15 oktober 2009 @ 15:54:
[...]

We have a winner, soort van
Als je method zo ziet verwacht je dat false wordt meegegeven indien er iets faalt. (alle clients van de class gaan daar ook vanuit).

Als je de method zo ziet verwacht je niets, want het is totaal niet duidelijk wat de semantische betekenis is van die boolean. En blijkbaar moet je zelfs een rollback() doen als addBar() false returnt, dus "het is niet gelukt" zal het dan wel niet zijn. Wellicht een "het mag niet", terwijl je de exceptions gebruikt voor de echt uitzonderlijke gevallen (database (verbinding) errors). En dan is de code op zich prima.

[ Voor 78% gewijzigd door .oisyn op 15-10-2009 16:19 ]

[jAnO!]

Standeman schreef op donderdag 15 oktober 2009 @ 15:54:
[...]

We have a winner, soort van
Als je method zo ziet verwacht je dat false wordt meegegeven indien er iets faalt. (alle clients van de class gaan daar ook vanuit).

Je mag verwachten dat wanneer er een method een boolean retourneerd ook false kan kan retourneren. Maar dat gaat in dit geval dus nooit gebeuren.

Ik ga 'm maar even aanpassen, kan ik gelijk die extra rollback eruit gooien!

Ehm, hij geeft toch gewoon false terug als bar niet wordt toegevoegd? Of een exceptie als er iets misgaat en true als het lukt. Lijkt me prima in orde.

[!null]

In principe is het fout ontwerp. Wat is het nut van true or false als er al met excepties wordt gegooid.
In de situatie waarin er niet met exceptions wordt gegooid is true of false veel te beperkt en wil je een foutcode retourneren. (maar dan ben je eigenlijk zelf foutafhandeling aan het maken).
Er zijn maar weinig situaties waarin iets niet kan lukken zonder dat dat meteen een error is.

[jAnO!]

!null schreef op donderdag 15 oktober 2009 @ 16:30:
In principe is het fout ontwerp. Wat is het nut van true or false als er al met excepties wordt gegooid.
In de situatie waarin er niet met exceptions wordt gegooid is true of false veel te beperkt en wil je een foutcode retourneren. (maar dan ben je eigenlijk zelf foutafhandeling aan het maken).
Er zijn maar weinig situaties waarin iets niet kan lukken zonder dat dat meteen een error is.

Er is heel veel nut voor true of false regardless van exceptions. Exceptions gebruiken voor programflow is zo verschrikkelijk fout dat het bijna pijn doet als ik het typ.

Exceptions gebruik je voor exceptional behaviour, dus als een netwerkverbinding faalt, een security token niet valid is, de database een fout returned.

In bovenstaande post weet ik niet wat context was, maar stel het was voeg postzegel toe aan verzameling,
true is gelukt, flase is niet gelukt (bijvoorbeeld omdat je em al had) is dat perfect nuttig om true false te hebben. Als de postzegelverzameling in de brand staat gooi je exception.

Errorcodes zijn heel heel heel erg....

[!null]

Dit is erg subjectief. Waarom vind je het geen exception als ie er al in zit? Ik zou zelf ook niet de user dood willen gooien met exceptions, ik zou in dat geval denk ik het niet eens melden, gewoon een functie zonder return waarde.
Maar los van het subjectieve, in jouw voorstel doe je een aanname, of doe je een stelling dat false == dubbele postzegel. Vind ik niet erg duidelijk, vind ik niet echt zelfuitleggend ofzo.

Errorcodes zijn vaak niet echt een goed idee nee, maar kan nuttig zijn in een bredere context. Ik werk nu ook aan een project waar errorcodes gebruikt worden, het kan lokaal best fijn werken maar belangrijker, ze zijn nodig omdat het geheel breder dan de context van de applicatie wordt gebruikt, ze gaan ook de deur uit via andere interfaces.

Verder is me niet helemaal duidelijk hoe je een programma flow bouwt met alleen true of false. Er zijn genoeg functies waarvan het toch iets ingewikkelder ligt. Ok, het is niet gelukt de postzegel toe te voegen, maar wat is er dan gebeurt wil je weten.. Is het album vol? Was ie te groot voor het hoesje? Was ie dubbel? Heeft je hond je postzegelverzameling verslonden? Is je verzameling gestolen? (null pointer exception )

Ik zeg niet dat er 1 manier is om het te doen, maar in veel gevallen is true or false totaal niet genoeg en kan je daarmee dus ook niet een programma flow maken. En om de rest er dan aan vast te knutselen met exceptions is dan ook weer zo'n half om half werkje. Try/catch/finally maakt een goede flow met foutafhandeling mogelijk maar om daar nou alles in te doen is ook weer zoiets...

[ Voor 16% gewijzigd door !null op 15-10-2009 18:20 ]

[.oisyn]

!null schreef op donderdag 15 oktober 2009 @ 18:14:
Vind ik niet erg duidelijk, vind ik niet echt zelfuitleggend ofzo.

Is het ook niet, omdat er geen comments bij staan. Als is gedocumenteerd dat ie teruggeeft of de postzegel al in de verzameling zat, dan is dat een prima designkeuze imho.

[H!GHGuY]

Standeman schreef op donderdag 15 oktober 2009 @ 15:01:
Weer een leuke bug gevonden in de code. Deze heeft vziw nog geen problemen opgeleverd, maar dat is imo slechts een kwestie van tijd.

Java:

    try
    {
      daoFactory = DAOFactory.getDAOFactory(DAOFactory.DBMS);
      dao = daoFactory.loadFooDAO();
//...
    }
    catch(DataAccessException dax)
    {
      log.error(dax.getMessage());
      dao.rollback(); //!!!
      throw new ModelControllerException(dax);
    }
// ...

Ik hoop bovendien dat getDAOFactory en loadFooDAO nooit een DataAccessException throwen...

[D-Raven]

!null schreef op donderdag 15 oktober 2009 @ 18:14:
....
Ik zeg niet dat er 1 manier is om het te doen, maar in veel gevallen is true or false totaal niet genoeg en kan je daarmee dus ook niet een programma flow maken. En om de rest er dan aan vast te knutselen met exceptions is dan ook weer zo'n half om half werkje. Try/catch/finally maakt een goede flow met foutafhandeling mogelijk maar om daar nou alles in te doen is ook weer zoiets...

Exception handling is erg traag. Het is veel sneller/performant om met errorcodes te werken dan een exception op te gooien.
Bijvoorbeeld bij het toevoegen van een postzegel zou je de methode true of false terug kunnen laten geven of het wel of niet gelukt is. Is het niet gelukt dan vraag je aan het object wat de errorcode is en ga je daarmee werken.
Je gooit pas een exception op het moment dat er iets gebeurd wat niet eventueel door de gebruiker opgelost kan worden.
Tenminste, zo kijk ik er tegenaan.

[!null]

True/false gebruiken en dan later de errorcode opvragen lijkt me iig beter kunnen, retourneer dan meteen de errorcode (die dus ook 0 = succesvol kan zijn oid).

[Janoz]

Wat is die fracking aversie tegen exceptions eigenlijk? De 'performance impact' is natuurlijk een non issue zolang je geen software voor je arduino of nokia schrijft. Ik durf zelfs wel te stellen dat het gebruik van errorcodes duurder is dan een fatsoenlijke implementatie middels exceptions. Ten eerste is een implementatie met Exceptions een stuk cleaner (geen complete if structuur op elk niveau in je functie om foutafhandeling te regelen) waardoor de code beter te begrijpen is en ten tweede is het debuggen van problemen met een complete stacktrace een stuk makkelijker dan met een melding waar alleen maar een errorcode uit te halen is. En ik neem aan dat iedereen wel weet dat de grootste kostenpost van software de mensen zijn die de software moeten ontwikkelen en onderhouden.

[Haan]

Het punt is denk dat het gebruiken van Exceptions om je program flow te regelen wezenlijk fout is. Een exception heet niet voor niets exception, het is een uitzonderlijke situatie. Er is natuurlijk niets mis met het opvangen van exceptions an sich. (tenzij je overal try {..} catch(Exception e) { ..} doet natuurlijk )

[MBV]

Tja, heel 'vervelend' dat de ontwikkelaars bij SUN daar anders over denken. 'FileNotFoundException' wil je vaak echt anders afhandelen dan 'IllegalAccessException' ofzo. Als je er een speciale exception voor gaat verzinnen, is het eigenlijk al geen uitzonderlijke situatie meer: je hebt er immers van tevoren over nagedacht dat het kan voorkomen

[!null]

Overigens, eventueel performance verlies door exceptions is toch alleen sprake van als daadwerkelijk de exception gegooid wordt? Bij normaal traject leidt het toch niet tot performance verlies? Dan is het imo ook niet echt een issue, dat performance verhaal.

[Janoz]

Haan schreef op vrijdag 16 oktober 2009 @ 11:03:
Het punt is denk dat het gebruiken van Exceptions om je program flow te regelen wezenlijk fout is. Een exception heet niet voor niets exception, het is een uitzonderlijke situatie. Er is natuurlijk niets mis met het opvangen van exceptions an sich. (tenzij je overal try {..} catch(Exception e) { ..} doet natuurlijk )

Exception is per definitie een manier op flow te regelen. Een zeer specifieke flow, namelijk de uitzonderlijke flow. Ik ben het met je eens dat je happy flow zeker niet via exceptions moet lopen, maar vanaf daar wordt het minder zwart wit. Een authenticatie module die een exception gooit bij een niet geslaagde inlogpoging wil ik niet per definitie fout noemen.

[mithras]

Janoz schreef op vrijdag 16 oktober 2009 @ 11:34:
[...]

Exception is per definitie een manier op flow te regelen. Een zeer specifieke flow, namelijk de uitzonderlijke flow. Ik ben het met je eens dat je happy flow zeker niet via exceptions moet lopen, maar vanaf daar wordt het minder zwart wit. Een authenticatie module die een exception gooit bij een niet geslaagde inlogpoging wil ik niet per definitie fout noemen.

Tja, je kan het ook prima combineren. Ik gebruik gewoon een makkelijke authenticate functie. Die functie retourneert een auth-result. Dit result in valid of niet (dus geslaagd of niet), maar geeft ook beschrijvingen. Die kan je bij niet-valid checken. Daar zitten weer codes in als "credentials wrong", "identity not found", "identity ambigue" en een "overige fouten". Je kan dus imho een exception gooien bij een overige fout, omdat het iets is wat je niet verwacht. Het inloggen met verkeerde gegevens is juist iets wat je wel verwacht (waarom moet je anders inloggen?).

Maar ik ben het met je eens dat het eea wel wat genuanceerder mag.

[MBV]

!null schreef op vrijdag 16 oktober 2009 @ 11:17:
Overigens, eventueel performance verlies door exceptions is toch alleen sprake van als daadwerkelijk de exception gegooid wordt? Bij normaal traject leidt het toch niet tot performance verlies? Dan is het imo ook niet echt een issue, dat performance verhaal.

Dat lijkt me per definitie zo: in elke for-loop kan je een ArrayIndexOutOfBoundException krijgen, bij elke methode-aanroep op een object een NullPointerException. Die performance penalty heb je dus altijd, pas bij het gooien gebeurt er iets wat tijd kost.

Ik heb trouwens wel eens een slide gezien van iemand die in Java2 had gemeten dat for-loops afhandelen met exceptions sneller was:

Java:

int i = 0, sum = 0;
try {
  while (true) {
    sum += array[i];
    i++;
  }
}
catch (IndexOutOfBoundsException e) {}
system.out.println(sum);

Dat bleek in nagenoeg constante tijd te werken, t.o.v. lineair voor de for-loop

[.oisyn]

MBV schreef op vrijdag 16 oktober 2009 @ 11:50:
Dat bleek in nagenoeg constante tijd te werken, t.o.v. lineair voor de for-loop

Sorry maar dat kan niet anders dan echt complete utter onzin zijn.

.edit: een snelle test leert wel dat hij bij het 100x optellen van alle elementen in een array van 1.000.000 elementen een milliseconde sneller is (~55 ipv ~56 ms). Wat op zich wel logisch is want je spaart 100.000.000 compares uit.

Interessant is wel dat als ik 10.000 keer een sum doe van 10.000 elementen dat de exception-versie dan wel een stuk duurder is (82ms tov 42ms). Opvallend trouwens dat de normale versie hier ook een stuk sneller is dan de exception variant.

.edit2: hmm nu ik m'n code anders heb opgeschreven is hij bij de 100x1000000 variant ook niet meer sneller, en haal ik 89ms tov 47ms. En dat ie bij minder elementen sneller wordt is natuurlijk wel logisch, de cache speelt hier een grote rol.

[ Voor 64% gewijzigd door .oisyn op 16-10-2009 12:09 ]

[Michali]

In het boek Clean Code wordt ook aangeraden juist exceptions te gebruiken ipv. error codes. Overigens wel een aanrader dat boek, gaat goed in op hoe je netjes met exceptions om gaat. Weinig boeken die dat zo behandelen helaas.

[MBV]

.oisyn schreef op vrijdag 16 oktober 2009 @ 11:52:
[...]

Sorry maar dat kan niet anders dan echt complete utter onzin zijn.
.edit: een snelle test leert wel dat hij bij het 100x optellen van alle elementen in een array van 1.000.000 elementen een milliseconde sneller is (~55 ipv ~56 ms). Wat op zich wel logisch is want je spaart 100.000.000 compares uit.

Je vergeet een cruciaal detail: ik zat nog op het HBO, 2e jaar geloof ik, dus dat is 2003. En het was iets wat de docent al een paar jaar daarvoor had uitgezocht, dus vandaar mijn gok Java v1.2. Het probleem met een gewone for-loop is namelijk dat de check of hij kleiner is 2x wordt gedaan: 1x door de Array zelf (if (i > length) throw new Exception) en een keer door je loop-definitie. Mijn gok is dan ook dat de java6 syntax sneller is:

Java:

int sum = 0;
for (int item: array) sum += item;
printf(sum);

[ Voor 20% gewijzigd door MBV op 16-10-2009 14:04 ]

[Verwijderd]

Zoo, wat is dit topic dood zeg! Produceert niemand meer slechte code tegenwoordig?

Een klein voorbeeldje van wat ik net (ongeveer) tegen kwam in code van mij zelf, wel van een aantal jaren terug:

PHP:

if ($bla == 1)
{
    echo '<input type="radio" name="bla" value="1" checked /> Iets <input type="radio" name="bla" value="2" /> Iets <input type="radio" name="bla" value="3" /> Iets <input type="radio" name="bla" value="4" /> Iets';
}
elseif ($bla == 2)
{
    echo '<input type="radio" name="bla" value="1" /> Iets <input type="radio" name="bla" value="2" checked /> Iets <input type="radio" name="bla" value="3" /> Iets <input type="radio" name="bla" value="4" /> Iets';
}
elseif ($bla == 3)
{
    echo '<input type="radio" name="bla" value="1" /> Iets <input type="radio" name="bla" value="2" /> Iets <input type="radio" name="bla" value="3" checked /> Iets <input type="radio" name="bla" value="4" /> Iets';
}
elseif ($bla == 4)
{
    echo '<input type="radio" name="bla" value="1" /> Iets <input type="radio" name="bla" value="2" /> Iets <input type="radio" name="bla" value="3" /> Iets <input type="radio" name="bla" value="4" checked /> Iets';
}
else
{
    echo '<input type="radio" name="bla" value="1" checked /> Iets <input type="radio" name="bla" value="2" /> Iets <input type="radio" name="bla" value="3" /> Iets <input type="radio" name="bla" value="4" /> Iets';
}

En ik ben te lui om het goed te maken nu, ga gewoon een nieuwe optie toevoegen op dezelfde manier.

[H!GHGuY]

Verwijderd schreef op donderdag 29 oktober 2009 @ 20:42:
En ik ben te lui om het goed te maken nu, ga gewoon een nieuwe optie toevoegen op dezelfde manier.

Niemand kan je dan ook verwijten dat je code niet consistent is!

[Cartman!]

mithras schreef op vrijdag 16 oktober 2009 @ 11:50:
[...]
Tja, je kan het ook prima combineren. Ik gebruik gewoon een makkelijke authenticate functie. Die functie retourneert een auth-result. Dit result in valid of niet (dus geslaagd of niet), maar geeft ook beschrijvingen. Die kan je bij niet-valid checken. Daar zitten weer codes in als "credentials wrong", "identity not found", "identity ambigue" en een "overige fouten". Je kan dus imho een exception gooien bij een overige fout, omdat het iets is wat je niet verwacht. Het inloggen met verkeerde gegevens is juist iets wat je wel verwacht (waarom moet je anders inloggen?).

Maar ik ben het met je eens dat het eea wel wat genuanceerder mag.

Waarom eigenlijk zoveel info? Geef je die ook aan de user? Ik geef altijd een "combinatie onbekend" melding, als je weggeeft dat alleen een password niet klopt geef je al bevestiging dat een username wel bestaat...

[MBV]

Weet je wat een leuke tool is om dit soort dingen op te sporen: CCFinderX. Ik heb gehuild van het analyseren van de sourcecode van Compiere (GPL ERP-systeem): een grote bende van copy/paste code. Overal en nergens worden queries uitgevoerd, exceptions afgevangen en gelogd, verbindingen gesloten, enzovoort.
The Real WTF©: Javacode, die net zoals alle rammelende PHP-websites de code in strings opbouwt op de meest onmogelijke manieren (if(x) sql += "...", 100x genest). Representatief voorbeeld:

Java:

        PreparedStatement pstmt = null;
        String sql = "SELECT * FROM AD_Archive WHERE AD_Client_ID=?";
        if (whereClause != null && whereClause.length() > 0)
            sql += whereClause;
        sql += " ORDER BY Created";
        
        try
        {
            pstmt = DB.prepareStatement (sql, null);
            pstmt.setInt (1, ctx.getAD_Client_ID());
            ResultSet rs = pstmt.executeQuery ();
            while (rs.next ())
                list.add (new MArchive(ctx, rs, null));
            rs.close ();
            pstmt.close ();
            pstmt = null;
        }
        catch (Exception e)
        {
            s_log.log(Level.SEVERE, sql, e);
        }
        try
        {
            if (pstmt != null)
                pstmt.close ();
            pstmt = null;
        }
        catch (Exception e)
        {
            pstmt = null;
        }
        if (list.size() == 0)
            s_log.fine(sql);
        else
            s_log.finer(sql);
        //
        MArchive[] retValue = new MArchive[list.size()];
        list.toArray(retValue);
        return retValue;
    }

Dit hele stuk code staat een keer of 1000 door de hele code heen, met als enige het type van de return-variabele en de query zelf.

Nog een WTF: de hele set bestanden ad/src/org/compiere/model/X_* zou gegenereerd moeten zijn, maar ik weet vrij zeker dat daar aardig wat handmatig in ge-edit is. Man man man, wat een ranzige meuk. 700.000 regels code lang Ideale case-study voor mijn scriptie over code-analyse

In Adempiere, de community-fork ervan, hebben ze het duplicatie-probleem gedeeltelijk opgelost met een methode getSqlValue. Ze zijn ergens halverwege het herschrijven naar iets wat marginaal beter is

[mithras]

Cartman! schreef op donderdag 29 oktober 2009 @ 21:49:
[...]

Waarom eigenlijk zoveel info? Geef je die ook aan de user? Ik geef altijd een "combinatie onbekend" melding, als je weggeeft dat alleen een password niet klopt geef je al bevestiging dat een username wel bestaat...

PHP:

switch($result->getCode()) {
  case Zend_Auth_Result::FAILURE_CREDENTIAL_INVALID:
    $this->_helper->log('False login attempt for ' . $result->getIdentity());
  case Zend_Auth_Result::FAILURE:
  case Zend_Auth_Result::FAILURE_IDENTITY_AMBIGUOUS:
  case Zend_Auth_Result::FAILURE_IDENTITY_NOT_FOUND:
    $this->_helper->flashMessenger(array('error'=>'Login wrong'));
    break;
  case Zend_Auth_Result::SUCCESS:
    $this->_helper->flashMessenger(array('success'=>'Login succeed'));
    break;
  default:
    // Zend_Auth_Resul::FAILURE_UNKNOWN
    throw new Exception('Error');
}

offtopic:
De meldingen zijn niet hetzelfde, maar de structuur wel

[Cartman!]

Lijkt me prima dan

[LuCarD]

Cartman! schreef op vrijdag 30 oktober 2009 @ 10:42:
Lijkt me prima dan

Volgens mij krijg je altijd een error exception als correct inlogt

laatste break mist.

[mithras]

LuCarD schreef op vrijdag 30 oktober 2009 @ 10:46:
[...]

Volgens mij krijg je altijd een error exception als correct inlogt

laatste break mist.

Nietus!

Het ging om het idee he, niet de precieze uitwerking Het punt is dat ik onderscheid wil maken tussen de verschillende failures. Ik vind het belangrijk om terug te kunnen zien dat er voor user x, y inlogpogingen zijn gedaan. Met alleen maar een success/failure systeem mis je zo'n controle. Hetzelfde geldt voor niet-bestaande gebruikers. Daar doe ik niets mee, maar je zou zo ook brute forcing makkelijker kunnen afvangen.

[ Voor 40% gewijzigd door mithras op 30-10-2009 10:52 ]

[Shagura]

Redelijke schok bij het zien van deze code, ik wist niet eens dat er current() en next() php functies bestonden voor een array (zullen vast ooit handig zijn in theorie maar whatever). Ik vraag me gewoon af of iemand dit expres heeft gedaan zo:

PHP:

        if(count($monthsArray) == 1){
            $prev = -1;
            $next = -1;
        }
        else{
            if(current($monthsArray)==$monthsArray[$index]){
                $next = -1;
                $prev = array_search(next($monthsArray), $monthsArray);
            }
            else{
                while(current($monthsArray)!=$monthsArray[$index]){
                    next($monthsArray);
                }
                $next = array_search(prev($monthsArray),$monthsArray);
                next($monthsArray);
                if(next($monthsArray)!=FALSE){
                    $prev = array_search(current($monthsArray), $monthsArray);
                }
                else
                {
                    $prev = -1;
                }
            }
        }

Blijkbaar wil iemand nagaan wat de volgende en vorige arrayindex is en weet dit in lineaire looptijd te doen. wtf?

[MBV]

code:

array_search(prev($monthsArray),$monthsArray);

WTF?!!!

[!null]

Hilarisch... sowieso het door elkaar heen gebruiken van index en een iterator..

[MBV]

Er zijn algoritmen waarbij dat soort-van zinvol is, daar hoort dit natuurlijk niet bij.

[.oisyn]

Hoe kun je wel op de hoogte zijn van prev(), next() en current(), maar niet van key()?

[Laurens-R]

ik ga m'n collega slaan....

net dit tegengekomen in een legacy vb6 app, terwijl ik door de loginfunctie heen ging... deed hij omdat hij wilde 'debuggen' ik vind deze manier van debuggen al minder, laat staan dat het nu 'perongeluk' naar productie is gegaan.... de service desk zal wel voorlopig geen gebruikers meer aan de lijn krijgen omdat ze niet kunnen inloggen ofzo.

code:

succes = ValidateUser(username, password)

goto gaverder

IF sucess <> True THEN
     .... allerlei code om de gebruiker te weigeren in het systeem....
END IF

gaverder:

... code die toegang geeft tot het systeem.

[ Voor 3% gewijzigd door Laurens-R op 05-11-2009 14:03 ]

[Janoz]

Met een fatsoenlijke unittest was deze code nog niet eens door de nightly build gekomen....

[MBV]

Unit-test? Er staat "Legacy VB6 app". I rest my case...

[Laurens-R]

Hadden we maar een unit-test framework + build systeem voor VB6 Daarbij wordt aan de legacy VB6 tooling een minimale hoeveelheid geld besteed. Dergelijke systemen (als ze al bestaan) zouden nooit goedgekeurd worden door de business...

Daarom zijn we ook hard bezig met een migratie naar .net (met unit-tests, TFS nightly builds en alles wat daarbij hoort)... maar ja tot die tijd moet deze tooling toch blijven draaien

[ Voor 7% gewijzigd door Laurens-R op 05-11-2009 15:14 ]

[.oisyn]

Janoz schreef op donderdag 05 november 2009 @ 14:31:
Met een fatsoenlijke unittest was deze code nog niet eens door de nightly build gekomen....

Met een code review van tevoren was hij niet eens ingechecked geweest

[MBV]

en met peer-programming was hij niet geschreven

[!null]

MBV schreef op donderdag 05 november 2009 @ 15:14:
en met peer-programming was hij niet geschreven

Sorry, wat is peer-programming?

Het was er iig niet doorheen gekomen met ook meer iets van een beetje fatsoenlijk testplan.
Maarja, je hebt idd van die projecten die dan op het einde lopen, wordt weinig meer aan gedaan dan.

[.oisyn]

!null schreef op donderdag 05 november 2009 @ 15:17:
[...]


Sorry, wat is peer-programming?

Dat is als je software schrijft voor de concurrent van Apple
(MBV bedoelt pair programming )

[ Voor 18% gewijzigd door .oisyn op 05-11-2009 15:19 ]

[Laurens-R]

Allemaal heel valide opmerkingen waarmee ik het helemaal eens ben...

Ik denk dat we een aparte thread/topic kunnen openen over bad practices als het aankomt op software onderhoud, en een business afdeling die voor een dubbeltje op de eerste rij wilt zitten... zeker als de app EOL begint te worden (maar niet als zodanig behandeld wordt)

[MBV]

.oisyn schreef op donderdag 05 november 2009 @ 15:17:
[...]

Dat is als je software schrijft voor de concurrent van Apple
(MBV bedoelt pair programming )

Peer != Pear! http://www.answers.com/pear En het is niet voor een concurrent, maar voor een emulator

Even dat en peer-review door elkaar gemixed:

quote: http://www.answers.com/peer

# A person who has equal standing with another or others, as in rank, class, or age: children who are easily influenced by their peers.

Sorry, it all sounds alike

Dearest creature in Creation
Studying English pronunciation,
I will teach you in my verse
Sounds like corpse, corps, horse and worse.
It will keep you, Susy, busy,
Make your head with heat grow dizzy; ...

[.oisyn]

MBV schreef op donderdag 05 november 2009 @ 15:40:
[...]

Peer != Pear! http://www.answers.com/pear

Ik doelde dan ook op het Nederlandse woord voor de vrucht . Ik ben me er terdege van bewust wat peer, pear en pair betekenen.

Verder: http://googlefight.com/in...d2=%22pair+programming%22. Peer programming lijkt me idd iets wat een eigen leven is gaan leiden naast "peer review", terwijl mensen eigenlijk pair programming bedoelen, uit het extreme programming paradigma waar het vandaan komt.

thefreedictionary verwijst naar pair programming als je peer programming opzoekt, en wikipedia heeft alleen een pagina voor pair programming

[ Voor 65% gewijzigd door .oisyn op 05-11-2009 15:51 ]

[Snake]

!null schreef op donderdag 05 november 2009 @ 15:17:
[...]


Sorry, wat is peer-programming?

Het was er iig niet doorheen gekomen met ook meer iets van een beetje fatsoenlijk testplan.
Maarja, je hebt idd van die projecten die dan op het einde lopen, wordt weinig meer aan gedaan dan.

Gelijk appel programming!

Serieus: Pair programming, met 2 aan 1 pc zitten. Heb je onmiddelijke feedback op je code van een ander, en nog een hele resum van voordelen.

1 Nadeel: ik hou het niet langer als 2 uur uit, dan plek ik die z'n mond dicht.

[MBV]

lol

Leuk detail: er zijn aardig wat goeroes die beweren dat het net zo snel werkt als ieder voor zich programmeren. Bij een manager van wie ik een presentatie heb gezien over het onderwerp ben ik op z'n afdeling geweest, en ik zag kennelijk niemand programmeren

[Verwijderd]

ik ben al eens dit tegengekomen:

PHP:

<?php
$result=mysql_query("SELECT * FROM users WHERE id=1");
$row=mysql_fetch_object($result);
mysql_query("DELETE FROM users WHERE id=1");
$newpass=$_POST['password'];
$query="INSERT INTO users (id,username,password) VALUES ('1','{$row->username}','{$newpass}')";
mysql_query($query)
?>

Wie oh wie ziet wat er overbodig is...

[BM]

Verwijderd schreef op donderdag 05 november 2009 @ 16:26:
ik ben al eens dit tegengekomen:

PHP:

<?php
$result=mysql_query("SELECT * FROM users WHERE id=1");
$row=mysql_fetch_object($result);
mysql_query("DELETE FROM users WHERE id=1");
$newpass=$_POST['password'];
$query="INSERT INTO users (id,username,password) VALUES ('1','{$row->username}','{$newpass}')";
mysql_query($query)
?>

Wie oh wie ziet wat er overbodig is...

je kunt die $_POST['password']; ook direct in je $query variabele stoppen, die $newpass kan dus wel weg.

[harrald]

BM schreef op donderdag 05 november 2009 @ 16:30:
[...]

je kunt die $_POST['password']; ook direct in je $query variabele stoppen, die $newpass kan dus wel weg.

of je doet een update...

en als je toch bezig bent, meteen iets aan de sql injectie doen

[YopY]

MBV schreef op donderdag 29 oktober 2009 @ 21:50:
The Real WTF©: Javacode, die net zoals alle rammelende PHP-websites de code in strings opbouwt op de meest onmogelijke manieren (if(x) sql += "...", 100x genest). Representatief voorbeeld:

Java:

// code

Ik heb het gezien, . En ook zelf gemaakt, overigens, omdat ik niks beters wist. Maar een Google zoekopdracht later krijg je zoiets, en dan maar éénmaal:

Java:

    public synchronized int executeQuery(final Connection connection, final String sql, final ResultSetHandler<?> handler) {
        Statement statement = null;
        ResultSet resultSet = null;
        try {
            statement = connection.createStatement();
            if (handler != null) {
                resultSet = statement.executeQuery(sql);
                handler.handle(resultSet);
            } else {
                return statement.executeUpdate(sql);
            }
        } catch (SQLException e) {
            log.log(Level.SEVERE, e.getMessage(), e);
        } finally {
            try {
                if (resultSet != null)  resultSet.close();
                if (statement != null)  statement.close();
                if (connection != null) connection.close();
            } catch (SQLException e) {
                log.log(Level.SEVERE, e.getMessage(), e);
            }
        }
        return 0;
    }

waar een ResultSetHandler zoiets is als:

Java:

    class PercentageVotesHandler implements ResultSetHandler<Integer> {
        public int percentage = 0;
        public void handle(ResultSet rs) throws SQLException {
            if (rs.next()) {
                percentage = Math.round(rs.getFloat("percentage"));
            }
        }

        public Integer getResults() {
            return percentage;
        }
    }

(en ja, hij is lelijk - generics met Integer class enzo, afronding, bleuaargh, maar ik heb geen zin om er nog langer aan te werken. Het komt uit een project dat euh... begin van het jaar opgestart is, en pas nu (nadat ik er zelf totaal wel een dikke honderd uur of meer ingestoken heb totaal) lijkt het bijna klaar te zijn. Maar helaas wordt het pas volgend jaar uitgerold, )

[MBV]

YopY schreef op donderdag 05 november 2009 @ 16:43:
[...]


Ik heb het gezien, . En ook zelf gemaakt, overigens, omdat ik niks beters wist.

Schaam je. Nooit Hibernate tegengekomen bij het zoeken naar hoe je SQL moet doen met Java?

[Sebazztiaan]

gister tegengekomen bij een collega, had net ternaire operators uitgevonden

code:

$alt = 'odd';
while($row = $db->nextRow()) {
  ...
  $alt = $alt == 'odd' ? 'odd' : 'even';
}

en dan met het briljante statement komen WHILE loops zijn kut, ik zie de alternating rowstyle niet!, met een FOR loop zou dit wel gelukt zijn! echt, ik zweer het je!

just:

[Verwijderd]

Sebazztiaan schreef op vrijdag 06 november 2009 @ 06:50:
gister tegengekomen bij een collega, had net ternaire operators uitgevonden

code:

$alt = 'odd';
while($row = $db->nextRow()) {
  ...
  $alt = $alt == 'odd' ? 'odd' : 'even';
}

en dan met het briljante statement komen WHILE loops zijn kut, ik zie de alternating rowstyle niet!, met een FOR loop zou dit wel gelukt zijn! echt, ik zweer het je!

just:

Die is wel heel erg, nog erger als iets als:

PHP:

while (true)
{
    $i = 1 - $i;
}

[Mastermind]

Sebazztiaan schreef op vrijdag 06 november 2009 @ 06:50:
gister tegengekomen bij een collega, had net ternaire operators uitgevonden

code:

$alt = 'odd';
while($row = $db->nextRow()) {
  ...
  $alt = $alt == 'odd' ? 'odd' : 'even';
}

en dan met het briljante statement komen WHILE loops zijn kut, ik zie de alternating rowstyle niet!, met een FOR loop zou dit wel gelukt zijn! echt, ik zweer het je!

just:

als hij
$alt = $alt == 'odd'? 'even': 'odd';
had gedaan had het wel gewerkt.

[Erkens]

Mastermind schreef op vrijdag 06 november 2009 @ 09:04:
[...]


als hij
$alt = $alt == 'odd'? 'even': 'odd';
had gedaan had het wel gewerkt.

En voor de leesbaarheid had ik nog wat haakjes gebruikt:

PHP:

$alt = ($alt == 'odd') ? 'even' : 'odd';

Hoewel ik waarschijnlijk gewoon een boolean had gebruikt.

[Woy]

Ik had denk gewoon een for loop gebruikt, dan kan je later ook nog makkelijk een index vooraan de row plaatsen, of elke 10e rij een andere class geven.

PHP:

for( $i = 0; $row = $db->nextRow(); $i++ )
{
    $rowStyle = ($i % 2 == 0) ? 'odd' : 'even';
    ....
}

[ Voor 3% gewijzigd door Woy op 06-11-2009 09:38 ]

[Sebazztiaan]

Erkens schreef op vrijdag 06 november 2009 @ 09:23:
[...]

En voor de leesbaarheid had ik nog wat haakjes gebruikt:

PHP:

$alt = ($alt == 'odd') ? 'even' : 'odd';

Hoewel ik waarschijnlijk gewoon een boolean had gebruikt.

true, maar hij kon nu ez dit printen

code:

print '<div class="row row-'.$alt.'">...</div>';

[YopY]

MBV schreef op donderdag 05 november 2009 @ 16:58:
[...]

Schaam je. Nooit Hibernate tegengekomen bij het zoeken naar hoe je SQL moet doen met Java?

Jawel, maar ik geef je 5 euro als jij dat werkend krijgt in WebManager, . OSGI enzo, met een eigen laag er bovenop gebouwd, etc etc etc.

(en het waren maar een handjevol queries, [/excuus])

[ Voor 6% gewijzigd door YopY op 06-11-2009 09:57 ]

[Janoz]

Ik was zelf erg gecharmeerd van Springs jdbcTemplate. Enkele jaren terug heb ik dat nog intensief toegepast in een omgeving waar ook geen Hibernate gebruikt kon/mocht worden. De structuur lijkt iig wel erg op wat jij ook al gedaan hebt.

Verder heb ik voor een meer lean en mean applicatie ook zelf de sql code uitgeschreven, en ook daar werk ik met callback handlers. In dat geval gaat het over een kleine clientside applicatie (zie avatar ). Die wil ik niet ineens 3x zo groot maken omdat ik een OR mapper mee lever.

[MBV]

De quote was "omdat ik niks beters wist". En zelf SQL code uitschrijven is in sommige gevallen verdedigbaar, ik heb bijvoorbeeld gelezen dat een port van Adempiere naar Hibernate zo achterlijke traag was dat je een uur bezig was met het laden van de applicatie. De manier waarop dat is gedaan in Compiere is dan weer níet verdedigbaar.

Voor de liefhebbers, een plaatje uit CCFinderX:

Je ziet hier een scatterplot met horizontaal en verticaal alle code, zwart wanneer het fragment op die regel overeenkomt, en blauw wanneer het SQL exception handling is. Het zwarte blok is gegenereerde code, dat zijn objecten die de gegevens uit de database vertegenwoordigen.

[ Voor 6% gewijzigd door MBV op 06-11-2009 13:20 ]

[YopY]

Janoz schreef op vrijdag 06 november 2009 @ 10:00:
Ik was zelf erg gecharmeerd van Springs jdbcTemplate. Enkele jaren terug heb ik dat nog intensief toegepast in een omgeving waar ook geen Hibernate gebruikt kon/mocht worden. De structuur lijkt iig wel erg op wat jij ook al gedaan hebt.

Ik heb daar ook naar gekeken, maar ik las dat en ik had niet iets van 'dit snap ik', danwel dat het snel in m'n app gezet kon worden, dus heb ik het niet toegepast . Maar ik zal het nogmaals proberen als het later nog een keer voorkomt. Spring is wel standaard beschikbaar in het CMS waar ik voor ontwikkel, dus dat moet geen probleem zijn.

[ Voor 8% gewijzigd door YopY op 06-11-2009 14:05 ]

[Janoz]

Om te kijken hoe dat werkt moet je niet in de Spring documentatie kijken, maar in het 'Spring in Action' boek (Tenminste, dat was 4 jaar geleden wel zo)

[Verwijderd]

Tja, als je het UPDATE statement niet kent kan dit natuurlijk ook... Verder ook niet het password hashen of checken op SQL-Injection.

Gelukkig ontbreekt de puntkomma ontbreekt op regel zeven, waardoor het sowieso niet zal werken.

<edit> poep, gereageerd op het bericht van TMje op de vorige pagina, dacht dat dat de laatste pagina was.

[ Voor 18% gewijzigd door Verwijderd op 07-11-2009 14:01 ]

[Cartman!]

Iets wat ik me ineens herinner, een topic hier van heul lang geleden waarin iemand beweerde dat t gebruik van single quotes in html veel sneller zou zijn dan dubbele quotes omdat ze de helft minder ruimte verbruiken

[curry684]

Cartman! schreef op zaterdag 07 november 2009 @ 15:04:
Iets wat ik me ineens herinner, een topic hier van heul lang geleden waarin iemand beweerde dat t gebruik van single quotes in html veel sneller zou zijn dan dubbele quotes omdat ze de helft minder ruimte verbruiken

Dude

[prototype]

Woy schreef op vrijdag 06 november 2009 @ 09:37:
Ik had denk gewoon een for loop gebruikt, dan kan je later ook nog makkelijk een index vooraan de row plaatsen, of elke 10e rij een andere class geven.

PHP:

for( $i = 0; $row = $db->nextRow(); $i++ )
{
    $rowStyle = ($i % 2 == 0) ? 'odd' : 'even';
    ....
}

En als 't dan toch alleen odd/even is had ik misschien nog eerder een AND bitmask met 1 gedaan (oneven getallen hebben altijd een hoge LSB), dus zoiets als:

PHP:

for( $i = 0; $row = $db->nextRow(); $i++ ) {
    $rowStyle = ($i & 1 == 0) ? 'even' : 'odd';
}

Weet niet hoe PHP precies de modulo operatie heeft geimplement maar dit zou dus gewoon een paar opcodes kunnen schelen ;-) ZOMGMICROOPTIMALISATIESWTFBBQ

[ Voor 10% gewijzigd door prototype op 08-11-2009 03:06 ]

[NLxAROSA]

Janoz schreef op vrijdag 06 november 2009 @ 10:00:
Ik was zelf erg gecharmeerd van Springs jdbcTemplate.

De Spring templates vind ik sowieso erg goed, ook de Hibernate- en JPA template. Het grootste voordeel is dat je alle boilerplate code kwijt bent (verplichte try/catch blokken).

MBV schreef op vrijdag 06 november 2009 @ 13:19:
De quote was "omdat ik niks beters wist". En zelf SQL code uitschrijven is in sommige gevallen verdedigbaar, ik heb bijvoorbeeld gelezen dat een port van Adempiere naar Hibernate zo achterlijke traag was dat je een uur bezig was met het laden van de applicatie.

Hibernate is dan ook bij uitstek geschikt voor bepaalde zaken (met name CRUD) en weer heel erg slecht in andere zaken (complexe queries, batchwerk, etc.). Staat ook aangegeven in de Hibernate Reference. Als ik op een project weer eens mensen hoor roepen dat 'je tegenwoordig niks meer van SQL en de database hoeft te weten omdat je Hibernate hebt', lopen de rillingen over mijn rug. Goede kennis van SQL en de database waar je mee werkt blijft essentieel om e.e.a. goed te kunnen optimaliseren.

[MBV]

absoluut. Maar met Hibernate Query Language kom je toch ook een heel eind? IMHO de volgorde:
- schrijven met O/R-framework, zodat je iig de standaard selects op ID's en insert/update al hebt
- indien nodig bottlenecks opsporen
- indien bottlenecks bij framework, omzeilen met native SQL queries

En het mooiste: dat gigantische zwarte blok was gegenereerde code. Zet daar dan ook al die simpele queries in

[Kwastie]

Kwam dit afgelopen week tegen bij mijn stage

PHP:

/* Return the result */
function _return_result($return) {
  return $return; 
}

En dit werd zo'n 20-30 keer aangeroepen in 1 bestand

*Kwastie hoopt dat dit door een andere stagiair gemaakt is*

[Sebazzz]

Waarom zou je zo'n functie maken

[Kwastie]

dat was ook ook mijn eerste gedachte

Ik hoop zelf dat het een overblijfsel is van oude code (wat waarschijnlijk vroeger wel een 'doel' had) en later herschreven is.

[Voutloos]

Kwastie schreef op zondag 08 november 2009 @ 14:08:
*Kwastie hoopt dat dit door een andere stagiair gemaakt is*

svn blame

[Tsunami]

Verwijderd schreef op zaterdag 07 november 2009 @ 14:00:
Gelukkig ontbreekt de puntkomma ontbreekt op regel zeven, waardoor het sowieso niet zal werken.

Gelukkig is de puntkomma bedoelt om statements te scheiden, en aangezien het de laatste statement in dat code block betreft is de puntkomma overbodig De meeste mensen, ikzelf ook, schrijven hem echter wel zodat het consistent is.

[.oisyn]

Tsunami schreef op zondag 08 november 2009 @ 15:02:
[...]

Gelukkig is de puntkomma bedoelt om statements te scheiden, en aangezien het de laatste statement in dat code block betreft is de puntkomma overbodig

In talen als Pascal ja. Vrijwel alle talen met C-like syntax (javascript is een bekende uitzondering) is het geen scheidingstoken maar onderdeel van een statement, en ze vereisen 'm dus. PHP ook. Je code runt dus niet zoals hij in de topic stond

[ Voor 14% gewijzigd door .oisyn op 08-11-2009 18:34 ]

[StM]

In PHP kan je door een bug in de parser in een aantal gevallen de laatste puntkomma weglaten. Maar dat is eigenlijk het abusen van een bug. In hoeverre dit gefixed is en wanneer het toepasbaar is durf ik niet te zeggen aangezien ik gewoon altijd netjes afsluit

/edit: zo te zien is het in PHP 5 gefixed
/edit2: toch niet. Het hangt er nogal van af wat je precies doet. Dit is valide code:

PHP:

<?php

echo "test";

exit()

?>

/edit3: Op het moment dat je de sluit tag weg laat (wat gewoon valide is in php...) dan krijg je een unexpected $end error.

[ Voor 41% gewijzigd door StM op 08-11-2009 18:47 ]

[PrisonerOfPain]

In PHP geldt ?> als impliciete semicolon.

http://php.net/manual/en/...nstruction-separation.php

[Sh4wn]

Niet echt een bug, maar ook weer iets van de de PHP parser, de ?> geldt gewoon als geldige afsluiter.

[StM]

"It's not a bug, its a feature!" Ik vraag me af in hoeverre ze er over nagedacht hebben van te voren.

[Verwijderd]

Sh4wn schreef op zondag 08 november 2009 @ 19:00:
Niet echt een bug, maar ook weer iets van de de PHP parser, de ?> geldt gewoon als geldige afsluiter.

Ja, maar werd op dat moment niet verwacht....

[.oisyn]

PrisonerOfPain schreef op zondag 08 november 2009 @ 18:55:
In PHP geldt ?> als impliciete semicolon.

http://php.net/manual/en/...nstruction-separation.php

Ah, dat verklaart waarom mijn test niet runde - die had zowel geen sluitende accolade als geen closing tag . Desalniettemin, het blijft zo dat een ; geen scheidingsteken is, maar onderdeel is van oa statements.

[mithras]

Site.to.Make schreef op zondag 08 november 2009 @ 19:09:
"It's not a bug, its a feature!" Ik vraag me af in hoeverre ze er over nagedacht hebben van te voren.

Als je templates bouwt mbv php short tags is het wel lekker om óók de semicolon te kunnen missen hoor

[StM]

Persoonlijk vind ik dat dat soort code ook al heel snel in dit topic thuis hoort, hoewel ik weet dat er developers zijn die het daar totaal niet mee eens zullen zijn

[.oisyn]

Ah, je bent er zoéén die het principe van scheiding van business layer en presentation layer onjuist interpreteert als zijnde dat de presentatielaag geen code mag bevatten?

[StM]

Het is niet zozeer dat het het probleem is dat er code in voorkomt (smarty is net zo goed een taal), het probleem is meer dat de gemiddelde template zo smerig wordt gemaakt op de langere termijn dat er mee werken gewoon niet fijn is. Natuurlijk kan alles wat je met smarty kan doen ook met php, het is gewoon een gevalletje smaak.

(en collega's wat harder schoppen)

[ Voor 5% gewijzigd door StM op 09-11-2009 00:59 ]

[Jaap-Jan]

En hoe gaat het leren van een ander idioom dat probleem dan oplossen?

Maar goed, je zegt zelf al dat het vooral ligt aan het feit dat sommigen er niet mee om kunnen gaan. Als je dat gezegd had, dan had dat al weer een paar posts gescheeld.

[ Voor 138% gewijzigd door Jaap-Jan op 09-11-2009 01:08 ]

[StM]

Wat mij oa heel vaak opvalt bij php-in-html template's, is dat er heel makkelijk wordt overgestapt op het gebruik van echo of print ipv uit de php mode te gaan. In iets als smarty is dat sowieso niet mogelijk. Aan de andere kant zijn er soms ook mensen die de meest vreselijke smarty code weten te produceren....

[Jaap-Jan]

Simpel gezegd, als in die PHP template html geprint wordt, dan zit er iets fout. Echter, echo/ print is wel de enige manier om variabelen/ literals in je html pagina te krijgen. Maar templates horen voor het grootste gedeelte al uit html te bestaan, dus als het leeuwendeel php is, dan was de scheiding van logica/ presentatie al niet goed.

Kun je misschien een voorbeeld laten zien van wat je echt fout vind (om weer back on- topic te komen. ).

[Verwijderd]

Iets als het onderstaande?

PHP:

<div class="bla">
    <div id="blaat">
        <?php
        echo '<span class="iets">'.$blaat.'</span>
              <span class="nogiets">'.(100 * $test + $lol).'</span>';
        ?>
    </div>
</div>

Moet stiekem toegeven dat ik het zo wel eens gebruik, prefereer tegenwoordig toch wel iets als:

PHP:

<div class="bla">
    <div id="blaat">
        <span class="iets"><?=$blaat?></span>
        <span class="nogiets"><?=(100 * $test + $lol)?></span>
    </div>
</div>

Mét shorttags.

[Patriot]

Shorttags gebruiken is niet echt geweldig handig als code portability een issue is (een andere server kan shorttags uit hebben staan), maar het principe (niet onnodig html in je echo) is inderdaad goed.

Site.to.Make schreef op maandag 09 november 2009 @ 01:13:
Wat mij oa heel vaak opvalt bij php-in-html template's, is dat er heel makkelijk wordt overgestapt op het gebruik van echo of print ipv uit de php mode te gaan. In iets als smarty is dat sowieso niet mogelijk. Aan de andere kant zijn er soms ook mensen die de meest vreselijke smarty code weten te produceren....

Mensen die daar verkeerde beslissingen over nemen zie ik er sowieso niet echt voor aan wel de goede beslissingen te nemen als het gaat om scheiding van de business en presentation logic.

[Verwijderd]

Patriot schreef op maandag 09 november 2009 @ 03:21:
Shorttags gebruiken is niet echt geweldig handig als code portability een issue is (een andere server kan shorttags uit hebben staan), maar het principe (niet onnodig html in je echo) is inderdaad goed.

Nah, ik ben nog nooit een server tegengekomen waar dit een probleem veroorzaakte, op het moment dat dit wel een probleem is, komen we daar tijdens de test-procedure achter en kunnen we het nog aan laten passen in de configuratie van de server. Over het algemeen hebben onze klanten geen cheapass budget hosting, dus dat zal nooit een probleem gaan worden. Mocht er dan ooit één geval komen waar het niet uit kan en er niet verhuisd kan worden, dan heeft m'n IDE een fijne replace functie.

[Cartman!]

Ik ben ook fan van shorttags maar bedenk wel dat ze in PHP6 niet meer bestaan. Ik ben maar aan het wennen door de boel weer uit te schrijven dus.

Het gebruik van smarty begrijp ik ook niet helemaal, in feite doe je precies hetzelfde als 'normaal' alleen dan met een andere syntax die ervoor zorgt dat je nog een extra vertaalslag nodig hebt (=slomer).

[Erkens]

Cartman! schreef op maandag 09 november 2009 @ 10:09:
Ik ben ook fan van shorttags maar bedenk wel dat ze in PHP6 niet meer bestaan. Ik ben maar aan het wennen door de boel weer uit te schrijven dus.

Die blijven gewoon bestaan hoor?
short_open_tag is met PHP6 alleen niet 'by default'. Men wordt alleen aangeraden om hem niet meer te gebruiken bij nieuwe projecten vooral vanwege compatibility met andere server settings.

[Cartman!]

Zijn ze daar op teruggekomen dan? Eerst hebben ze gezegd dat de short_tags depricated zouden zijn en gewoon helemaal niet meer bestaan net zoals magic_quotes.

[Snake]

Ik begrijp niet waarom ShortTags by default worden afgezet. Waarom wordt uberhaupt die optie aangeboden? <?=$var?> is gewoon een shorthand naar <?php print($var); ?>

Wat is het probleem daarmee? Bij ASP.NET gebruik je toch constant <%=myVar%>. En daar klaagt niemand over.

[Voutloos]

Het probleem is echt wel voldoende (keertje of 10.000) beschreven. Enkel met <?= specifiek is er een minder groot probleem, en je zou het stom kunnen vinden dat die niet los van de <? tag werkt.

Overigens is er ook een support voor de ASP tag, maar die wordt godzijdank ook afgeraden.

[ Voor 19% gewijzigd door Voutloos op 09-11-2009 10:56 ]

[Erkens]

Cartman! schreef op maandag 09 november 2009 @ 10:51:
Zijn ze daar op teruggekomen dan? Eerst hebben ze gezegd dat de short_tags depricated zouden zijn en gewoon helemaal niet meer bestaan net zoals magic_quotes.

Hij staat standaard uit, maar verwijderen gaan ze niet doen, dat zal namelijk een te grote impact hebben. Althans, dat is wat ik uit de php-mailinglist had gelezen een paar maanden geleden.

[YopY]

Ik vindt het persoonlijk wel een beetje een vreemde beslissing om de short tag uit te zetten - <?= $henk ?> vindt ik toch veel leuker werken dan <?php echo $henk; ?>. Wordt het meer een leesbare template taal dan een programmeertaal die je in je templates zet.

Hoe dan ook, ik ben geen fan van php templates . JSP / JSTL vindt ik nog een trapje erger zelfs in sommige gevallen.

code:

<c:choose>
  <c:when test="${conditie}">
      hoi!
  </c:when>
  <c:otherwise>
    doei!
  </c:otherwise>
</c:choose>