[alg] Slechtste programmeervoorbeelden deel 4

[Verwijderd]

.Gertjan. schreef op zaterdag 06 juni 2009 @ 12:22:
[...]


Waarschijnlijk autogenerated code van Visual Studio. Ik moet zeggen dat VS er een handje van heeft om bagger te maken. Vooral de oudere versies. 2008 geeft wel aardige HTML (ook als je "sleur en pleur" gebruikt).

Maar soms zet ik toch mijn vraagtekens bij HTML generatie van VS. Zo wordt een ASP:CheckBox altijd gerenderd als:

XHTML:

<span class="cssClass"><input type="checkbox" name="xxx" /></span>

Waarbij alle attributen die je toekent aan de checkbox op de bovenliggende span worden toegepast. Als je dan een hele pagina aan het stylen bent en er vanuit gaat dat alles op de input wordt gezet (en daar ook je CSS op baseert) is het toch wel even een kleine WTF wanneer je gaat runnen.

Vanwege die reden pas ik de rendering van bepaalde controls aan en gebruik ik eigenlijk sowieso zo min mogelijk .NET controls. Maar goed dat is ook een beetje mijn frontend achtergrond en mijn eigenwijsheid

De vorige programmer schijnt het inderdaad nogal prettig hebben gevonden de design view te gebruiken en daar op los gaan (niks mis mee), zonder toen ie klaar was de code te herstructureren of te becommentariëren (daar wel iets mis mee). Ik heb al eens gezocht of je die auto format code bij het runnen niet kan uitzetten in VS 2003, maar geloof dat dit pas is ingevoerd bij 2005. Ik kan het in ieder geval nergens vinden. En vanwege compatibiliteit willen ze het echt liever allemaal in VS2003 houden.

ps. ik zie net pas dat mn nsbp niet te zien was foutje, ik dacht dat dat wel kon.

[mcDavid]

uit een standaard forum-template:

Cascading Stylesheet:

.xsmalltext{ font-size: 0.75em;}
.smalltext{ font-size: 0.8em;}
.middletext{ font-size: 0.85em;}
.normaltext{ font-size: 0.95em;}
.largetext{ font-size: 1.3em;}

.floatright{ float: right;}
.floatleft{ float: left;}

WTF
Gebruik dan gewoon inline styles!

[Snake]

mcDavid schreef op zaterdag 11 juli 2009 @ 00:37:
uit een standaard forum-template:

Cascading Stylesheet:

.xsmalltext{ font-size: 0.75em;}
.smalltext{ font-size: 0.8em;}
.middletext{ font-size: 0.85em;}
.normaltext{ font-size: 0.95em;}
.largetext{ font-size: 1.3em;}

.floatright{ float: right;}
.floatleft{ float: left;}

WTF
Gebruik dan gewoon inline styles!

Waarom? Ik vind dit properder. Ik probeer zowiezo inline styles te vermijden, en dan zeker door dit mooi per klasse op te delen kan je altijd meerdere attributen erbij gooien om zo sitewide changes te doen.

[Patriot]

De echte fout is de naamgeving die hij gebruikt. Je moet de naam die je geeft niet opstellen aan de hand van het uiteindelijke uiterlijk (dus klein, rood, groen, links-uitgelijnd, met een border bovenaan, etc.), maar aan de hand van de functie (notitie, waarschuwing, succes-bericht, alinea, etc.).

[Michali]

Snake schreef op zaterdag 11 juli 2009 @ 01:47:
[...]

Waarom? Ik vind dit properder. Ik probeer zowiezo inline styles te vermijden, en dan zeker door dit mooi per klasse op te delen kan je altijd meerdere attributen erbij gooien om zo sitewide changes te doen.

Het probleem is dat je zo niet echt je content van de presentatie scheidt. Wat als je nu een element met xsmalltext toch en groter lettertype dan 1 met largetext wilt geven? Dan zouden die classes dus nergens meer op slaan. Dat moet je dus altijd voorkomen.


Ik snap overigens wel waarom dit handig zou zijn. Maar hiervoor zou je eigenlijk een soort CSS class inhertence moeten hebben, of variabelen. Nu is daar helaas nog weinig of geen support voor, dus daar moet je dan een andere oplossing voor zoeken. Dit soort zaken horen echter wel altijd in de stylesheet te gebeuren, en je HTML niet te beïnvloeden. Helemaal waar is dat natuurlijk ook niet, want in het ideale geval zou je geen enkel element een class of ID te hoeven geven, en dat is niet zo.

[ Voor 30% gewijzigd door Michali op 11-07-2009 04:14 ]

[Michali]

MBV schreef op dinsdag 23 juni 2009 @ 21:58:
Het is inderdaad raarrrr, en ik heb geen idee van de semantiek: moet je nu naar de action van het form toegaan, of naar de href van de anchor?

Hij validate wel, als je een action aan de form toevoegt (en natuurlijk doctype, head en andere meuk toevoegt):

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head><title>something</title></head>
<body>
<form action="somethingelse">
  <a href="something">
    <input type="button">
  </a>
</form>
</body>
</html>

De href, aangezien het geen submit of image input is.

Maar wat als in de onclick iets als "this.parent.href='javascript:alert(123);'" staat?

[ Voor 5% gewijzigd door Michali op 11-07-2009 04:17 ]

[mcDavid]

Snake schreef op zaterdag 11 juli 2009 @ 01:47:
[...]

Waarom? Ik vind dit properder. Ik probeer zowiezo inline styles te vermijden, en dan zeker door dit mooi per klasse op te delen kan je altijd meerdere attributen erbij gooien om zo sitewide changes te doen.

mag jij mij vertellen, wat is het voordeel van <span class='floatright'> boven <span allign='right'> ?

Op deze manier kun je wel voor iedere css-property een aparte class gaan maken. Kun je weer heerlijk opmaak door je inhoud mixen, en toch pimpen met je 100% css layout .
En aangezien dat dus deels gebeurd is, gaat het aanpassen van die forumtemplate langer duren dan ik gehoopt had.

-edit-
gelukkig kan het altijd nóg erger.. zomaar een stukje css uit een willekeurig groot nederlandstalig forum van 3 letters begginnend met een F:

Cascading Stylesheet:

.ar{text-align:right;}
.btd{border-top:1px dashed #c0c0c0;}
.bbd{border-bottom:1px dashed #c0c0c0;}
.bls{border-left:1px solid #c0c0c0;}
.bbs{border-bottom:1px solid #c0c0c0;}
.bts{border-top:1px solid #c0c0c0;}
.brs{border-right:1px solid #c0c0c0;}
.w772{width:772px;table-layout:fixed;}
.c1{color:#606060;}
.c2{color:#404040;}
.c3{color:#000;}
.bg1{background:#f0f0f0;}
.bg2{background:#f8f8f8;}
.bg3{background:#F7F6F3;}
.bg4{background:#b0b0b0;}
.bg5{background:#d0d0d0;}
.cb{clear:both;}
.cl{clear:left;}
.px1{font-size:1px;}
.px2{font-size:2px;}
.px5{font-size:5px;}
.px5{font-size:5px;}
.px8{font-size:8px;}
.px9{font-size:9px;}
.px10{font-size:10px;}
.px11{font-size:11px;}
.px12{font-size:12px;}
.px14{font-size:14px;}
.px16{font-size:16px;}
.px18{font-size:18px;}
.px20{font-size:20px;}
.cp{cursor:pointer;}
.picker{width:8px;height:8px;border:1px solid #c0c0c0;cursor:pointer;}
.postit{display:block;background:#fefeec;width:100px;height:100px;}
.mr20{margin-right:20px;}
.mt20{margin-top:20px;}
.mb20{margin-bottom:20px;}
.pl1{padding-left:1px;}
.pl2{padding-left:2px;}
.pl3{padding-left:3px;}
.pl4{padding-left:4px;}
.pl5{padding-left:5px;}
.pl6{padding-left:6px;}
.pl7{padding-left:7px;}
.pl8{padding-left:8px;}
.pl9{padding-left:9px;}
.pl10{padding-left:10px;}
.pl11{padding-left:11px;}
.pl13{padding-left:13px;}
.pr0{padding-right:0;}
.pr1{padding-right:1px;}
.pr2{padding-right:2px;}
.pr3{padding-right:3px;}
.pr4{padding-right:4px;}
.pr5{padding-right:5px;}
.pr6{padding-right:6px;}
.pr7{padding-right:7px;}
.pr8{padding-right:8px;}
.pr9{padding-right:9px;}
.pr10{padding-right:10px;}
.p2{padding:2px;}
.pt2{padding-top:2px;}
.pb2{padding-bottom:2px;}
.ht6{height:6px;}
.ht9{height:9px;}
.ht10{height:10px;}
.ht45{height:45px;}
.vam{vertical-align:middle;}
.vat{vertical-align:top;}

[ Voor 58% gewijzigd door mcDavid op 11-07-2009 11:51 ]

[Sebazzz]

Ik heb de HTML niet gezien maar ik vermoed dat het allemaal <span>netjes zijn die gebruikt worden in plaats van netjes een h1, h2, ..., h6, strong, etc te gebruiken. Dat is denk ik nog wel de ergste fout

[Rickets]

mcDavid schreef op zaterdag 11 juli 2009 @ 00:37:
uit een standaard forum-template:

Cascading Stylesheet:

.xsmalltext{ font-size: 0.75em;}
.smalltext{ font-size: 0.8em;}
.middletext{ font-size: 0.85em;}
.normaltext{ font-size: 0.95em;}
.largetext{ font-size: 1.3em;}

.floatright{ float: right;}
.floatleft{ float: left;}

WTF
Gebruik dan gewoon inline styles!

Het wordt pas een feest als de classname niet meer overeenkomt met wat de properties zijn. Zoiets krijg je dan:

Cascading Stylesheet:

.width40{width:31px;}
.width50{width:41px;}

Erg leuk.

[Soultaker]

Op zich valt er voor die semantische klassen als "smalltext" nog wel wat te zeggen. Wellicht verschilt wat small of large is afhankelijk van de user preferences of de gebruikte browser (mobiele browsers t.o.v. desktopbrowsers b.v.) en dan is het netter om die verschillen te beperken tot een alternatieve stylesheet. (Sterker nog, je kunt meerdere stylesheets koppelen aan een pagina en dan kan de gebruiker zelf de actieve kiezen!)

Maar in dit geval is het natuurlijk wat te veel van het goede.

[mcDavid]

Soultaker schreef op zaterdag 11 juli 2009 @ 15:08:
Op zich valt er voor die semantische klassen als "smalltext" nog wel wat te zeggen. Wellicht verschilt wat small of large is afhankelijk van de user preferences of de gebruikte browser (mobiele browsers t.o.v. desktopbrowsers b.v.) en dan is het netter om die verschillen te beperken tot een alternatieve stylesheet. (Sterker nog, je kunt meerdere stylesheets koppelen aan een pagina en dan kan de gebruiker zelf de actieve kiezen!)

Maar in dit geval is het natuurlijk wat te veel van het goede.

ja daar valt idd nog een beetje wat voor te zeggen, het is zo wel *net* iets minder onpraktisch dan gewoon de <font> tag gebruiken. Maar dan nog gaat mijn voorkeur uit naar semantische class-names.

In dit template wordt de class "smalltext" voor verschillende dingen gebruikt. Bijv. voor de breadcrumbs bovenaan, en in het topicoverzicht voor het aantal reacties dat een topic heeft. Wat nou als ik die breadcrumb groter wil maar de rest niet?

Doe mij dan maar een aparte class .breadcrumb en een aparte class .reply_count ofzo, dan is het in de CSS tenminste ook direct duidelijk wat er verandert als je zo'n waarde aanpast.

[ Voor 3% gewijzigd door mcDavid op 11-07-2009 15:22 ]

[Zeebonk]

mcDavid schreef op zaterdag 11 juli 2009 @ 00:37:
uit een standaard forum-template:

Cascading Stylesheet:

.xsmalltext{ font-size: 0.75em;}
.smalltext{ font-size: 0.8em;}
.middletext{ font-size: 0.85em;}
.normaltext{ font-size: 0.95em;}
.largetext{ font-size: 1.3em;}

.floatright{ float: right;}
.floatleft{ float: left;}

WTF
Gebruik dan gewoon inline styles!

Ik kan mij voorstellen dat als er op het forum gebruik wordt gemaakt van een soort WYSIWYG editor of UBB tags om posts op te maken, dit wel de manier is om styles toe te passen.

Of zijn daar betere technieken voor te gebruiken?

[ Voor 4% gewijzigd door Zeebonk op 11-07-2009 15:34 ]

[Michali]

Soultaker schreef op zaterdag 11 juli 2009 @ 15:08:
Op zich valt er voor die semantische klassen als "smalltext" nog wel wat te zeggen. Wellicht verschilt wat small of large is afhankelijk van de user preferences of de gebruikte browser (mobiele browsers t.o.v. desktopbrowsers b.v.) en dan is het netter om die verschillen te beperken tot een alternatieve stylesheet. (Sterker nog, je kunt meerdere stylesheets koppelen aan een pagina en dan kan de gebruiker zelf de actieve kiezen!)

Maar in dit geval is het natuurlijk wat te veel van het goede.

Hmm, maar dat zou dan betekenen dat de HTML verandert (andere classes) als het uiterlijk van de pagina wijzigt. Met stylesheets wil je dit juist voorkomen, lijkt me.

Maar wat je zegt idd. beter is dan om dan een extra stylesheet, large-text.css en small-text.css oid.

[Patriot]

Zeebonk schreef op zaterdag 11 juli 2009 @ 15:33:
[...]

Ik kan mij voorstellen dat als er op het forum gebruik wordt gemaakt van een soort WYSIWYG editor of UBB tags om posts op te maken, dit wel de manier is om styles toe te passen.

Of zijn daar betere technieken voor te gebruiken?

De tekstgroottes zijn dan semantisch gezien nog wel te verantwoorden, maar dan zou ik de selector iets minder globaal maken (om duidelijk te maken dat het om styling van ubb-tags gaat). De "floatleft" en "floatright" vind ik dan nog steeds minder geschikt, en zou ik anders doen (door middel van inline styles denk ik).

EDIT: Sowieso vind ik inline styles dan geschikter, denk ik. Het argument dat je de css later niet goed kunt wijzigen als je het zo'n specifieke naam geeft gaat bijvoorbeeld in mindere mate op, omdat je de CSS van dit soort dingen meestal niet wilt veranderen omdat je dan eerdere posts die bepaalde ubb-tags gebruiken kunt veranderen (kleine tekst moet niet opeens net zo groot zijn als een titel, dan krijg je een heel andere betekenis).

[ Voor 25% gewijzigd door Patriot op 11-07-2009 16:49 ]

[mcDavid]

Zeebonk schreef op zaterdag 11 juli 2009 @ 15:33:
[...]


Ik kan mij voorstellen dat als er op het forum gebruik wordt gemaakt van een soort WYSIWYG editor of UBB tags om posts op te maken, dit wel de manier is om styles toe te passen.

Of zijn daar betere technieken voor te gebruiken?

Voor datsoort werk heb je <b> <u> <small> enz. tags. Die kun je evt. ook met css stylen.

(dat is overigens ook niet waarvoor het in dit voorbeeld gebruikt wordt, gelukkig)

[ Voor 8% gewijzigd door mcDavid op 11-07-2009 18:01 ]

[Zeebonk]

mcDavid schreef op zaterdag 11 juli 2009 @ 17:59:
[...]


Voor datsoort werk heb je <b> <u> <small> enz. tags. Die kun je evt. ook met css stylen.

(dat is overigens ook niet waarvoor het in dit voorbeeld gebruikt wordt, gelukkig)

Naja dat kan je wel zo zeggen, maar als ik kijk naar classes zie je 5 tekst afmetingen. de elementen small en large zullen je dan niet met alle formaten helpen. Dan zou je kunnen kijken naar h1 h2 enz maar ik denk niet dat dat de slimste elementen zijn om te gebruiken in een forum post.

en @Patriot
Als je een lichte herstyling doet van een forum lijkt het mij juist wel fijn dat je de verschillende tekst grotes weer relatief kan aanpassen naar iets wat in style is met de rest van de opmaak. Dat was toch het hele achter de stylesheets? Dat je zonder met de html enz aan de gang gaat je gewoon het uiterlijk kan aanpassen?

Ik denk dat (in de context van een forum post zoals ik eerder aangaf) er hoogstens op de css aan te merken valt dat de benaming te generiek is.

[Passenger]

Ik vind deze ook nog steeds erg fraai:

HTML:

<tr>
  <td class="content_even"></td>
</tr>
<tr>
  <td class="content_uneven"></td>
</tr>

[Patriot]

Zeebonk schreef op zondag 12 juli 2009 @ 00:21:
[...]

en @Patriot
Als je een lichte herstyling doet van een forum lijkt het mij juist wel fijn dat je de verschillende tekst grotes weer relatief kan aanpassen naar iets wat in style is met de rest van de opmaak. Dat was toch het hele achter de stylesheets? Dat je zonder met de html enz aan de gang gaat je gewoon het uiterlijk kan aanpassen?

Ik denk dat (in de context van een forum post zoals ik eerder aangaf) er hoogstens op de css aan te merken valt dat de benaming te generiek is.

True, maar je hebt het over iets wat meestal dynamisch tot stand komt. Over het algemeen sla je de ubb niet parsed op (tenzij je cached, maar je laat altijd een kopie van de originele content bestaan). Je kunt die wijzigingen dus doorvoeren in je parser.

Passenger schreef op zondag 12 juli 2009 @ 01:06:
Ik vind deze ook nog steeds erg fraai:

HTML:

<tr>
  <td class="content_even"></td>
</tr>
<tr>
  <td class="content_uneven"></td>
</tr>

Daar is helemaal niets mis mee hoor.

[StephanVierkant]

Behalve dat een rij met slechts één kolom vrij zinloos is

[Passenger]

Ehmm... uneven?

[momania]

'uneven' lol
Typisch hollanders aan het werk zo te zien... je zoekt je soms scheel in code gewoon omdat mensen alles verkeerd spellen/schrijven of soms gewoon helemaal geen engels gebruiken in hun code.

[Jaap-Jan]

That's odd.

[Hardfreak]

heb ik afgelopen week op mijn stage geschreven:

code:

sqlQuery.CommandText = "DELETE FROM T_EXECUTE WHERE F_EXECUTE_DATE < " + strDate + " AND F_STATUS = 1";

Werkt perfect, maar is toch gigantisch slecht geschreven


ps. strDate = was gewoon een string met een datum in YYYY-mm-dd stijl die 'k van een DateTime variabele had afgeleid, dus daar was ook niks mis mee

[ Voor 24% gewijzigd door Hardfreak op 12-07-2009 10:45 ]

[Haan]

Hardfreak schreef op zondag 12 juli 2009 @ 10:43:
heb ik afgelopen week op mijn stage geschreven:

code:

sqlQuery.CommandText = "DELETE FROM T_EXECUTE WHERE F_EXECUTE_DATE < " + strDate + " AND F_STATUS = 1";

Werkt perfect, maar is toch gigantisch slecht geschreven


ps. strDate = was gewoon een string met een datum in YYYY-mm-dd stijl die 'k van een DateTime variabele had afgeleid, dus daar was ook niks mis mee

Programming FAQ - SQL: Over het gebruik van Parametrized Queries

[Verwijderd]

momania schreef op zondag 12 juli 2009 @ 10:31:
'uneven' lol
Typisch hollanders aan het werk zo te zien... je zoekt je soms scheel in code gewoon omdat mensen alles verkeerd spellen/schrijven of soms gewoon helemaal geen engels gebruiken in hun code.

Passenger schreef op zondag 12 juli 2009 @ 10:18:
Ehmm... uneven?

Uneven is ook gewoon goed hoor. Synoniem van odd.

[ Voor 47% gewijzigd door Verwijderd op 12-07-2009 11:04 ]

[CJ_Latitude]

Een mooi leesbaar stukje uit ZenCart :

PHP:

...
?>
<?php
  if ($title) {
  ?>
<?php echo $title; ?>
<?php
 }
 ?>
<?php
...

Echt, hoe vaak kan je gaan switchen tussen PHP aan-en-uit bij iets waar ik in dit geval ($title is geset of niet) toch echt gewoon 1 regel zou gebruiken...

code:

...
echo $title;
...

[Haan]

CJ_Latitude schreef op zondag 12 juli 2009 @ 11:14:
Een mooi leesbaar stukje uit ZenCart :

PHP:

...
?>
<?php
  if ($title) {
  ?>
<?php echo $title; ?>
<?php
 }
 ?>
<?php
...

[ Voor 26% gewijzigd door Haan op 12-07-2009 11:19 ]

[Not Pingu]

Passenger schreef op zondag 12 juli 2009 @ 01:06:
Ik vind deze ook nog steeds erg fraai:

HTML:

<tr>
  <td class="content_even"></td>
</tr>
<tr>
  <td class="content_uneven"></td>
</tr>

Persoonlijk zet ik dat soort classes altijd op de <tr> ipv. op de <td>, dan kun je toch nog de hele row makkelijk stylen zonder dat je aan elke cell zo'n class moet hangen.

Cascading Stylesheet:

.content_even td
{
background-color: #f00;
}

.content_uneven td
{
background-color: #00f;
}

[fleppuhstein]

CJ_Latitude schreef op zondag 12 juli 2009 @ 11:14:
Een mooi leesbaar stukje uit ZenCart :

PHP:

...
?>
<?php
  if ($title) {
  ?>
<?php echo $title; ?>
<?php
 }
 ?>
<?php
...

Echt, hoe vaak kan je gaan switchen tussen PHP aan-en-uit bij iets waar ik in dit geval ($title is geset of niet) toch echt gewoon 1 regel zou gebruiken...

code:

...
echo $title;
...

Beter om zo te doen:

code:

<?php
  echo isset($title) ? $title : '';
?>

Levert geen warning op als title niet bestaat.

[Gomez12]

fleppuhstein schreef op zondag 12 juli 2009 @ 12:05:
[...]


Beter om zo te doen:

code:

<?php
  echo isset($title) ? $title : '';
?>

Levert geen warning op als title niet bestaat.

Dacht ik ook, maar het 1e voorbeeld kijkt ook niet of $title geset is. Hiermee krijg je dus andere functionaliteit...

[Haan]

Gomez12 schreef op zondag 12 juli 2009 @ 12:08:
[...]

Dacht ik ook, maar het 1e voorbeeld kijkt ook niet of $title geset is. Hiermee krijg je dus andere functionaliteit...

Dat 1e voorbeeld is juist een voorbeeld van hoe het niet moet hè, dus niet raar dat het daar dan niet in zit

[CJ_Latitude]

Haan schreef op zondag 12 juli 2009 @ 12:12:
[...]

Dat 1e voorbeeld is juist een voorbeeld van hoe het niet moet hè, dus niet raar dat het daar dan niet in zit

Hij bedoelde denk ik mijn verbeter-voorbeeld. Zeker true dat je 'm nog even kon checken, maar in deze situatie zijn de warnings bovenin de pagina uitgezet.

[hostname]

CJ_Latitude schreef op zondag 12 juli 2009 @ 12:14:
[...] maar in deze situatie zijn de warnings bovenin de pagina uitgezet.

Dat is op zichzelf al een slecht voorbeeld.

[ Voor 4% gewijzigd door hostname op 12-07-2009 12:36 ]

[Cartman!]

Niet mee eens, in een liveomgeving wil je geen errors tonen, die vang je af op een nette foutpagina. In development-omgeving geef ik je gelijk.

[CJ_Latitude]

hostname schreef op zondag 12 juli 2009 @ 12:36:
[...]

Dat is op zichzelf al een slecht voorbeeld.

Daar ben ik het opzich niet mee eens, zolang dit maar tot de productieomgeving beperkt blijft. De eindgebruiker moet natuurlijk geen letter server-code (of variabele namen) kunnen zien. De ontwikkel- & testomgevingen hebben het natuurlijk wel aanstaan.

EDIT:
Cartman!: Gamma

[ Voor 3% gewijzigd door CJ_Latitude op 12-07-2009 12:51 ]

[Patriot]

Stephan4kant schreef op zondag 12 juli 2009 @ 02:34:
Behalve dat een rij met slechts één kolom vrij zinloos is

Mja, eens, maar gezien het onderwerp leek het mij om de naamgeving van de classes te gaan. Daar is in ieder geval niets mis mee.

Er zijn duizend-en-één dingen te verzinnen wat je met die HTML allemaal fout kunt doen, maar dat is en blijft speculeren, en daar schieten we vrij weinig mee op in dit topic

[Soultaker]

fleppuhstein schreef op zondag 12 juli 2009 @ 12:05:
Beter om zo te doen:

code:

<?php
  echo isset($title) ? $title : '';
?>

Doe dan gelijk zo:

PHP:

<?php echo @$title ?>

Wel zo leesbaar.

[XWB]

Soultaker schreef op zondag 12 juli 2009 @ 14:51:
[...]

Doe dan gelijk zo:

PHP:

<?php echo @$title ?>

Wel zo leesbaar.

Foei.

[Soultaker]

Want?

[Verwijderd]

Soultaker schreef op zondag 12 juli 2009 @ 15:55:
Want?

Je onderdrukt gewoon de foutmelding.

[Soultaker]

En wat is daar mis mee? De eerder genoemde code doet immers precies hetzelfde.

[XWB]

Soultaker schreef op zondag 12 juli 2009 @ 16:02:
En wat is daar mis mee?

Foutmeldingen hoor je te voorkomen (in dit geval door te kijken of de variabele bestaat met isset () ) en plaatsen waar je foutmeldingen kan verwachten (zoals een database die eruit kan klappen) hoor je af te vangen en verder te verwerken.

De eerder genoemde code doet immers precies hetzelfde.

Dat doet het niet, het kijkt eerst of de variabele bestaat en indien ja, afdrukken naar het scherm.

[ Voor 4% gewijzigd door XWB op 12-07-2009 16:10 ]

[hostname]

Cartman! schreef op zondag 12 juli 2009 @ 12:49:
Niet mee eens, in een liveomgeving wil je geen errors tonen, die vang je af op een nette foutpagina. In development-omgeving geef ik je gelijk.

Ik zou op een productieomgeving niet graag de errors uitzetten, maar ze eerder niet zichtbaar voor de gebruiker afvangen en loggen. Word anders vrij moeilijk als iets op de liveomgeving niet werkt, maar je het niet op je developmentomgeving kan reproduceren. Dan zijn errorlogs wel is handig.

[ Voor 17% gewijzigd door hostname op 12-07-2009 16:17 ]

[IStealYourGun]

Volgend stukje is een volledige pagina van iemand die zijn zelf gemaakte webpagina kwam showen op een ander forum. Ik werd gewoon weg gefrustreerd na het zien van de code, zeker omdat het niet haar eerste webpagina is en omdat ik al meermaals fouten van haar verbeterd had en enkele goede links had gepost waar je de basis kan leren. Op de raadgeving: "Lees misschien best eerst eens het eerste hoofdstuk van een html cursus" kreeg ik het antwoord: "Daar heb ik dus geen zin in."

Een andere memorabele quote kwam van iemand anders toen ik hen uitlegde dat elke html-tag moest worden gesloten en dat elke (basic) html pagina met <html> moest beginnen en eindigen: "Serieus, webshit. Het spijt ons ENORM dat we niet zo'n grote kennis hebben op het gebied van websites, maar laat ons lekker genieten van wat we zelf kunnen knutselen!"

Ergens wel jammer want haar layout is best wel mooi.

code:

<head>

<title>--hier stond een titel die ik verwijderd heb--</title>

</head>

<body>

<style type="text/css">

BODY {background-image: url(bg.png); background-repeat: repeat}

<!--BODY{
scrollbar-3dlight-color: #D6D6D6;
scrollbar-arrow-color: #F57CB8;
scrollbar-base-color: #D6D6D6;
scrollbar-darkshadow-color: #F57CB8;
scrollbar-face-color: #D6D6D6;
scrollbar-highlight-color: #D6D6D6;
scrollbar-shadow-color: #B9B9B9;
scrollbar-track-color: #D6D6D6;
}-->


</style>

<img src="versie002.png" style="position:absolute;top:0;left:0">

<iframe FRAMEBORDER="0" BORDER=0 width=80 height=80 src="navigatie.html" 
name=home2 allowTransparency scrolling=no style="position:absolute; top:170px; left:582px" 
style="FILTER: chroma (color=#40FF40)"></iframe>

<iframe FRAMEBORDER="0" BORDER=0 width=330 height=700 src="000.html" 
name=home allowTransparency scrolling=no style="position:absolute; top:40px; left:242px" 
style="FILTER: chroma (color=#40FF40)"></iframe>

Ik heb trouwens 6 verschillende fouten gevonden die in totaal 16 keer voorkomen

[Soultaker]

Ok, blijkbaar zijn niet alle programmeurs even bekend met het principe van het scheiden van extern observeerbaar gedrag van implementatiedetails. In onderstaande beschrijving:

Hacku schreef op zondag 12 juli 2009 @ 16:10:
Foutmeldingen hoor je te voorkomen (in dit geval door te kijken of de variabele bestaat met isset ())

Rood is extern observeerbaar gedrag. Zowel mijn suggestie als die van fleppuhstein voorkomt de foutmelding wanneer $title niet gedefinieerd is. Functioneel zijn de snippets dus hetzelfde. Blauw is een mogelijke implementatie van dit gedrag, maar het is niet de enige mogelijke implementatie. Ik vind mijn aanpak beter omdat die korter en duidelijker is.

Dat doet het niet, het kijkt eerst of de variabele bestaat en indien ja, afdrukken naar het scherm.

Juist, dit is dus een verschil in implementatie, maar geen verschil in gedrag. Ik had ook wel gezien dat mijn code niet hetzelfde is, maar hij doet wel hetzelfde. Dus nogmaals: wat is er mis met deze implementatie van het gewenste gedrag?

[.oisyn]

Soultaker schreef op zondag 12 juli 2009 @ 14:51:
[...]

Doe dan gelijk zo:

PHP:

<?php echo @$title ?>

Wel zo leesbaar.

Ik vind de plek van @ nogal raar. Zou die niet voor de echo moeten staan?

.edit: ah nee, toch niet:

When prepended to an expression in PHP, any error messages that might be generated by that expression will be ignored

Ik dacht even dat je er statements mee moest prependen.

Overigens heeft je code niet hetzelfde resultaat. Althans, in de huidige PHP implementatie wellicht, maar je kunt je voorstellen dat er wel meer errors mogelijk kunnen zijn bij het accessen van die variabele (bijv. omdat ie private is en jij dus geen toegang hebt). Jij onderdrukt dan ook die error. Met een isset() zal dat niet het geval zijn. Het extern observeerbare gedrag is dus weldegelijk verschillend in dat geval.

[ Voor 58% gewijzigd door .oisyn op 12-07-2009 16:47 ]

[Verwijderd]

Dus omdat het korter en/of duidelijker leesbaar is ga je maar met opzet fouten maken, en vervolgens de foutmelding onderdrukken?

Tuurlijk, uiteindelijk doet het wat het moet doen, maar dat geld denk ik voor het grootste deel van de code gepost in dit topic...

[Gamebuster]

CJ_Latitude schreef op zondag 12 juli 2009 @ 11:14:
Een mooi leesbaar stukje uit ZenCart :

PHP:

...
?>
<?php
  if ($title) {
  ?>
<?php echo $title; ?>
<?php
 }
 ?>
<?php
...

Echt, hoe vaak kan je gaan switchen tussen PHP aan-en-uit bij iets waar ik in dit geval ($title is geset of niet) toch echt gewoon 1 regel zou gebruiken...

code:

...
echo $title;
...

code:

echo $title

kan een error geven wanneer $title niet bestaat en errors aanstaan. In 1 regel kan het als volgt:

PHP:

<?php
echo isset($title)?$title:'';
?>

[.oisyn]

Verwijderd schreef op zondag 12 juli 2009 @ 16:47:
Dus omdat het korter en/of duidelijker leesbaar is ga je maar met opzet fouten maken, en vervolgens de foutmelding onderdrukken?

Dus omdat je per se geen fouten wilt maken die verder totaal geen bijeffecten hebben, ga jij je code minder leesbaar maken?

@Gamebuster: anders lees je de topic voor je reageert.

[ Voor 15% gewijzigd door .oisyn op 12-07-2009 16:50 ]

[Verwijderd]

.oisyn schreef op zondag 12 juli 2009 @ 16:49:
[...]

Dus omdat je per se geen fouten wilt maken die verder totaal geen bijeffecten hebben, ga jij je code minder leesbaar maken?

@Gamebuster: anders lees je de topic voor je reageert.

Dat minder leesbaar is natuurlijk ook iets subjectiefs. Je weet dat er 2 mogelijkheden zijn, namelijk dat de variabel geset is, of dat hij niet geset is. Daarom vind ik de oplossing met isset veel beter leesbaar, omdat je dan gelijk ziet wat er in beide gevallen gebeurd.

[XWB]

Zowel mijn suggestie als die van fleppuhstein voorkomt de foutmelding wanneer $title niet gedefinieerd is.

Het is allemaal leuk dat php dit kan, en daarom doen we het ook? Druk in bijvoorbeeld C# even een variabele af die niet gedefinieerd en druk even op compilen

Ik vind mijn aanpak beter omdat die korter en duidelijker is.

Korter? Ja. Duidelijker? Nee, ik weet nu niet wat er gebeurt wanneer er fouten optreden.

wat is er mis met deze implementatie van het gewenste gedrag?

Eh, dat kan je toch zelf raden? Als je bijvoorbeeld een @mysql_connect() doet en de database ligt eruit, dan krijg een leeg scherm voor je neus. Dat lijkt me helemaal niet zo handig. Of ga je in dit geval wel een error handler inbouwen?

[ Voor 11% gewijzigd door XWB op 12-07-2009 16:53 ]

[.oisyn]

Verwijderd schreef op zondag 12 juli 2009 @ 16:51:
[...]

Dat minder leesbaar is natuurlijk ook iets subjectiefs. Je weet dat er 2 mogelijkheden zijn, namelijk dat de variabel geset is, of dat hij niet geset is. Daarom vind ik de oplossing met isset veel beter leesbaar, omdat je dan gelijk ziet wat er in beide gevallen gebeurd.

Dat is geen antwoord op mijn vraag en niet relevant voor de discussie die wij hadden. Soultaker stelde dat het leesbaarder was en daar ging jij in mee met je argument (je stelde het voorkomen van fouten belangrijker dan leesbare code). Dan moet je nu niet ineens zeggen dat je het niet leesbaar is om je eigen argument te verdedigen, aangezien dat niet van toepassing is

Hacku schreef op zondag 12 juli 2009 @ 16:52:
[...]


Het is allemaal leuk dat php dit kan, en daarom doen we het ook? Druk in bijvoorbeeld C# even een variabele af die niet gedefinieerd en druk even op compilen

C# is dan ook geen scripttaal waarbij variabelen mogelijk niet kunnen bestaan terwijl de code dan toch werkt. Nutteloos argument dus.

Eh, dat kan je toch zelf raden? Als je bijvoorbeeld een @mysql_connect() doet en de database ligt eruit, dan krijg een leeg scherm voor je neus

Hij doet toch geen mysql_connect(), of wel? De expressie omvat het accessen van een variabele, niet het aanroepen van een functie die om tal van redenen fout kan gaan.

Overigens prefereer ik zelf mysql_connect() weldegelijk aan te roepen met een @, zodat ik gewoon goede error afhandeling kan doen in die context ipv dat de gebruiker een error van PHP om z'n oren geslagen wordt. En custom error handlers zijn ook maar zo zo (namelijk niet context-afhankelijk).

[ Voor 40% gewijzigd door .oisyn op 12-07-2009 16:58 ]

[Gamebuster]

.oisyn schreef op zondag 12 juli 2009 @ 16:49:
[...]

Dus omdat je per se geen fouten wilt maken die verder totaal geen bijeffecten hebben, ga jij je code minder leesbaar maken?

@Gamebuster: anders lees je de topic voor je reageert.

PHP:

<?php

$t = microtime(1);

for($x = 10000;$x > 0;$x--) {
    echo @$title;
    //echo isset($title)?$title:'';
}

echo microtime(1)-$t;

?>

Gemiddeld: 0.019

PHP:

<?php

$t = microtime(1);

for($x = 10000;$x > 0;$x--) {
    //echo @$title;
    echo isset($title)?$title:'';
}

echo microtime(1)-$t;

?>

Gemiddeld: 0.002

Hoezo geen bijeffecten? De "onoverzichtelijke" maar correcte manier is toch wel wat sneller

[_JGC_]

Patriot schreef op zaterdag 11 juli 2009 @ 02:25:
De echte fout is de naamgeving die hij gebruikt. Je moet de naam die je geeft niet opstellen aan de hand van het uiteindelijke uiterlijk (dus klein, rood, groen, links-uitgelijnd, met een border bovenaan, etc.), maar aan de hand van de functie (notitie, waarschuwing, succes-bericht, alinea, etc.).

Meestal geef ik die dingen ids aan de hand van functies of plaatsing. Wel lachen als een concurrent dan letterlijk je HTML overkopieert incl indenting en ids. <div id="left"> stond bij de concurrent rechts op de site . En dan nog durven te beweren dat je dat zelf bedacht hebt... yeah right

[.oisyn]

Gamebuster schreef op zondag 12 juli 2009 @ 16:56:
Hoezo geen bijeffecten? De "onoverzichtelijke" maar correcte manier is toch wel wat sneller

Ah ja, en hoeveel invloed heeft dit op de totale executietijd van een productiescript, denk je? Het verschil dat jij laat zien is 20 milliseconden bij een uitvoer van 10000 variabelen die alle 10000 niet bestaan (!!!). Vind jij dat belangrijk genoeg om de leesbaarheid van de code in het geding te brengen?

[ Voor 10% gewijzigd door .oisyn op 12-07-2009 17:02 ]

[Soultaker]

.oisyn schreef op zondag 12 juli 2009 @ 16:44:
Overigens heeft je code niet hetzelfde resultaat. Althans, in de huidige PHP implementatie wellicht, maar je kunt je voorstellen dat er wel meer errors mogelijk kunnen zijn bij het accessen van die variabele [..]

Dat klopt, en er zijn nog wel meer observeerbare verschillen trouwens (ik geloof dat PHP eventuele custom error handling functions ook called met 0 als errorlevel, wat enigzins onlogisch is omdat die als level niet bestaat, maar het is PHP). Dat neemt niet weg dat als de situatie is dat je een variabele hebt waarvan je weet dat die ongedefinieerd zou kunnen zijn, en je wil de waarde afdrukken mits 'ie die heeft, dan voldoen beide methodes voor dat doel.

Overigens noem je wel een aardig punt: omdat je met @ alle foutmeldingen onderdrukt is het een operator die je niet te onpas moet gebruiken. Vandaar dat ik 'm vooral gebruik bij simpele expressies zoals in het voorbeeld, maar ook bijvoorbeeld als functies foutmeldingen genereren die ik zelf wil afhandelen:

PHP:

if (($str = @file_get_contents('foobar')) === FALSE) {
  // handle error
}

In een voorbeeld als dit is het onmogelijk om alle redenen waarom file_get_contents() zou kunnen falen van te voren te checken (zelfs als je b.v. checkt of een bestand bestaat is het lastig checken of je de juiste rechten hebt, en zelfs dan nog is er een race condition tussen je check en het uitvoeren van de functie).

Ik wil niet dat mijn logfiles (of erger: de HTML output) vervuild worden met foutmeldingen die ik kon verwachten en bereid ben om af te handelen. Ik wil dat juist onverwachtte fouten gelogd worden!

Verwijderd schreef op zondag 12 juli 2009 @ 16:47:
Dus omdat het korter en/of duidelijker leesbaar is ga je maar met opzet fouten maken [..]

Ik vind het feit dat code korter en/of duidelijker leesbaar wordt inderdaad een belangrijk argument om de ene snippet boven de andere te prefereren. Ik zie het niet als met opzet fouten maken; met de @-operator geef je juist aan dat in een expressie condities die normaalgesproken een foutmelding opleveren niet als zodanig behandeld moeten worden. Wat is daar fout aan? Het zou pas fout zijn als ik kan verwachten dat die variabele leeg is en er niets mee doe, maar ik handel die situatie juist af.

[Gamebuster]

.oisyn schreef op zondag 12 juli 2009 @ 17:02:
[...]

Ah ja, en hoeveel invloed heeft dit op de totale executietijd van een productiescript, denk je? Het verschil dat jij laat zien is 20 milliseconden bij een uitvoer van 10000 variabelen die niet bestaan (!!!)

als je overal met zulke kleine dingen rekening houdt kan je toch wel een flinke performance verschil merken. Alle kleine beetjes helpen, helemaal bij grote websites, ook al is dit wel heel klein. Verschil in leesbaarheid valt ook reuze mee, helmeaal als je het zo doet:

PHP:

<?php
if( isset( $title )) {
  echo $title;
}
?>

Niks onleesbaars aan.

[ Voor 14% gewijzigd door Gamebuster op 12-07-2009 17:07 ]

[Verwijderd]

.oisyn schreef op zondag 12 juli 2009 @ 16:54:
Dat is geen antwoord op mijn vraag en niet relevant voor de discussie die wij hadden. Soultaker stelde dat het leesbaarder was en daar ging jij in mee met je argument (je stelde het voorkomen van fouten belangrijker dan leesbare code). Dan moet je nu niet ineens zeggen dat je het niet leesbaar is om je eigen argument te verdedigen, aangezien dat niet van toepassing is

In dat geval vind ik de correcte manier nog steeds duidelijker, aangezien ik gelijk 'zie' dat er een fout zit in de echo @var;

Kost mijn hersenen ongeveer evenveel cpu cycles als het gooien van de notice maar niet weergeven van de foutmelding in php Minimaal, maar meetbaar, zoals het voorbeeld hierboven al heeft aangetoond.

[.oisyn]

Gamebuster schreef op zondag 12 juli 2009 @ 17:04:
[...]

als je overal met zulke kleine dingen rekening houdt kan je toch wel een flinke performance verschil merken. Alle kleine beetjes helpen, helemaal bij grote websites, ook al is dit wel heel klein.

Overigens is hij alleen bij een echo sneller. Als je $t = @$title; schrijft dan is dat sneller dan $t = isset($title) ? $title : '';
En mijn punt was, jij test al 10000 variabelen voor de echo. Dan heb je "al die kleine beetjes" dus al bij elkaar genomen. Echt niet dat in een groot script zoveel wordt geecho'd dat het verschil merkbaar is. Dan is maintainability van code toch echt veel belangrijker, omdat je daarmee meer tijd overhoudt om optimalisaties te doen die wél veel uitmaken. Of gewoon snellere hardware kunt kopen.

Verwijderd schreef op zondag 12 juli 2009 @ 17:06:
[...]

In dat geval vind ik de correcte manier nog steeds duidelijker, aangezien ik gelijk 'zie' dat er een fout zit in de echo @var;

Kost mijn hersenen ongeveer evenveel cpu cycles als het gooien van de notice maar niet weergeven van de foutmelding in php

Nogmaals, de aanname was dat het leesbaarder is. Als je dat niet vindt dan moet je het natuurlijk sowieso niet gebruiken. Desalniettemin ben ik (en Soultaker dus ook) het nog altijd oneens met je stelling dat het voorkomen van fouten die geen bij-effect hebben (vooropgenomen dat dat ook zo is) belangrijker is dan leesbare code.

Minimaal, maar meetbaar, zoals het voorbeeld hierboven al heeft aangetoond.

Zoals ik hierboven laat zien geldt dat gek genoeg alleen in de specifieke case van Gamebuster, en niet bij een assignment aan een andere variabele

[ Voor 42% gewijzigd door .oisyn op 12-07-2009 17:14 ]

[Gamebuster]

.oisyn schreef op zondag 12 juli 2009 @ 17:08:
[...]


Overigens is hij alleen bij een echo sneller. Als je $t = @$title; schrijft dan is dat sneller dan $t = isset($title) ? $title : '';
En mijn punt was, jij test al 10000 variabelen voor de echo. Dan heb je "al die kleine beetjes" dus al bij elkaar genomen. Echt niet dat in een groot script zoveel wordt geecho'd dat het verschil merkbaar is. Dan is maintainability van code toch echt veel belangrijker, omdat je daarmee meer tijd overhoudt om optimalisaties te doen die wél veel uitmaken. Of gewoon snellere hardware kunt kopen.


[...]

Nogmaals, de aanname was dat het leesbaarder is. Als je dat niet vindt dan moet je het natuurlijk sowieso niet gebruiken. Desalniettemin ben ik (en Soultaker dus ook) het nog altijd oneens met je stelling dat het voorkomen van fouten die geen bij-effect hebben (vooropgenomen dat dat ook zo is) belangrijker is dan leesbare code.

[...]

Zoals ik hierboven laat zien geldt dat gek genoeg alleen in de specifieke case van Gamebuster, en niet bij een assignment aan een andere variabele

Zo kan ik wel 100 voorbeelden erbij halen met je "alleen bij echo is het sneller".
Punt is: het uitvoeren van het script kost minder tijd wanneer je al je variablen alle benodigde controles geeft.

Je kan dan wel zeggen dat het minder leesbaar is maar in dit geval vind ik het ook nog eens beter leesbaar omdat ik dan weet dat het mogelijk is dat die variable niet bestaat.

PHP:

<?php
echo @$title;
?>

PHP:

<?php
if(isset($title)) {
  echo $title;
}
?>

De onderste methode is de beste en correcte methode wanneer je weet dat $title mogelijk niet bestaat, ook wanneer je over leesbaarheid praat. Je kan namelijk direct zien dat het mogelijk is dat $title niet bestaat.

Die @ is minder duidelijk omdat-ie ook andere errors tegenhoud.

het wordt tijd dat PHP komt met een try {} catch() {}

natuurlijk is dit een slap voorbeeld: je moet er gewoon voor zorgen dat je geen variablen gebruikt die mogelijk niet bestaan.

Over assignment van variable is weer een hele andere discussie mogelijk. Bij assignment komen weer andere factoren kijken.

[Verwijderd]

Nogmaals, de aanname was dat het leesbaarder is. Als je dat niet vindt dan moet je het natuurlijk sowieso niet gebruiken. Desalniettemin ben ik (en Soultaker dus ook) het nog altijd oneens met je stelling dat het voorkomen van fouten die geen bij-effect hebben (vooropgenomen dat dat ook zo is) belangrijker is dan leesbare code.

Wat ik wil zeggen is dat het met opzet maken van fouten per definitie onleesbaarder is, omdat het niet gelijk duidelijk is wat het resultaat is van het 'wel fout maken maar geen foutmelding weergeven', je ziet niet gelijk of er geen bij-effecten zijn. Helemaal in het geval van PHP moet je onvoorspelbaar gedrag zoveel mogelijk voorkomen (wat als ik een custom error_handler inbouw voor het loggen van fouten? wat als er straks een nieuwe php versie uitkomt?).

[XWB]

het wordt tijd dat PHP komt met een try {} catch() {}

Dat hebben ze al sinds PHP 5.0

[Soultaker]

Verwijderd schreef op zondag 12 juli 2009 @ 17:33:
Wat ik wil zeggen is dat het met opzet maken van fouten per definitie onleesbaarder is

Voor dat ik de rest van de rant behandel: kun je aangeven wat er nu precies "fout" aan is? Het gedrag van dat stukje PHP code is volledig gedefinieerd: een ongedefinieerde variabele evalueert naar NULL, waarbij bovendien een foutmelding met level E_NOTICE gegenereerd wordt, tenzij foutmeldingen onderdrukt worden. Waarom zou ik dat gedrag niet mogen exploiteren om kort-maar-krachtige code te schrijven die werkt zoals bedoeld?

Om het even buiten de PHP-sfeer te trekken: als ik in Windows CreateFile() aanroep met als argument de naam van een bestand dat niet bestaat (of dat ik om een andere reden niet in de gewenste mode kan openen) dan faalt die functie gewoon en dat kun je zien aan de return value en vervolgens kun je dat afhandelen. Dat het mogelijk is dat die functie faalt is géén teken dat de programmeur een fout heeft gemaakt; dat is iets wat gewoon voor kan komen. Je zult Windows programmeurs dan ook niet hemel en aarde zien bewegen om maar van te voren te kunnen bepalen of die call wel of niet mogelijk zou zijn (wat, zoals ik al eerder aangeef, toch al onmogelijk is in het algemene geval) maar gewoon die functie callen.

Waarom zou ik in PHP dan wel moeite moeten doen om van te voren te verifiëren of een functieaanroep misschien faalt als ik ook gewoon direct de functie kan aanroepen en eventueel falen daarna kan aanroepen? PHP verschilt alleen van andere omgevingen in de zin dat een foutmelding gegenereerd wordt (in een logfile, of in de HTML uitvoer) ongeacht of de programmeur de conditie zelf afhandeld. Vandaar dat je als programmeur de @-operator moet gebruiken als je de foutconditie zelf wil afhandelen in plaats van het genereren van een foutmelding. (Het is in die zin een soort halfslachtig exceptie-mechanisme.)

isset() is een prima functie voor als je onderscheid wil maken tussen een ongedefinieerde variable en een variabele met NULL als waarde, maar als ik een ongedefinieerde variabele niet wil weergeven, ben ik niet geïnteresseerd in dat verschil omdat echo NULL al weergeeft zoals ik wil (helemaal niet, namelijk).

Helemaal in het geval van PHP moet je onvoorspelbaar gedrag zoveel mogelijk voorkomen (wat als ik een custom error_handler inbouw voor het loggen van fouten? wat als er straks een nieuwe php versie uitkomt?).

Ja, wat dan? Dan blijft mijn code ook gewoon werken? Het gedrag is niet onvoorspelbaar; het is prima gedefinieerd. Als ze in een nieuwe PHP versie de @-operator eruit gooien ben ik de zak, maar dat geldt ook voor jouw code als ze de isset() functie schrappen, en geen van beide lijkt me erg waarschijnlijk.

[frickY]

Ze gooien niet de silence-operator (@) weg, maar hebben een scream-operator

[ Voor 4% gewijzigd door frickY op 12-07-2009 19:09 ]

[.oisyn]

Gamebuster schreef op zondag 12 juli 2009 @ 17:30:
Je kan dan wel zeggen dat het minder leesbaar is

Dat zijn niet mijn woorden. Ik heb nooit zoiets beweerd. Ik ging slechts mee in de discussie over leesbaarheid vs "correctheid".

Maar in dit geval vind ik het ook nog eens beter leesbaar omdat ik dan weet dat het mogelijk is dat die variable niet bestaat.

Prima, dát is een goede reden om voor jou eigen constructie te kiezen. Niet omdat het marginaal sneller is.

De onderste methode is de beste en correcte methode wanneer je weet dat $title mogelijk niet bestaat, ook wanneer je over leesbaarheid praat.

Subjectief. Als jij dat tweede leesbaarder vind dan is dat idd de beste methode. Correct is sowieso het allebei.

Over assignment van variable is weer een hele andere discussie mogelijk. Bij assignment komen weer andere factoren kijken.

Oh, welke dan?

[Soultaker]

Gamebuster schreef op zondag 12 juli 2009 @ 17:04:

PHP:

<?php
if( isset( $title )) {
  echo $title;
}
?>

Niks onleesbaars aan.

Ik vind het verschil tussen in-line PHP (op een enkele regel) en multiline soms wel groot. Vergelijk:

PHP:

<form method=".." action="..">
<input type="text" name="foo" value="<?php echo @$foo ?>">
<input type="text" name="bar" value="<?php echo @$bar ?>">
<input type="submit" value="Do Something">
</form>

Met jouw voorstel:

PHP:

<form method=".." action="..">
<input type="text" name="foo" value="<?php
if( isset( $foo ) ) {
    echo $foo;
}
?>">
<input type="text" name="bar" value="<?php
if( isset( $bar ) ) {
    echo $bar;
}
?>">
<input type="submit" value="Do Something">
</form>

Het probleem is niet eens zozeer dat het langer is, maar door de mix van HTML markup met multiline PHP code wordt het geheel onduidelijk i.m.o. Dan prefereer ik de vorm met alleen korte PHP expressies, wanneer dat mogelijk is.

Natuurlijk is leesbaarheid enigzins subjectief en ik wil niemand een specifieke coding style voorschrijven, maar het feit dat de discussie ermee begon dat mijn voorstel "fout" zou zijn ("foei!") en dat de opponenten nu teruggekrabbeld zijn en het er op houden dat de isset() methode sneller is (lekker boeiend ) of men het persoonlijk beter leesbaar vind, interpreteer ik als winst.

[XWB]

of men het persoonlijk beter leesbaar vind,

Tja, het blijft persoonlijk. Net zoals jouw voorbeelden voor mij alles behalve leesbaar zijn; ik hou m'n html gescheiden van php code. Maar dat is weer een andere discussie.

[Verwijderd]

PHP:

<form method=".." action="..">
<input type="text" name="foo" value="<?php echo isset($foo) ? $foo : ''; ?>">
<input type="text" name="bar" value="<?php echo isset($bar) ? $bar : 'default value'; ?>">
<input type="text" name="bar" value="<?php echo array_key_exists('aap', $array) ? $array['aap'] : ''; ?>">
<input type="submit" value="Do Something">
</form>

Zo zou ik het waarschijnlijk doen

Maar zoiezo, als je gewoon je variabelen declareerd heb je het hele probleem niet. Ik ben dit probleem irl nog nooit tegen gekomen in elk geval.

ik hou m'n html gescheiden van php code.

Ik maak meestal of gebruik van een template engine (GeryEngine zit wel goed in elkaar, of Smarty). Of ik gebruik PHP als template taal (waar het oorspronkelijk ook voor bedoeld was), en dan kan een situatie zoals hierboven wel voorkomen.

[ Voor 23% gewijzigd door Verwijderd op 12-07-2009 22:15 ]

[Patriot]

.oisyn schreef op zondag 12 juli 2009 @ 23:34:
[...]

Alsjeblieft niet. Ik bespaar m'n gebruikers liever de lelijke PHP error meldingen.

Daar heb je dan weer geen error control operator voor nodig. Sterker nog, als je zonder dat ding werkt is je uiteindelijke code denk ik leesbaarder (gewoon je eigen error handler instellen).

De hele aversie tegen het gebruik wat Soultaker voorstelde is meer een knee-jerk-reaction dan dat men objectief naar dat wat Soultaker voorstelde keek. Het is in zijn geval namelijk verre van problematisch, en een prima gebruik van de error control operator.

[.oisyn]

Patriot schreef op maandag 13 juli 2009 @ 03:42:

Daar heb je dan weer geen error control operator voor nodig. Sterker nog, als je zonder dat ding werkt is je uiteindelijke code denk ik leesbaarder (gewoon je eigen error handler instellen).

Zoals ik al zei, dat is niet context-gevoelig. Error handlers in PHP werken nogal ruk imho. Als ik een file wil openen met fopen(), en die file mag best nog niet bestaan, dan ben ik helemaal niet geïnteresseerd in een error handler. fopen() die gewoon false retourneert is prima. De @ is dan noodzakelijk (of je moet moeilijk gaan doen door tijdelijk een nieuwe dummy handler in te stellen die niets doet (waarbij je mogelijk ook nog eens hele andere errors negeert), of tijdelijk de E_WARNING uit de error reporting gooien)

[ Voor 6% gewijzigd door .oisyn op 13-07-2009 04:01 ]

[Patriot]

Ah, nvm ook, ik zie nu dat ik je opmerking compleet uit zijn context las. Ik denk dat het tijd wordt voor een nieuw stukje slechte code, waar we weer hartelijk om moeten kunnen lachen. Dit loopt namelijk uit op niets.

[roy-t]

Ik heb voor de lol is even oude code open getrokken voor aller vermaak .

Als eerste wist ik vroeger niet van de this operator en hoe null nu precies werkte/

C#:

public LayerState(BaseLayer _screen, int _postprocessor_1, int _postprocessor_2, int _postprocessor_3, bool _isactive)
{
                if (_screen != null)
                {
                    Screen = _screen;
                }
                else
                {
                    Screen = null;
                }
                                
                PostProcessor_1 = _postprocessor_1;
                PostProcessor_2 = _postprocessor_2;
                PostProcessor_3 = _postprocessor_3;
}

Ook enums was ik zoals boven te zien nog niet helemaal bekend mee . Ik had een enum en gebruikte !intern! die enum om te kijken of een int in de constructor iets betekende .

Iets verderop ging het al wat beter met die enums, maar toen kwam ik het volgende stukje code tegen. Zo maakte ik 'dynamisch' een hoofd menu aan in een spelletje.

C#:

            ItemNames[(int)Menus.Main, Items[(int)Menus.Main]] = "Main Menu";
            ItemNames[(int)Menus.Main, (int)MainMenu.Newgame] = "New Game";
            ItemNames[(int)Menus.Main, (int)MainMenu.LoadSave] = "Load Save";
            ItemNames[(int)Menus.Main, (int)MainMenu.Options] = "Options";
            ItemNames[(int)Menus.Main, (int)MainMenu.Quit] = "Quit";

            ItemNames[(int)Menus.NewGame, Items[(int)Menus.NewGame]] = "New Game";
            ItemNames[(int)Menus.NewGame, (int)NewGameMenu.Start] = "Start";
            ItemNames[(int)Menus.NewGame, (int)NewGameMenu.Level] = "Level";
            ItemNames[(int)Menus.NewGame, (int)NewGameMenu.Difficulty] = "Difficulty";
            ItemNames[(int)Menus.NewGame, (int)NewGameMenu.Back] = "Back";

            ItemNames[(int)Menus.LoadSave, Items[(int)Menus.LoadSave]] = "Load and Save";
            ItemNames[(int)Menus.LoadSave, (int)LoadSaveMenu.Save] = "Save";
            ItemNames[(int)Menus.LoadSave, (int)LoadSaveMenu.Load] = "Load";
            ItemNames[(int)Menus.LoadSave, (int)LoadSaveMenu.Back] = "Back";

            ItemNames[(int)Menus.Options, Items[(int)Menus.Options]] = "Options";
            ItemNames[(int)Menus.Options, (int)OptionsMenu.Back] = "Back";

            ItemNames[(int)Menus.Quit, Items[(int)Menus.Quit]] = "Quit";
            ItemNames[(int)Menus.Quit, (int)QuitMenu.Yes] = "Yes";
            ItemNames[(int)Menus.Quit, (int)QuitMenu.No] = "No";
            

            Items[(int)Menus.Main] = 4;
            Items[(int)Menus.NewGame] = 4;
            Items[(int)Menus.LoadSave] = 3;
            Items[(int)Menus.Options] = 1;
            Items[(int)Menus.Quit] = 2;

En tsja deze code die zorgde ervoor dat mijn 'dynamische' menu dingen kon doen (prachtig ).

C#:

if (keys.IsKeyDown(Keys.Down) && !oldKeys.IsKeyDown(Keys.Down))
                { CurrentMenuItem++; }

                if (keys.IsKeyDown(Keys.Up) && !oldKeys.IsKeyDown(Keys.Up))
                { CurrentMenuItem--; }

                if (CurrentMenuItem >= Items[CurrentMenu])
                {
                    CurrentMenuItem = 0;
                }
                if (CurrentMenuItem < 0)
                {
                    CurrentMenuItem = Items[CurrentMenu] - 1; //Items is altijd 1 meer dan zerobased array
                }

                //////////////////////
                //Inputs voor Menus //
                //////////////////////
                switch (CurrentMenu)
                {
                    case (int)Menus.Main:

                        if (keys.IsKeyDown(Keys.Enter) && !oldKeys.IsKeyDown(Keys.Enter))
                        {
                            CurrentMenu = CurrentMenuItem + 1; //Omdat Main Menus.0 is, zal het volgende menu altijd CurrentMenuItem + 1 zijn
                            CurrentMenuItem = 0;
                        }

                        if (keys.IsKeyDown(Keys.Escape) && !oldKeys.IsKeyDown(Keys.Escape))
                        {
                            CurrentMenu = (int)Menus.Quit;
                        }

                        break;

                    case (int)Menus.NewGame:

                        if (keys.IsKeyDown(Keys.Enter) && !oldKeys.IsKeyDown(Keys.Enter))
                        {
                            if (CurrentMenuItem == (int)NewGameMenu.Back)
                            {
                                CurrentMenu = (int)Menus.Main;
                            }
                        }

                        break;

                    case (int)Menus.LoadSave:

                        if (keys.IsKeyDown(Keys.Enter) && !oldKeys.IsKeyDown(Keys.Enter))
                        {
                            if (CurrentMenuItem == (int)LoadSaveMenu.Back)
                            {
                                CurrentMenu = (int)Menus.Main;
                            }
                        }


                        break;

                    case (int)Menus.Options:

                        if (keys.IsKeyDown(Keys.Enter) && !oldKeys.IsKeyDown(Keys.Enter))
                        {
                            if (CurrentMenuItem == (int)OptionsMenu.Back)
                            {
                                CurrentMenu = (int)Menus.Main;
                            }
                        }

                        break;

                    case (int)Menus.Quit:

                        if (keys.IsKeyDown(Keys.Enter) && !oldKeys.IsKeyDown(Keys.Enter))
                        {
                            if (CurrentMenuItem == (int)QuitMenu.Yes)
                            {
                                Unload(1.0);
                            }
                            if (CurrentMenuItem == (int)QuitMenu.No)
                            {
                                CurrentMenu = (int)Menus.Main;
                            }
                        }

                        break;
                }

Oh well, tot dusver de oude truken doos, het is niet vreselijk dramatisch maar toch wel fijn om te weten dat dit me nu een stuk beter af gaat.

[Olaf van der Spek]

.oisyn schreef op zondag 12 juli 2009 @ 16:54:
Overigens prefereer ik zelf mysql_connect() weldegelijk aan te roepen met een @, zodat ik gewoon goede error afhandeling kan doen in die context ipv dat de gebruiker een error van PHP om z'n oren geslagen wordt.

Is het dan niet handiger gewoon (inline) error reporting uit te zetten?

[Voutloos]

Olaf van der Spek schreef op maandag 13 juli 2009 @ 10:16:
[...]
Is het dan niet handiger gewoon (inline) error reporting uit te zetten?

Dat is natuurlijk stukken anders dan @ gebruiken.

[Sebazzz]

.oisyn schreef op zondag 12 juli 2009 @ 23:34:
[...]

Alsjeblieft niet. Ik bespaar m'n gebruikers liever de lelijke PHP error meldingen.

Dat zie ik aan de lelijke PHP error meldingen bij de demo's op je site

[Woy]

.oisyn schreef op maandag 13 juli 2009 @ 11:58:
[...]

Hey da's ook wel een aardige oplossing idd

Woy in "[alg] Slechtste programmeervoorbeelden d..."

Daar kwamen we het vorige rondje met PHP ook al op uit

[Sebazzz]

Ik lever ook maar een bijdrage aan dit topic. Gemaakt tijdens de informatica lessen op de middelbare school en dit was mijn eerste C# programma Een programma om de schoolcomputers te hacken en in het administrator account te komen: haxor.7z (408 KB)
Source zit erbij, inloggen moet met Sebazzz/haxor. Ik heb alle gevaarlijke code eruit gesloopt, dus wat er nog van over is is onschuldig en dan moet je denken aan dingen ala Netmessenger. Een greep uit de source:

C#:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.IO;
using System.Net;
using System.Net.NetworkInformation;
using System.Threading;
using System.Net.Sockets;
using System.Diagnostics;
using System.Runtime.InteropServices;
using System.Resources;
using System.Reflection;
using haxor.Properties;
using haxorauth;
using System.Security;
using Microsoft.Win32;

C#:

     public static string B2S(bool bol)
        {
            if (bol == true) { return "true"; } else { return "false"; }
        }

C#:

if (netmsgservicectl.Status != System.ServiceProcess.ServiceControllerStatus.Running)
            {
                netmsgservicectl.Start( );
                try
                {
                    netmsgservicectl.WaitForStatus( System.ServiceProcess.ServiceControllerStatus.Running, System.TimeSpan.FromMilliseconds( 5000 ) );
                }
                catch (Exception ee)
                {
                    ee.HelpLink = "";
                    DialogResult res = MessageBox.Show( this, "De netmessenger service staat vast en kan niet worden gestopt of gestart. Probeer het later nog eens of herstart de computer.", "Netmessenger fout", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Exclamation, MessageBoxDefaultButton.Button1 );
                    while (res == DialogResult.Retry)
                    {
                        netmsgservicectl.Start( );
                        netmsgservicectl.WaitForStatus( System.ServiceProcess.ServiceControllerStatus.Running, System.TimeSpan.FromMilliseconds( 5000 ) );
                        if (netmsgservicectl.Status != System.ServiceProcess.ServiceControllerStatus.Running)
                        {
                            res = MessageBox.Show( this, "De netmessenger service staat vast en kan niet worden gestopt of gestart. Probeer het later nog eens of herstart de computer.", "Netmessenger fout", MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Exclamation, MessageBoxDefaultButton.Button1 );
                            if (res == DialogResult.Ignore)
                            {
                                break;
                            }
                            if (res == DialogResult.Abort)
                            {
                                this.Close( );
                            }
                        }
                        else
                        {
                            break;
                        }
                    }
                }
            }

[Erkens]

Woy schreef op maandag 13 juli 2009 @ 12:49:
[...]

Woy in "[alg] Slechtste programmeervoorbeelden d..."

Daar kwamen we het vorige rondje met PHP ook al op uit

Zelf geef ik toch de voorkeur aan de oplossing die in een van die reacties op php.net gegeven is:

PHP:

set_error_handler(create_function('$a, $b, $c, $d', 'throw new ErrorException($b, 0, $a, $c, $d);'), E_ALL);

Sebazzz schreef op maandag 13 juli 2009 @ 13:06:

C#:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.IO;
using System.Net;
using System.Net.NetworkInformation;
using System.Threading;
using System.Net.Sockets;
using System.Diagnostics;
using System.Runtime.InteropServices;
using System.Resources;
using System.Reflection;
using haxor.Properties;
using haxorauth;
using System.Security;
using Microsoft.Win32;

Wat is er precies mis met deze code? Ik ben dan geen C# expert (werk er niet professioneel mee ) maar als je deze includes ook gebruikt, is er toch niks mis mee?

[Haan]

Sebazzz schreef op maandag 13 juli 2009 @ 13:06:
Ik lever ook maar een bijdrage aan dit topic. Gemaakt tijdens de informatica lessen op de middelbare school en dit was mijn eerste C# programma Een programma om de schoolcomputers te hacken en in het administrator account te komen: haxor.7z (408 KB)
Source zit erbij, inloggen moet met Sebazzz/haxor. Ik heb alle gevaarlijke code eruit gesloopt, dus wat er nog van over is is onschuldig en dan moet je denken aan dingen ala Netmessenger. Een greep uit de source:

C#:

// Bestaat onze Authentication lib?
if (!File.Exists( "haxauth.dll" ))
{
        MessageBox.Show( this, "Fatale fout: Haxor Authentication Library haxauth.dll niet gevonden! Uitvoering gestaakt!", "DLL bestand niet gevonden", MessageBoxButtons.OK, MessageBoxIcon.Error, MessageBoxDefaultButton.Button1 );
      Application.Exit( );
}

Altijd leuk om het wiel opnieuw uit te vinden

[RobIII]

Erkens schreef op maandag 13 juli 2009 @ 13:14:
Wat is er precies mis met deze code? Ik ben dan geen C# expert (werk er niet professioneel mee ) maar als je deze includes ook gebruikt, is er toch niks mis mee?

De volgende usings worden niet gebruikt:

C#:

using System.Collections.Generic;
using System.Data;
using System.Linq;
using System.Threading;
using System.Runtime.InteropServices;
using System.Resources;

Daarbij is het, maar dan moet je het project even inzien, wel wat veel om allemaal in een "mainform" te plempen. Welke bestaat uit 1876 regels code uit de categorie "van alles en nog wat"*, wat ook reflecteert in de usings

* of beter: zo goed als alle code

En er zitten nog wel wat WTF's in inderdaad

C#:

protected static string [] Usernames =  {"Sebazzz", "Van IJzeren" , "Van IJzeren"};
protected static string [] Passwords =  {"haxor",   "hacker", "hacker" };

Die vond ik wel leuk Zeker omdat die in een eigen project zit dat verder niets doet

[ Voor 20% gewijzigd door RobIII op 13-07-2009 13:34 ]

[Haan]

De Authenticate functie zelf is ook wel aardig:

C#:

public static bool Authenticate( string Username, string Password)
        {
            bool ucorr = false;
            bool pcorr = false;
            int u = Usernames.GetLength(0);
            int p = Passwords.GetLength(0);
            int c = 0;

            while (c < u)
            {
                ucorr = (Username == Usernames[c]);
                if (ucorr == true)
                {
                    break;
                }
                else
                {
                    c++;
                }
            }
            if (ucorr) { pcorr = (Password == Passwords[c]); }
            return ((ucorr == true) && (pcorr == true));
        }

Daar zou je iets als dit van kunnen maken:

C#:

public static bool Authenticate2(string userName, string pw)
{
    // deze lijst staat hier alleen even als voorbeeld
    Dictionary<string, string> usersWithPassword = new Dictionary<string, string>();
    usersWithPassword.Add("Sebazzz", "hax0r");
    usersWithPassword.Add("Haan", "1337h4x0r");

    if (usersWithPassword.ContainsKey(userName))
    {
        return usersWithPassword[userName].Equals(pw);
    }

    return false;
}

Het is ook wel vervelend dat je de users + wachtwoorden zo uit kan lezen

code:

        void  .cctor() cil managed
{
  // Code size       75 (0x4b)
  .maxstack  3
  .locals init (string[] V_0,
           string[] V_1)
  IL_0000:  ldc.i4.3
  IL_0001:  newarr     [mscorlib]System.String
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  ldc.i4.0
  IL_0009:  ldstr      "Sebazzz"
  IL_000e:  stelem.ref
  IL_000f:  ldloc.0
  IL_0010:  ldc.i4.1
  IL_0011:  ldstr      "Van IJzeren"
  IL_0016:  stelem.ref
  IL_0017:  ldloc.0
  IL_0018:  ldc.i4.2
  IL_0019:  ldstr      "Van IJzeren"
  IL_001e:  stelem.ref
  IL_001f:  ldloc.0
  IL_0020:  stsfld     string[] haxorauth.LoginAuth::Usernames
  IL_0025:  ldc.i4.3
  IL_0026:  newarr     [mscorlib]System.String
  IL_002b:  stloc.1
  IL_002c:  ldloc.1
  IL_002d:  ldc.i4.0
  IL_002e:  ldstr      "haxor"
  IL_0033:  stelem.ref
  IL_0034:  ldloc.1
  IL_0035:  ldc.i4.1
  IL_0036:  ldstr      "hacker"
  IL_003b:  stelem.ref
  IL_003c:  ldloc.1
  IL_003d:  ldc.i4.2
  IL_003e:  ldstr      "hacker"
  IL_0043:  stelem.ref
  IL_0044:  ldloc.1
  IL_0045:  stsfld     string[] haxorauth.LoginAuth::Passwords
  IL_004a:  ret
} // end of method LoginAuth::.cctor

[ Voor 33% gewijzigd door Haan op 13-07-2009 14:06 ]

[Sebazzz]

Daarvoor heb je obfuscators, maar wist ik veel. Het was mijn eerste C# programma

[RobIII]

Sebazzz schreef op maandag 13 juli 2009 @ 14:13:
maar wist ik veel. Het was mijn eerste C# programma

Dat maakt niet dat we je daarom niet mogen uitlachen

(/plaagmode hoor )

[.oisyn]

Sebazzz schreef op maandag 13 juli 2009 @ 14:13:
Daarvoor heb je obfuscators

Nee dus. Obfuscators wijzigen de namen van identifiers in je programma, niet de inhoud van strings

[Sebazzz]

.oisyn schreef op maandag 13 juli 2009 @ 14:30:
[...]

Nee dus. Obfuscators wijzigen de namen van identifiers in je programma, niet de inhoud van strings

SmartAssembly wel (okey, het is wel wat meer dan een obfuscator).

[Matis]

C++:

if (critical_operation() == FAILED) {
    /* Uh oh. Quick, we need a distraction! */
    switch((rand() % 4)) {
        case 0: blame = "killall -SEGV kick_watchdog";     break;
        case 1: blame = "killall -ABRT cli_process";       break;
        case 2: blame = "cat /dev/urandom >/proc/kmem";    break;
        case 3: blame = "killall -FPE  hardware_manager";  break;
    }
    system(blame);
    system("rm /var/log/*.log"); /* Destroy the evidence */
    sleep(10); /* Wait for the other process to die first */
    return;
}

http://codingrelic.geekho...ugs-demand-desperate.html

[ Voor 6% gewijzigd door Matis op 13-07-2009 16:12 ]

[roy-t]

Matis schreef op maandag 13 juli 2009 @ 16:11:

C++:

if (critical_operation() == FAILED) {
    /* Uh oh. Quick, we need a distraction! */
    switch((rand() % 4)) {
        case 0: blame = "killall -SEGV kick_watchdog";     break;
        case 1: blame = "killall -ABRT cli_process";       break;
        case 2: blame = "cat /dev/urandom >/proc/kmem";    break;
        case 3: blame = "killall -FPE  hardware_manager";  break;
    }
    system(blame);
    system("rm /var/log/*.log"); /* Destroy the evidence */
    sleep(10); /* Wait for the other process to die first */
    return;
}

http://codingrelic.geekho...ugs-demand-desperate.html

Prachtig, dat is pas echt defensive programming! Ik zou het haast offensive programming noemen zelfs. Zo blijf je toch boven op de voedsel keten .

[kenneth]

T:\>ConsoleApplication1.exe

Onverwerkte uitzondering: System.DivideByZeroException: Poging door nul te delen.
   bij ConsoleApplication1.Program.Main(String[] args)

Welke klapmongool heeft bedacht om dit soort foutmeldingen te gaan localizen?

/rant

* kenneth belt de systeembeheerder maar eens even ... zucht

[Haan]

.Net ontwikkelen op een NL systeem is een ramp ja Je komt er ook niet vanaf, behalve door een engelstalig OS te installeren..

[ Voor 42% gewijzigd door Haan op 14-07-2009 09:52 ]

[HawVer]

kenneth schreef op dinsdag 14 juli 2009 @ 09:46:

T:\>ConsoleApplication1.exe

Onverwerkte uitzondering: System.DivideByZeroException: Poging door nul te delen.
   bij ConsoleApplication1.Program.Main(String[] args)

Welke klapmongool heeft bedacht om dit soort foutmeldingen te gaan localizen?

/rant

* kenneth belt de systeembeheerder maar eens even ... zucht

Wat Haan zegt. .NET maakt er dat soort dwaze nietszeggende meldingen van:

Nog één:

de objectverwijzing is niet op een exemplaar van een object ingesteld (Aha, nu weet ik wat ik moet doen!)

[Matis]

Lol, zie ook Xander in "Engels voorkeur boven Nederlands bij pro..."

[Woy]

Haan schreef op dinsdag 14 juli 2009 @ 09:50:
.Net ontwikkelen op een NL systeem is een ramp ja Je komt er ook niet vanaf, behalve door een engelstalig OS te installeren..

Volgens mij kom je er gewoon vanaf door een onderdeel van .net te de-installeren.

Ik kwam laatst ook wel een "leuke" vertaling tegen in File-Zilla

"Bezig met host naam oplossen" , ja resolve betekent oplossen als je het letterlijk vertaald, maar in deze context klint het nogal stom.

edit:
Zie ook \[.NET]Localized exceptions uitschakelen, als je de language pack deinstalleert krijg je wel ( gedeeltelijk ) engelse exceptions

[ Voor 37% gewijzigd door Woy op 14-07-2009 10:08 ]

[Afvalzak]

roy-t schreef op dinsdag 14 juli 2009 @ 09:42:
[...]


Prachtig, dat is pas echt defensive programming! Ik zou het haast offensive programming noemen zelfs. Zo blijf je toch boven op de voedsel keten .

Haha prachtig, dat commentaar ook

[Haan]

Woy schreef op dinsdag 14 juli 2009 @ 10:04:
[...]

Volgens mij kom je er gewoon vanaf door een onderdeel van .net te de-installeren.


edit:
Zie ook \[.NET]Localized exceptions uitschakelen, als je de language pack deinstalleert krijg je wel ( gedeeltelijk ) engelse exceptions

Iedereen roept dat altijd wel, maar ik heb nog niet gezien dat het ook echt kan. Dat topic is van jou zelf, maar er staat ook niet in of het jou uiteindelijk gelukt is, mij in ieder geval niet.. Daarom is volgens mij de enige oplossing om je OS in het engels te draaien.

[kenneth]

Ik heb mijn eigen computer zelf geinstalleerd, dus daar gaat het wel goed. Dit is op de server waar de software gedeployed moet gaan worden. Maargoed, ik laat het maar zitten, het is de moeite niet waard. Mijn software is toch foutloos

[Matis]

kenneth schreef op dinsdag 14 juli 2009 @ 10:18:
Mijn software is toch foutloos

Ik installeer sinds kort alleen nog maar Engelse OS-en (iig voor het gezin). Het is even wennen, maar van Engels --> NL is een stuk eenvoudiger dan andersom. Tijdens het ontwikkelen is een foutmelding op zn Engels ook makkelijker te Googlen dan dat ie nog vertaald moet worden of op zn NL gezocht moet worden

[Woy]

Haan schreef op dinsdag 14 juli 2009 @ 10:12:
[...]
Iedereen roept dat altijd wel, maar ik heb nog niet gezien dat het ook echt kan. Dat topic is van jou zelf, maar er staat ook niet in of het jou uiteindelijk gelukt is, mij in ieder geval niet.. Daarom is volgens mij de enige oplossing om je OS in het engels te draaien.

In mijn laatste reply daar staat dat het gedeeltelijk geholpen heeft. Ik heb ondertussen al lang een andere pc waar wel gewoon engelse windows op staat. Ik kan het nog wel even op mijn laptop proberen.

[kenneth]

Matis schreef op dinsdag 14 juli 2009 @ 10:20:
[...]

Nee, echt!

Haan schreef op dinsdag 14 juli 2009 @ 10:12:
[...]

Iedereen roept dat altijd wel, maar ik heb nog niet gezien dat het ook echt kan. Dat topic is van jou zelf, maar er staat ook niet in of het jou uiteindelijk gelukt is, mij in ieder geval niet.. Daarom is volgens mij de enige oplossing om je OS in het engels te draaien.

Ik heb WinXP in het Nederlands hier, maar alles van .NET --van runtime tot VS.NET-- is gewoon in het Engels. Helaas heb ik geen flauw idee meer hoe ik het heb gedaan. Wat mij betreft een grote misser van MSFT. Je zou moeten kunnen snappen dat Engels veel breder geaccepteerd is in de developer community ... maak het dan op z'n minst mogelijk om makkelijk voor Engels te kiezen ...

[Woy]

Ik heb het net geprobeerd. Ik had eerst nederlandse exceptions, en nadat ik de language packs ( .net 2.0 en 3.0 ) gedeinstalleerd had kreeg ik gewoon engelse exceptions. Gewoon zoals je zou verwachten dus.

[Sebazzz]

Je kan ook .NET 4 installeren, heb je ook weer Engelse exceptions Ik snap zowieso niet dat dingen zoals NullReferenceExceptions en Argument****Exceptions vertaald zijn. De gebruiker van het programma heeft niets aan zulke interne fouten. Het enige waar de gebruiker wel wat aan heeft zijn exceptions ala IOException, maar meestal weet je als programmeur al wat aan de hand is er is het niet nodig om een Exception.Message te weergeven.

Matis schreef op dinsdag 14 juli 2009 @ 10:04:
Lol, zie ook Xander in "Engels voorkeur boven Nederlands bij pro..."

Wat moet ik mij voorstellen bij een gegevenshouthakker? En met een bocht op een schakelaar (voor lezing van boomstronk gegevens) aansluiten?

[ Voor 30% gewijzigd door Sebazzz op 14-07-2009 11:45 ]