[PHP] (te)veel brakke code

[Verwijderd]

Vaak merk ik het op mn werk dat de code die mn collega's produceren niet op een al te hoog niveau zijn. Natuurlijk, iedereen moet leren, maar ook veel te downloade code (waarvan een beginner toch van moet leren) is meestal ook aardige spagetti.
In deze thread was al al enige discussie over OSCommerce begonnen, maar zelf heb ik het vermoeden dat dit voor +- 95% van de code is die zo te downloaden is.
Dan komt natuurlijk de vraag naar boven "Wat is goeie code?". Voor een beginner is het ook erg moeilijk om het meteen goed te beginnen... maar misschien is het handig om eens vast te stellen wat nu eigenlijk goed is.

Zelf heb ik dit lijstje gemaakt met punten waar code aan moet voldoen:
-goed uitbreidbaar -> veel code is niet eenvoudig recyclebaar en hier bedoel ik dan niet mee dat het niet te gebruiken is nadat alles is gecopyenpaste en daarna hier en daar iets is aangepast, maar dat er weinig gebruik wordt gemaakt van classes die weer eenvoudig aangeroepen kunnen worden indien het ergens nodig is. Misschien is OO dus een goeie oplossing.
-goed gestructureerd -> functies moeten op een logische plaats neer gezet worden, html & code moet goed gescheiden blijven
-veilig -> het is al mooi om te zien dat addslashes veel gebruikt wordt (hoewel dit vaak zorgt voor een dubbel addslashes idee omdat standaard magic slash meuk van php aanstaat), maar de veel zo te downloade code is lek. Gelukkig blijft het meestal maar bij een javascript injection mogelijkheid, maar in een redelijk aantal gevallen is er meer mogelijk, bijvoorbeeld password omzeiling of zelfs file inclusion.
-effectief -> dit is zeker iets wat voor een beginner moeilijk is. Net als elke andere taal moet php door en door gesnapt worden voordat de perfect effectieve code tevoorschijn komt. Helaas blijft het niet logisch nadenken zorgen voor veel onnodige code. Bijvoorbeeld het include van een file dmv include("http://eigenserver/bla..."); of het 10 keer copy&pasten van een stukkie code dat makkelijk in een functie had gekunt.

Ik hoop dat een van jullie hier nog wat aan toe te voegen heeft (of mij wil afzeiken ) en dat er een keer gedacht wordt voordat er zomaar wat code geproduceerd wordt en zo op het net gegooid wordt.

[Riball]

Waarom schrijf je nie een tutorial?

Als jij zoveel goeie ideeen heb wil ik de uitwerking ervan wel eens zien!

[AtleX]

Jij hebt het hier over het gebruik van classes, ik denk dat het een persoonlijke keuze is die mensen maken. Ik gebruik eigenlijk altijd functies, deze in de map /functions/ die weer onderverdeeld is in de mappen /functions/mysql/ of /funtions/formhandlers/. Dat is iets wat ik wel vaak mis bij andere (beginnende) programmeurs: een goede, duidelijke, mapstructuur.

[Verwijderd]

Riball schreef op 04 juli 2004 @ 20:56:
Waarom schrijf je nie een tutorial?

Als jij zoveel goeie ideeen heb wil ik de uitwerking ervan wel eens zien!

Yep, hier zat ik zeker aan te denken, maar ik zie graag eerst reacties zodat punten die ik over het hoofd heb gezien (of punten waar ik ook gewoon fout zit) aangepast/ toegevoegd kunnen worden

[PrisonerOfPain]

Ik ken (helaas) ook het verschijnsel maar ik erger me vooral aan dingen als

PHP:

$var = "12";
echo "$var";

- het niet gebruiken van super globals (waar ze wel van toepassing zij)
- de eindeloze lijst met sites die zich blootstellen aan SQL injections, include op iedere pagina iets als

PHP:

<?php
foreach ($_POST as $Value)
{
     $Value = $DB->Quote ($Value);
}
?>

en je hebt al een groot deel van de problemen op gelost...
- het gebruik van database specifieke functies (ja daar erger ik me aan ja!)
- dingen die eigenlijk in een array moeten (of gewoon overschreven kunnen worden) een naam geven als $<naam><cijfer>
- queries in een while loop die eigenlijk een join hadden moeten zijn
- het niet scheiden van verschillende lagen (PHPMyAdmin...)

maar dat zijn vooral details.. en ja OSCommerce slaat gewoon nergens op

[edit]
Over die tutorial, ik ben begonnen aan een tutorial op wikibooks omdat ik nogal eens merkte dat andere tutorials snel out of date raken; voel je vrij om er aan mee te werken

[ Voor 16% gewijzigd door PrisonerOfPain op 04-07-2004 21:02 ]

[Soultaker]

Wat ik zelf ook belangrijk vind is het scheiden van functionaliteit en elk afzonderlijk onderdeel onderbrengen in een aparte functie. Elke functie (of methode) moet een enkele welomschreven taak uitvoeren. Die kun je dan ook documenteren. In PHP is het bovendien erg handig om te omschrijven waar argumenten en return values aan moeten voldoen (wat voor typen zijn toegestaan?).

[AtleX]

@Soultaker: Daarom vindt ik het echt een nadeel dat PHP loose-typed is, het is in weinig situaties echt handig en voor de duidelijkheid en overzichtelijkheid zou beter zijn als je bij PHP gewoon variabelen moet declareren. (_{Ik kan niet op het tegenovergestelde van loose-typed komen, is dat strong-typed?}).

Aan de andere kant is PHP wel weer een ideale taal voor beginners, juist vanwege de dingen die hier allemaal beschreven worden. De PHP-interpreter slikt gewoon veel.

[PrisonerOfPain]

AtleX schreef op 04 juli 2004 @ 21:12:
Aan de andere kant is PHP wel weer een ideale taal voor beginners, juist vanwege de dingen die hier allemaal beschreven worden. De PHP-interpreter slikt gewoon veel.

Ik vind het zelf erg jammer dat PHP misbruikt word om in te leren programmeren (daar hadden we pascal toch voor?) want het is een geweldige taal maar hij (of zij) kan zo fout gebruikt worden, bloed zonde.

[Verwijderd]

AtleX schreef op 04 juli 2004 @ 21:12:
Aan de andere kant is PHP wel weer een ideale taal voor beginners, juist vanwege de dingen die hier allemaal beschreven worden. De PHP-interpreter slikt gewoon veel.

maar is het wel zo fijn dat PHP alles slikt, hierdoor kan een beginner zichzelf foute dingen aanleren omdat het toch wel werkt. als je standaard "1" gebruikt ipv 1 bij een optelling zal het zeker werken, maar op een moment dat je een andere taal gaat gebruiken (ik kan zosnel niet op goed voorbeeld komen) zal het niet werken of op de een of andere manier andere uitwerking hebben...

edit:

zie ook PrisonerOfPain zn reactie

[ Voor 24% gewijzigd door Verwijderd op 04-07-2004 21:18 ]

[Skaah]

Misschien is het interessant om een hoofdstuk over het belang van commentaar (staat er al een beetje) en aan programmeer stijl te wijden?

Denk aan indenting en dergelijk.

[PrisonerOfPain]

Verwijderd schreef op 04 juli 2004 @ 21:17:
hierdoor kan een beginner zichzelf foute dingen aanleren omdat het toch wel werkt.

Dat lijkt me nou juist niet de bedoeling

[AtleX]

@PrisonerOfPain en blaat-schaap:
Ik doe een MBO ICT-opleiding en we zijn begonnen met programmeren in Pascal (eitje ), alleen duurt het daarbij erg lang voor je eigenlijk resultaat hebt. Aangezien programmeren geen hoofddoel is voor een MBO opleiding en veel mensen er geen z*k aanvinden denk ik dat je meer mensen voor 'het vak' kan interesseren als je PHP gebruikt. Daarbij zie al heel snel resultaat, wat ervoor zorgt de leerlingen beter opletten.

* AtleX is misschien bevooroordeelt. Ik programmeer al wat langer dan 2 jaar, itt mijn klasgenoten.

[ Voor 8% gewijzigd door AtleX op 04-07-2004 21:23 ]

[Riball]

Wil je je zelf foute code aan leren moet je vooral een boek gaan halen...
ik had leuk een boek gehaald maar daar stond niks in over super globals...

vervolgens alles verkeerd aangeleerd... ken je weer overnieuw beginnen...

[PrisonerOfPain]

AtleX schreef op 04 juli 2004 @ 21:22:
@PrisonerOfPain en blaat-schaap:
Ik doe een MBO ICT-opleiding en we zijn begonnen met programmeren in Pascal (eitje ), alleen duurt het daarbij erg lang voor je eigenlijk resultaat hebt. Aangezien programmeren geen hoofddoel is voor een MBO opleiding en veel mensen er geen z*k aanvinden denk ik dat je meer mensen voor 'het vak' kan interesseren als je PHP gebruikt. Daarbij zie al heel snel resultaat, wat ervoor zorgt de leerlingen beter opletten.

Ja het nadeel is alleen dat je door dat snelle resultaat aan een project gaat beginnen zonder na te denken wat je uberhaupt wilt en tenslotte overnieuw moet beginnen omdat je `ontwerp` niet schaalbaar genoeg bleek te zijn...

Riball schreef op 04 juli 2004 @ 21:23:
Wil je je zelf foute code aan leren moet je vooral een boek gaan halen...
ik had leuk een boek gehaald maar daar stond niks in over super globals...

vervolgens alles verkeerd aangeleerd... ken je weer overnieuw beginnen...

Ik heb ook (ruimschootse) ervaring met dat soort boeken meestal komt dat omdat boeken erg snel verouderen.

@Skaah, als je tijd/zin hebt mag je van mij beginnen met schrijven hoor of desnoods een grovve opzet maken zodat iemand anders (ik waarschijnlijk..) het af maakt.

[ Voor 29% gewijzigd door PrisonerOfPain op 04-07-2004 21:29 ]

[AtleX]

PrisonerOfPain schreef op 04 juli 2004 @ 21:25:
[...]

Ja het nadeel is alleen dat je door dat snelle resultaat aan een project gaat beginnen zonder na te denken wat je uberhaupt wilt en tenslotte overnieuw moet beginnen omdat je `ontwerp` niet schaalbaar genoeg bleek te zijn...

Beginnende programmeurs maken ook niet meteen grote projecten, indien ze doorgroeien maken ze vanzelf nettere code. Als ik mijn bouwsels van 3 jaar geleden bekijk en mijn creaties van nu, dan denk ik dat ik toch heel ver vooruit ben gegaan.

[Verwijderd]

Soultaker schreef op 04 juli 2004 @ 21:05:
Wat ik zelf ook belangrijk vind is het scheiden van functionaliteit en elk afzonderlijk onderdeel onderbrengen in een aparte functie. Elke functie (of methode) moet een enkele welomschreven taak uitvoeren. Die kun je dan ook documenteren. In PHP is het bovendien erg handig om te omschrijven waar argumenten en return values aan moeten voldoen (wat voor typen zijn toegestaan?).

dat is inderdaad een erg goed punt (waar het bij mezelf nogal eens aan onbreekt). goed commentaar is ook een belangrijk iets. Vaak wordt het wel geprobeerd maar dan wordt zelfs een regel als "print $var1;" uitgelegd wat naar mijn mening misschien wat overdreven is.
Bij de typen... bedoel je daar integer/string/double etc of bijvoorbeeld userid,itemkey etc.. Als het de eerste is dan lijkt het mezelf niet echt heel handig omdat het niet direct iets toevoegd want als ik getusername($userid) zie staan weet ik al meteen dat een getal moet zijn en niet een string. Het probleem is namelijk dat het PHP zelf geen bal uitmaakt hoe je iets noemt. Als een client ergens 1 invult weet PHP dat het een integer is, maar van "hello world" weet ie ook dat het een string is.

[Skinkie]

ik denk dat echte goede C/C++/PHP code niet geschreven wordt tenzij je het juist NIET uitbreidbaar laat zijn. probleem is dat men tegenwoordig helemaal OO is geworden, inclusief moi. maar wat levert het op? maak je elke keer een nieuw raamwerk bij een nieuw project of her gebruik je de vorige tien sites?

universe code wordt altijd heel groot in code base, zie bijvoorbeeld pear, het voordeel is dat je het overal 'scriptend' aankunt roepen, maar dan ben je zeker niet aan het programmeren. zolang userinterface code nog voor 99% bestaat uit het controleren of de gebruiker wel het goede invuld ben je toch niet op de goede weg.

daarom denk ik dat men eens moet kijken naar code generatie tools, die code netjes uitspuigd en waar het niet nodig om daarna nog even te gaan 'hacken'.

just my two cents

[PrisonerOfPain]

AtleX schreef op 04 juli 2004 @ 21:28:
Beginnende programmeurs maken ook niet meteen grote projecten, indien ze doorgroeien maken ze vanzelf nettere code.

Dan hebben ze toch niets gehad aan hun opleiding omdat ze het alsnog zelf hebben moeten leren overigends ben je dan al te laat...

*we raken trouwens offtopic..

Skinkie schreef op 04 juli 2004 @ 21:30:
ik denk dat echte goede C/C++/PHP code niet geschreven wordt tenzij je het juist NIET uitbreidbaar laat zijn. probleem is dat men tegenwoordig helemaal OO is geworden, inclusief moi. maar wat levert het op? maak je elke keer een nieuw raamwerk bij een nieuw project of her gebruik je de vorige tien sites?

Ik heb al een hoop sites gebouwd met dezelfde database class, zoiets is gewoon erg universeel dus waarom zou je het 10 keer opnieuw doen? Zonde van m'n tijd als je het mij vraagt..

universe code wordt altijd heel groot in code base, zie bijvoorbeeld pear, het voordeel is dat je het overal 'scriptend' aankunt roepen, maar dan ben je zeker niet aan het programmeren. zolang userinterface code nog voor 99% bestaat uit het controleren of de gebruiker wel het goede invuld ben je toch niet op de goede weg.

Ja daar noem je ook een project, PEAR :wall: sorry hoor maar als een database class > 3000 regels nodig heeft per database ben je erg vreemd bezig, de meeste standaard PHP scripts halen met moeite zoveel regels.

[ Voor 61% gewijzigd door PrisonerOfPain op 04-07-2004 21:35 ]

[Riball]

PrisonerOfPain schreef op 04 juli 2004 @ Over die tutorial, ik ben begonnen aan een tutorial op wikibooks omdat ik nogal eens merkte dat andere tutorials snel out of date raken; voel je vrij om er aan mee te werken

Ik heb altijd wat te zeiken op sites daar nie van... en die tutorial ziet er best goed uit... alleen vind ik die elle-lange-pagina wat kloterig... tzou handig zijn als je het opdeeld... en natuurlijk mischien volgende en vorige etc...

enne kleurcodes mis ik nog...

[ Voor 3% gewijzigd door Riball op 04-07-2004 21:33 ]

[PrisonerOfPain]

Riball schreef op 04 juli 2004 @ 21:33:
Ik heb altijd wat te zeiken op sites daar nie van... en die tutorial ziet er best goed uit... alleen vind ik die elle-lange-pagina wat kloterig... tzou handig zijn als je het opdeeld... en natuurlijk mischien volgende en vorige etc...

Ik ga je echt niet tegen houden om het aan te passen hoor als het nou niet bevalt, wat let je?

[Skinkie]

PrisonerOfPain schreef op 04 juli 2004 @ 21:31:
Ja daar noem je ook een project, PEAR :wall: sorry hoor maar als een database class > 3000 regels nodig heeft per database ben je erg vreemd bezig, de meeste standaard PHP scripts halen met moeite zoveel regels.

Je vergeet een detail, die lui maken een abstractie laag per database, een abstractie laag ja, zodat de database universeel kan worden aangesproken. Inclusief errors (en dat zijn er nog al een hoop).

Ik kan nog wel een paar voorbeelden geven van projecten met een naar mijn mening iets te grote codebase.

Btw. Kan jou simpele universele code door iedereen worden gebruikt of heeft een een PoP-handleiding + limitaties

[Riball]

PrisonerOfPain schreef op 04 juli 2004 @ 21:36:
[...]

Ik ga je echt niet tegen houden om het aan te passen hoor als het nou niet bevalt, wat let je?

en hoe doek da? (ben goed in zeiken maar zeg nie dat ik het zelf beter kan hoor)

En nu we het toch over het uitbreiden van code hebben... ik zie iedere keer wel een voorbeeld, niet dat die verkeerd zijn, maar die voorbeelden worden niet uitgebreid... je krijg plof een voorbeeld voor je kiezen waar alles meteen in staat.... en bij een volgend ding/onderwerp krijg je meteen een nieuw voorbeeld...

[PrisonerOfPain]

Skinkie schreef op 04 juli 2004 @ 21:39:
Je vergeet een detail, die lui maken een abstractie laag per database, een abstractie laag ja, zodat de database universeel kan worden aangesproken. Inclusief errors (en dat zijn er nog al een hoop).

Voorbeeldje: de Prepare() of Excecute() functies hebben een interpreter gekregen om te kijken of er een "*" "?" en nog wat tekens in de query te vissen en te vervangen met de juiste waardes, iets wat sprintf() al jaren aan een stuk doet maar dan met een andere syntax...

Ik kan nog wel een paar voorbeelden geven van projecten met een naar mijn mening iets te grote codebase.

Btw. Kan jou simpele universele code door iedereen worden gebruikt of heeft een een PoP-handleiding + limitaties

Het werkt volgens het zelfde idee als de PEAR::DB class maar je kan er wat minder mee, genoeg voor de meeste projecten. Er is ook niet echt een manual nodig per class bevat 'ie een functie of 5 a 6..

@Riball, het "edit" knopje boven aan de pagina

[ Voor 5% gewijzigd door PrisonerOfPain op 04-07-2004 21:45 ]

[Verwijderd]

Riball schreef op 04 juli 2004 @ 21:41:
[...]


en hoe doek da? (ben goed in zeiken maar zeg nie dat ik het zelf beter kan hoor)

En nu we het toch over het uitbreiden van code hebben... ik zie iedere keer wel een voorbeeld, niet dat die verkeerd zijn, maar die voorbeelden worden niet uitgebreid... je krijg plof een voorbeeld voor je kiezen waar alles meteen in staat.... en bij een volgend ding/onderwerp krijg je meteen een nieuw voorbeeld...

graag bietje ontopic houden, maar we kunnen denk ik wel vast stellen dat voor een beetje grote projecten een framework/codebase toch wel makkelijk is zodat alles bietje bij de hand is. Misschien zou het een goed idee zijn om verschillende frameworks te hebben afhankelijk voor size van project...

@Skinkie
Ik denk dat je altijd probleem houdt van limitaties want op de een of andere manier vergeet je altijd iets bij het uitdenken van een module (dat heb ik in ieder geval )

[ Voor 11% gewijzigd door Verwijderd op 04-07-2004 21:47 ]

[crisp]

Zelf heb ik dit lijstje gemaakt met punten waar code aan moet voldoen

Dan heb ik nog wel een aanvulling
Iets waar veel aan voorbij wordt gegaan, en ook nooit vermeld staat in PHP tutorials e.d. is het belang van nette HTML, dat is per slot van rekening hetgeen dat de client ontvangt, en het zou niet moeten uitmaken of de client een browser x of y gebruikt. Serverside programmeurs zijn in mijn beleving slechte HTML-ers. Zelfs bij grote spelers in de markt, waar je zou verwachten dat de frontend code door gespecialiseerde mensen wordt gemaakt is het resultaat vaak bedroevend en nog vaker IE-only.
Mijn advies aan beginnende PHP-ers is vaak: leer eerst fatsoenlijk HTML-en en clientside scripten (je moet ook niet alles met PHP willen oplossen).

PrisonerOfPain schreef op 04 juli 2004 @ 21:00:
[...]
[edit]
Over die tutorial, ik ben begonnen aan een tutorial op wikibooks omdat ik nogal eens merkte dat andere tutorials snel out of date raken; voel je vrij om er aan mee te werken

Leuk stukje, maar wat ik voornamelijk mis is een uitleg over het gebruik van single-quotes en double-quotes. Ik zie menig PHP-er altijd en overal double-quotes gebruiken terwijl dat in 99% van de gevallen niet nodig is.

[Verwijderd]

crisp schreef op 04 juli 2004 @ 21:51:
Iets waar veel aan voorbij wordt gegaan, en ook nooit vermeld staat in PHP tutorials e.d. is het belang van nette HTML, dat is per slot van rekening hetgeen dat de client ontvangt, en het zou niet moeten uitmaken of de client een browser x of y gebruikt. Serverside programmeurs zijn in mijn beleving slechte HTML-ers. Zelfs bij grote spelers in de markt, waar je zou verwachten dat de frontend code door gespecialiseerde mensen wordt gemaakt is het resultaat vaak bedroevend en nog vaker IE-only.
Mijn advies aan beginnende PHP-ers is vaak: leer eerst fatsoenlijk HTML-en en clientside scripten (je moet ook niet alles met PHP willen oplossen).

zou het niet beter zijn om deze taken gescheiden te houden, dus een specialist op het gebied van HTML daarvoor laten zorgen, want HTML hangt altijd erg nauw samen met het design (het photoshop bestandje moet namelijk goed omgezet worden). Zelf zit ik niet echt te wachten op het moeten maken van templates, maar dit komt misschien ook omdat ik een collega heb die de templates voor me fixt. HTML zou ik toch echt als een taak appart beschouwen dat vooral bij grote projecten uitbesteed kan worden.

[PrisonerOfPain]

crisp schreef op 04 juli 2004 @ 21:51:
Dan heb ik nog wel een aanvulling
Iets waar veel aan voorbij wordt gegaan, en ook nooit vermeld staat in PHP tutorials e.d. is het belang van nette HTML, dat is per slot van rekening hetgeen dat de client ontvangt, en het zou niet moeten uitmaken of de client een browser x of y gebruikt.

Ik ben het met je eens dat men net moet leren HTML-en, maar dat heeft eigenlijk helemaal niets met PHP temaken en hoort daarom ook niet in zo'n tutorial thuis, daar heb je HTML tutorials voor.

Serverside programmeurs zijn in mijn beleving slechte HTML-ers.
Zelfs bij grote spelers in de markt, waar je zou verwachten dat de frontend code door gespecialiseerde mensen wordt gemaakt is het resultaat vaak bedroevend en nog vaker IE-only.

Ik heb sowieso het idee dat HTML een ondergeschoven kindje is wat betreft 'kunde' er zijn volgens mij relatie weinig mensen die echt erg nette HTML produceren.

(je moet ook niet alles met PHP willen oplossen).

Maar het kan soms erg verrassende resultaten leveren (PHP + OpenGL is blijkbaar ook gewoon mogenlijk )

Leuk stukje, maar wat ik voornamelijk mis is een uitleg over het gebruik van single-quotes en double-quotes.

Bedankt, ik zal binnenkort eens kijken of ik er iets over kan schrijven

[crisp]

Verwijderd schreef op 04 juli 2004 @ 21:57:
[...]

zou het niet beter zijn om deze taken gescheiden te houden, dus een specialist op het gebied van HTML daarvoor laten zorgen, want HTML hangt altijd erg nauw samen met het design (het photoshop bestandje moet namelijk goed omgezet worden). Zelf zit ik niet echt te wachten op het moeten maken van templates, maar dit komt misschien ook omdat ik een collega heb die de templates voor me fixt. HTML zou ik toch echt als een taak appart beschouwen dat vooral bij grote projecten uitbesteed kan worden.

Ik zie PHP zelf eigenlijk nog steeds als een bloated template-engine, en zo wordt het ook nog vaak genoeg gebruikt. Als PHP-er ben je dus een groot deel van de tijd gewoon HTML aan het schrijven, en zeker als beginnende amateur moet je het gewoon allebei kunnen.
Ik zeg niet dat een PHP-tutorial meteen een HTML-tutorial moet bevatten, maar het belang van nette HTML moet wel prominent genoemd worden imho. Ook bij debuggen is het van groot belang dat je je HTML code moet kunnen interpreteren - veel fouten vinden hun oorsprong in brakke HTML.

[Skinkie]

sql -> php -> xml -> xhtml klaar

[crisp]

Skinkie schreef op 04 juli 2004 @ 22:14:
sql -> php -> xml -> xhtml klaar

waarom xml als tussenstap? functioneel voegt het weinig toe (zoals gezegd: PHP is een prima template engine van zichzelf) en xhtml is ook al een vorm van xml.

[Skinkie]

crisp schreef op 04 juli 2004 @ 22:17:
waarom xml als tussenstap? functioneel voegt het weinig toe (zoals gezegd: PHP is een prima template engine van zichzelf) en xhtml is ook al een vorm van xml.

omdat ik vind dat PHP niet zo'n super template engine is en met de XML stap kun je ook leuk cachen

[Verwijderd]

HTML is zeker niet te vergeten maar toch valt het me op dat het vaak al fout gaat voordat men bij het HTMLen uitkomt. En naar mijn mening is het nog steeds zo dat het "HTML probleem" goed op te lossen is door - misschien achteraf - eens op je gemakje gaat bedenken hoe je het wilt gaan doen in HTML.

(je moet ook niet alles met PHP willen oplossen).

Maar als je spannende dingen in javascript ga doen en iemand heeft javascript uitstaan (zelfs dat kan) werkt het geheel niet meer. Ik ben zelf niet zo'n ster in javascript of andere clientside talen, maar ik probeer het toch zoveel mogelijk te vermijden zodat de sites nog minder client afhankelijk zijn.

[Verwijderd]

Verwijderd schreef op 04 juli 2004 @ 22:34:
HTML is zeker niet te vergeten maar toch valt het me op dat het vaak al fout gaat voordat men bij het HTMLen uitkomt. En naar mijn mening is het nog steeds zo dat het "HTML probleem" goed op te lossen is door - misschien achteraf - eens op je gemakje gaat bedenken hoe je het wilt gaan doen in HTML.


[...]


Maar als je spannende dingen in javascript ga doen en iemand heeft javascript uitstaan (zelfs dat kan) werkt het geheel niet meer. Ik ben zelf niet zo'n ster in javascript of andere clientside talen, maar ik probeer het toch zoveel mogelijk te vermijden zodat de sites nog minder client afhankelijk zijn.

JavaScript mag mijns inziens alleen gebruikt worden voor extra handigheidjes op een bepaalde site. De site moet zonder JavaScript ook perfect te gebruiken zijn.

[crisp]

Verwijderd schreef op 04 juli 2004 @ 23:17:
[...]

JavaScript mag mijns inziens alleen gebruikt worden voor extra handigheidjes op een bepaalde site. De site moet zonder JavaScript ook perfect te gebruiken zijn.

Voor een site ja, maar is ook wel afhankelijk van je doelgroep (de frontpage van Tweakers is zonder JS ook niet te bekijken). Voor een web-applicatie is het een ander verhaal.

[stekkel]

Okey, ik heb even naar dat wiki php cursus gekeken en ik denk dat het in de basis goed is en dat iedere beginnende php programmeur die cursus maar eens moet lezen.

Ik heb even de vrijheid genomen om het switch statement en de for lus wat verder te documenteren en ik heb wat oneigenlijk gebruik van double quotes verwijderd en vervangen door single quotes of niks. (loze "" sequences).

Wat ik verder mis het gebruik van variabele initialisatie vs het gebruik van isset(). Dit is voor mij vaak ergenis nummer een. Iedere php programmeur zou error reporting op E_ALL moeten hebben staan en error reporting to screen zodat je gelijk gewaarschuwd wordt indien variabelen niet geinitialiseerd zijn. Wanneer ik code van andere "php programmeurs" onder ogen krijg en mijn scherm staat vol met warnings dan denk ik gelijk "daar heb je weer zo'n prutser".

Maar goed, ik ben niet zo heel handig met die wiki dus wanneer iemand een hoofdstukje kan toevoegen over variabele initialisatie en het belang er van (netter, snellere detectie van fouten en snellere code) dan heb ik straks een tuturial waar ik andere naar kan verwijzen als ik het idee heb dat ze niks van php begrijpen.

[pietje63]

Waar ik me vaak aan erger is het verkeerd gebruiken van " ' en ` veel beginners lijken het verschil niet te kennen.

Over netjes programmeren. Het is heel verschillend waarvoor ik programmeer. Als ik een scriptje bouw voor iets dat ik tijdelijk nodig heb en waarvan ik weet dat ik er later niets meer mee doe is het recht toe recht aan.

Verder bouw ik meestal vrij modulair op, met includes voor stukjes code. Ik type in ieder geval genoeg commentaar. Ik heb de laatste tijd geen scripts meer geschreven die ik voor iedereen beschikbaar heb gesteld maar wel samen met andere mensen aan een site gewerkt en dan merk je toch wel dat het fijn is als mensen "goed" programmeren.

* pietje63 haat het als je gevraagd wordt om een script af te maken omdat iemand het niet helemaal afkrijgt/niet meer snapt en je hebt dan "slechte" code

[ludo]

Het probleem is ook dat een heel groot deel van de PHP tutorials gericht op beginners van een dermate laag niveau is dat een beginner veel basiseigenschappen voor het schrijven van fatsoenlijke code niet eens mee krijgt.

Er zijn honderden sites met php tutorials te vinden en dit helpt ook mee aan het succes van php. Dit is heel mooi, zeker voor beginners. Maar iedereen die een beetje php kan lijkt een tutorial te moeten schrijven, vol met slechte code...

[Mac_Cain13]

pietje63 schreef op 05 juli 2004 @ 12:51:
Waar ik me vaak aan erger is het verkeerd gebruiken van " ' en ` veel beginners lijken het verschil niet te kennen.
[...]

Nu ik dit zo lees realiseer ik me dat ik eigenlijk ook niet precies weet wanneer ik ' en wanneer ik " moet gebruiken in mijn PHP scripts. De ` is wel duidelijk die is exact gelijk aan de shell_exec() functie.

Op php.net staat wel dat bij echo "$foo" de inhoud van $foo wordt afgedrukt en dat echo '$foo' er letterlijk $foo word weergegeven. Is dit het enige verschil? Of zijn er meer dingen waar ik op moet letten? En welke zou ik standaard moeten gebruiken?

Ik heb al even op internet gezocht, maar kon geen duidelijke 'regels' vinden wanneer je welke moet gebruiken. Mss is er iemand die dit mij even kort zou willen uitleggen of die een linkje naar een artikeltje hierover heeft. Dan is mijn PHP code weer iets minder brak

[AtleX]

Als je enkele quotes gebruikt hoeft PHP de string niet te parsen op zoek naar variabelelen. Theoretisch is het dus sneller. Ook ziet het er wat netter uit en is een variabele beter te onderscheiden van de omliggende tekst.

[Gomez12]

Alhoewel er veel vreselijk geprogrammeerd word in PHP denk ik toch dat het beeld wel enigszins aangetast wordt door het soort sites/vragen etc waar je iets vandaan. Bijvoorbeeld hier op got heb ik nog nooit een stukje php gepost wat ik direct uit een bestand bij mezelf haalde, alles is herschreven naar GOT. Want het is absoluut niet boeiend voor jullie als ik 1500 regels neerplemp en dan zeg in regel 1361 t/m 1370 zit een fout waar ik niet uitkom.

Daardoor lijkt het soms wel alsof niemand ergens rekening meehoud, maar als ik in de vorige 1300 regels al sql-check etc heb gedaan. Dan hoef ik dat niet te posten op GOT omdat dat gewoon goed gaat, wat weer overkomt alsof ik geen sql-checks etc doe.

De php-code op GOT is over het algemeen bagger, maar dat komt (denk ik) bij de meeste personen meer omdat ze er gewoon vanuit gaan dat iemand dat niet gaat zitten copy-pasten.

Ik check op GOT nooit of mijn php-code syntax correct is als ik een antwoord geef. Ik ga er toch niet vanuit dat iemand het zo rechtstreeks gaat gebruiken. Ik ga ervanuit dat iemand dan gewoon door gaat zoeken.

En op sites als phpfreakz.nl etc daar heb ik toch al niet zo'n hoge pet van op.

En het is gewoon een feit dat php heel snel heel radikaal veranderd in sommige dingen, waardoor heel veel mensen ook oude tutorials zitten te lezen.

[PrisonerOfPain]

Mac_Cain13 schreef op 05 juli 2004 @ 13:28:
[...]
Nu ik dit zo lees realiseer ik me dat ik eigenlijk ook niet precies weet wanneer ik ' en wanneer ik " moet gebruiken in mijn PHP scripts. De ` is wel duidelijk die is exact gelijk aan de shell_exec() functie.

Op php.net staat wel dat bij echo "$foo" de inhoud van $foo wordt afgedrukt en dat echo '$foo' er letterlijk $foo word weergegeven. Is dit het enige verschil? Of zijn er meer dingen waar ik op moet letten? En welke zou ik standaard moeten gebruiken?

Bij ' worden (bijna) alle waarde's letterlijk genomen (behalve ' en \ geloof ik, die moet je escapen) je kan dus niet zetten '\n' om een newline af te drukken, bij " heb je een hoop meer mogenlijkheden, er zijn meer tekens om te escapen, je kan er variablen in zetten maar het is ook iets trager als '..

Alhoewel er veel vreselijk geprogrammeerd word in PHP denk ik toch dat het beeld wel enigszins aangetast wordt door het soort sites/vragen etc waar je iets vandaan.

Ik wil niet stom over komen ofzo, maar ik zie ook op deze site een hoop misbruik van PHP plaatsvinde.

Bijvoorbeeld hier op got heb ik nog nooit een stukje php gepost wat ik direct uit een bestand bij mezelf haalde, alles is herschreven naar GOT. Want het is absoluut niet boeiend voor jullie als ik 1500 regels neerplemp en dan zeg in regel 1361 t/m 1370 zit een fout waar ik niet uitkom.

Dat komt door het regelement, maar er zijn zat sites waar dat wel gebeurt. Op een dergelijke manier leer je het natuurlijk nooit..

Daardoor lijkt het soms wel alsof niemand ergens rekening meehoud, maar als ik in de vorige 1300 regels al sql-check etc heb gedaan. Dan hoef ik dat niet te posten op GOT omdat dat gewoon goed gaat, wat weer overkomt alsof ik geen sql-checks etc doe.

Als je iets boven je code zet als

PHP:

//valideer data

Denk ik niet dat veel mensen hier over zullen vallen.

De php-code op GOT is over het algemeen bagger, maar dat komt (denk ik) bij de meeste personen meer omdat ze er gewoon vanuit gaan dat iemand dat niet gaat zitten copy-pasten.

Niet alleen op GoT maar op bijna alle fora die PHP behandelen gebeurt zoiets, ik heb mezelf ook voorgenomen gewoon niets te posten in zo'n topic en het eventueel te melden.

Ik check op GOT nooit of mijn php-code syntax correct is als ik een antwoord geef. Ik ga er toch niet vanuit dat iemand het zo rechtstreeks gaat gebruiken. Ik ga ervanuit dat iemand dan gewoon door gaat zoeken.

Uhm? als je dat niet controleerd gaat men daar toch over door (logisch..) verder is dit een knowlege base, dus de kans dat iemand jou stukje code gebruikt is er weldegelijk..

[ Voor 54% gewijzigd door PrisonerOfPain op 05-07-2004 13:55 ]

[RwD]

crisp schreef op 04 juli 2004 @ 21:51:
...

Leuk stukje, maar wat ik voornamelijk mis is een uitleg over het gebruik van single-quotes en double-quotes. Ik zie menig PHP-er altijd en overal double-quotes gebruiken terwijl dat in 99% van de gevallen niet nodig is.

Niet nodig en langzamer...

Ikzelf vindt het eigenlijk voornamelijk belangrijk dat je consequent bent in je stijl, zowel in code als in de lay-out van je code, en je commentaar.
Daarvoor is zo'n algemene code standaard, maar die vindt ikzelf minder overzichtelijk en gebruik daarom een eigen. (Deze wordt waar ik werk ook gehanteerd.) Eenzelfde uitziende code en naamgeving-conventie van je functies en variabelen maakt enorm veel uit in de onderhoudbaarheid en zelfs de herbuikbaarheid.

Ik gebruik zelf objecten en functies door elkaar. Maar functies natuurlijk alleen als het iets is dat gewoon (input -> output; geen gegevens onthouden) is (ajbwib)

Maar goed. Mensen leren dit vanzelf, als je je ergerd aan het niveau van je collega's dan praat met je baas en zorg dat je ze hier in mag helpen...

[pjonk]

Zelf ben ik ook met een andere taal dan PHP begonnen en dan begrijp je wel dat als je alleen inhoud van variabelen wilt outputten je geen quotes gebruikt. Het enkele en dubbele quotes verhaal is natuurlijk wel PHP specifiek, maar toch wel basiskennis van de taal.

Wat mij opvalt is dat veel PHP programmeurs zeer beperkt aan validatie doen waardoor eerder genoemde SQL injection problemen kunnen voorkomen en de foutmeldingen over je scherm rollen indien je handmatig een GET variabele in de URL manipuleert.

Voorbeeld:
Er wordt een ID variabele meegegeven in de URL die vervolgens in de query gebruikt wordt.

Voordat ik de variabele in een query gebruik doe ik, om te forceren dat de variabele altijd numeriek is:

PHP:

$_GET['id'] = intval($_GET['id']);

Soms is het onwetenheid, maar vaak ook een luiheid van programmeurs die het teveel werk vinden om alle client input te valideren.
Bovengenoemd probleem geldt natuurlijk niet alleen voor PHP, maar voor alle webapplicaties.

[djluc]

echo "$foo"

Is IMO not-done. Wat is het nut van die quotes?

Het probleem is ook dat een heel groot deel van de PHP tutorials gericht op beginners van een dermate laag niveau is dat een beginner veel basiseigenschappen voor het schrijven van fatsoenlijke code niet eens mee krijgt.

Geheel mee eens. Je kunt nog geen fatsoenlijke code/opzet maken voor een script als je alleen maar weet hoe je met gegevens om moet gaan en hoe bepaalde functies werken. Je moet ook leren omgaan met het opzetten van een script.

[PrisonerOfPain]

djluc schreef op 05 juli 2004 @ 13:53:
Is IMO not-done. Wat is het nut van die quotes?

Geen idee, maar ik vind het echt enorm ranzig overbodig en een teken van onkunde

[Mac_Cain13]

djluc schreef op 05 juli 2004 @ 13:53:
[...]
Is IMO not-done. Wat is het nut van die quotes?
[...]

Dat is er niet en het is idd ranzig. Het was ook alleen om aan te tonen wat het verschil is tussen ' en ". Het is me iig nu duidelijk dat ik eigenlijk ' zou moeten gebruiken tenzij ik \n oid wil gebruiken. Tnx!

[AtleX]

Na de discussie over single- of double-quotes wil over naar het volgende onderwerp: Commentaar.

Daar kunnen mensen mee prutsen, of ze gebruiken het helemaal niet. Of ze becommentariseren elke regel die ze typen.

Ik zet boven elke gebruikers-gedefinieerde functie een kort stukje dat beschrijft wat de functie doet, welke paramaters er verwacht worden en wat de return-values zijn. Bij rare/afwijkende/ingewikkelde dingen zet ik daar ook weer een regeltje commentaar bij.

Het belang van goed commentaar is imho erg groot. Je moet over 3 maanden ook nog weten waarom je iets zo hebt gedaan. Ik heb weleens met iemand samengewerkt die 3 dingen verkeerd deed:
1) Geen commentaar
2) Copy-pasten van code. In 1 bestand 3 keer dezelde code tegenkomen is lastig debuggen
3) Niet inspringen

[Verwijderd]

AtleX schreef op 05 juli 2004 @ 13:48:
Als je enkele quotes gebruikt hoeft PHP de string niet te parsen op zoek naar variabelelen. Theoretisch is het dus sneller. Ook ziet het er wat netter uit en is een variabele beter te onderscheiden van de omliggende tekst.

RwD schreef op 05 juli 2004 @ 13:50:
[Crisp over single en double quotes]
Niet nodig en langzamer...

...knip...

Dit is echt zo niet waar. Of je nou single of double quotes gebruikt maar geen
ene hol uit qua tijdwinst. De tokenizer moet in beide gevallen gewoon netjes blijven
zoeken tot er een sluit quote (single of double) gevonden is. Die twee extra cases
doen het hem niet...
Uit de benchmark blijkt ook dat er geen verschil is tussen de twee varianten.

http://www.nextavenue.com/double.php
http://www.nextavenue.com/single.php

PHP:

$mtime = microtime(); 
$mtime = explode(" ",$mtime); 
$mtime = $mtime[1] + $mtime[0]; 
$starttime = $mtime; 

$t = 0;
for ($i = 0; $i < 10000; $i++) {
  for ($j = 0; $j < 250; $j++) {
    $a = 'blaat dit is een lange stringa';
    $b = 'blaat dit is een lange string.';
    if ($a == $b) {
      $t++;
    }
  }
}

$mtime = microtime(); 
$mtime = explode(" ",$mtime); 
$mtime = $mtime[1] + $mtime[0]; 
$endtime = $mtime; 
$total = $endtime - $starttime; 
echo $total;

[MisterData]

String array indices gebruiken zonder kwootjes is ook heel erg:

PHP:

<?php
$array = array();
$array[mijnarraykey] = "iets";
?>

enzo....

[Erkens]

MisterData schreef op 05 juli 2004 @ 15:32:
String array indices gebruiken zonder kwootjes is ook heel erg:

PHP:

<?php
$array = array();
$array[mijnarraykey] = "iets";
?>

enzo....

dat geeft bij mij altijd heel mooi een E_NOTICE

---

zelf gebruik ik eigenlijk altijd single quotes, ook als ik newlines moet hebben doe ik altijd single quotes:

PHP:

define('CR',chr(10));  // ja ik weet het, dat is linefeed,
                       // alleen carrige return vind ik duidelijker :P

..

echo "blaat", CR;

[Apache]

Ik ben het er mee eens, al lang trouwens.
De slechte reputatie van PHP als traag e.d. komt volgens mij ook vaak door slechte code die er rondzwerft op het internet.

Ook van PEAR word ik niet zo heel erg blij, maar das vnl omdat ik al wat langer met PHP 5 werk.

Ook wat crisp zegt, goede html erg belangrijk, natuurlijk gescheiden van de business logic, de xml tussenstap heeft voordelen, zoals al genoemd caching, maar in combinatie met XSL ook nog een mooie skinning engine.

Veiligheid is ook nog absoluut een punt, er zijn hopen sites waar je dmv een GET variable aan te passen andere, soms niet voor je ogen bedoelde informatie kan krijgen, ik schreef me ooit in op een php site, ik kreeg een tekstje in de zin van: "Welkom $gebruikersnaam, je passwoord is $passwoord."
Nu was dit in een popup en kreeg je niet meteen de URL hiervan te zien, maar ff view page info in mozilla, url kopieren, in gewone browser: welkom.php?user=$mijnuid

Nummertje veranderen en je kon andere gasten hun username & passwoord zien (erg moeilijk om dan met die account in te loggen ).

Een ander voorbeeld was SQL injection bij een van de grootste ISP's van België die een lanparty organiseerden, ingeschreven personen konden inloggen en hun gegevens wijzigen. Geen addslashes, dus als username (die je uit een lijst kon c/p'n) met een single quote, punt-komma en twee streepjes (commentaar in sql) (';--) en je kwam op die persoon z'n account

Zelf heb ik mijn grootste frustraties opgelost met wat collega studenten door een eigen framework op te bouwen, zoals pear hoeft het ook slechts op één plaats op de server te staan zodat een geupdate versie ook meteen alle bugs fixed in alle apps die ermee geschreven zijn.

_{Warning volgende code fragmenten bevatten aardige java ripoff}

PHP:

<?php
include('../zen-ng/zen.php');
zen::import('/core/http/request.class.php');
zen::import('/core/ui/listview.class.php');
zen::import('/core/tpl/tpl.class.php');
zen::import('/core/error/fileLogger.class.php');
zen::import('/core/error/mailNotification.class.php');
zen::import('/core/error/socketNotification.class.php');
?>

Die error handling classen zijn eigenlijk ontstaat vanuit het feit dat ik errors netjes wilde weergeven, maar het is meteen ook wat uitgebreid geworden met zogenaamde "debugdrivers" waarmee we meteen als developer verwittigd kunnen worden bij een error, een vriend heeft PET ontwikkeld waarmee je à la msn errors krijgt. [screenshot] [screenshot]

PHP:

<?php
/* 
de eerste parameter is null, maar kan een array bevatten met files 
waarvan hij de source niet mag tonen (kan ook volledig uitgezet worden)
zie eerste screenshot
2de parameter bevat de directory waar de error template zich bevind
die kan in de lokale applicatie overriden worden met een eigen template per app
en de 3de is de error reporting level 
*/
new ErrorHandler(null, zen::path().zen::tplPath, E_ALL); // template based

/* hier word er notification gestuurd naar een socket, kan ook een file, 
sqllite db, e-mail zijn, en zodra er jabber classes zijn ook een jabber versie
erg handig als je met 4 developers aan een project werkt met een stuk of 20 testusers, 
moeten ze niet meer manueel in een mailtje zeggen van woops er ging wat fout, weet niet weer, 
weet niet wat maar je hebt meteen alle uitgebreide informatie die je maar wil
*/
ErrorHandler::registerNotificationDriver(new errSocketNotification('10.0.0.2', 666));

/* dankzij php5 kunnen we hier ook een erg uitgebreide interface voor maken 
en typehinting gebruiken als parameter voor de registerNotificationDriver functie */

interface errorNotificationDriver {
    
    public function raiseError($errno, $errstr, $errfile, $errline, $vars);
    
}

    /**
    * @return void
    * @param errorNotificationDriver $end
    * @desc registers a notification driver that will be excecuted when an error occurs
    */
    static public function registerNotificationDriver(errorNotificationDriver $end){
    
        ErrorHandler::$notificationList[] = $end;
    
    }
?>

Wat ook meteen het punt van documentatie duidelijk maakt, er zijn standaard pakketten als phpDoc en javaDoc achtige toestanden die hieruit prachtige html bestanden kunnen genereren, de Zend development enviroment gebruikt ze dan ook nog eens bij de auto completion zodat je niet manueel naar de docs moet gaan kijken.

Voor de security is er de dbl die alles afhandelt dmv arrays en daar zelf de escape functie over haalt, t'is in de stijl van de key is veld dat geupdate moet worden en de value eraan is de nieuwe waarde.

En voor de GET/POST vars is er de request classe ism de Type classe, je krijgt bijvoorbeeld een warning wanneer je een $_GET['onbestaandeGetVar'] doet, een simpele wrapper functie lost dat op en daar kan je dan meteen typing doen desgewenst.

PHP:

<?php
    /**
    * @return mixed
    * @param mixed $index
    * @param integer $type
    * @desc returns a get variable but with isset and optional type checking
    */
    public static function get($index, $type = null){

        if (isset($_GET[$index])){
        
            if (is_null($type)){
            
                return $_GET[$index];
            
            } else {
                
                return Type::setType($_GET[$index], $type);
                
            }
        
        } else {
            
            return false;
            
        }
    
    }
?>

PHP:

<?php
$id = Request::get('id', Type::INTEGER);
?>

Ook de herbruikbaarheid van templates voor userinterfaces vond ik beter kunnen, hoe vaak zit je niet opnieuw een tabel volledig uit te typen.

Nu laat de template engine dit toe door een dir met standaard templates te hebben zoals een listview achtig iets, natuurlijk heeft de klasse die dit produceerd dan wel een instantie nodig van de Template engine, daarom moet die dus eerst aangemaakt worden en geregistreerd bij de Framework classe:

PHP:

<?php

zen::register(new Template('bleh.tpl'));

// in de Listview class:
$tpl = zen::getInstanceOf('Template');

// properties instellen van de listview:
// data kan ook rechtstreeks uit de Database layer komen
$lvwParams['data'] = array(array('bleh', 'blah', 'blehz0r'), 
array('blahz0r', 'bloeh', 'bloehz0r'), 
array('','blieh',null), 
array(null, null, 'bleh'));
$lvwParams['headers'] = array('naam', 'voornaam', 'bleh');
$lvwParams['highlight'] = 'naam';
$lvwParams['selectname'] = 'id';
$lvwParams['listmode'] = Listview::LVW_SELECT;

new listview($lvwParams);
?>

Wat er dan uiteindelijk zo komt uit te zien:


Nogmaals geef ik Crisp nog eens gelijk en vindt ik dat niet alles serverside moet, zo heb ik bij m'n isp slechts statische ruimte ter beschikking wat me dwong creatief te zijn, uiteindelijk zijn er wel server side scripts die lokaal draaien en thumbnails maken pagina's genereren en die via ftp doorstuurt naar m'n static webspace, maar daar heb ik dan zoveel mogelijk met JavaScript gewerkt om een dynamisch feel te geven, en uiteindelijk ziet het er nu allemaal vlotter uit omdat er geen postbacks zijn, slideshow kan zonder page reloads of andere truukjes. [vb] (slideshow wanneer je op een thumb klikt)

Nu vrees ik dat deze post veels te lang geworden is (t'regent buiten ), maar ik hoop vooral dat mensen hier wat originele ideeën uit kunnen putten en php misschien een beetje positiever bekijken, natuurlijk zijn dingen als dit ook vrij persoonlijk (coding/documenting style) maar dat heeft niet meteen iets te maken met security gaten die ontstaan in je web app.

Ik hoop dat met de komst van PHP 5 er een kwaliteitsverbetering komt in de source base die openlijk beschikbaar is. Een standaard reporting level van E_ALL of beter nog E_STRICT ( ) zou al een hoop schelen bij beginners
Niet te vergeten dat ook E_ALL code langer zal blijven draaien terwijl PHP in versie nummers stijgt en compatibiliteit breekt, zoals met superglobals het geval was.

Een jaar geleden heb ik trouwens een tutorial/code guideline-achtig iets gemaakt (35 bladzijden) maar das al vrij hopeloos outdated en heeft ook niet echt een groot publiek bereikt, iets wat het probleem is met veel tutorials denk ik. Wanneer je als team werkt aan een professioneel PHP project lijkt het mij wel nuttig om zoiets op te stellen als het al niet aanwezig is.

edit:

@AtleX: woei, graag gedaan
Nog 2 kleine tips:
drm's tiplist: http://gerard.yoursite.nl/got/php-tiplist/
en ACM had een PDF geschreven over beveiling van web applicaties, heb er geen url meer van, maar als hij dit leest wil hij hem misschien nog wel eens posten, k'heb em toen iig doorgenomen en vond hem wel nuttig (maar ik kan de pdf zelf ook niet meer terugvinden maar denk wel dat het van hem was )

[ Voor 10% gewijzigd door Apache op 05-07-2004 16:00 ]

[AtleX]

offtopic:
@Apache: Je post is niet nutteloos geweest. Je bracht me op een idee om een probleem op te lossen waar ik al 3 uur aan bezig was.

[ Voor 6% gewijzigd door AtleX op 05-07-2004 15:46 ]

[creative8500]

Hierbij mijn benchmarks betreffende de enkele/dubbele aanhalingtekens:

PHP:

<?php

require_once '../timer.php';

define ('limit', 2500000); // two and a half million

$results = array
(
    'single-quote' => (float) null,
    'double-quote' => (float) null
);

$BenchmarkTimer = new AutomaticBenchmarkTimer;

for ($i = 0; $i < limit; ++$i)
{
    $string = 'hier de test-string';
}

$results['single-quote'] = $BenchmarkTimer -> flush ();

for ($i = 0; $i < limit; ++$i)
{
    $string = "hier de test-string";
}

$results['double-quote'] = $BenchmarkTimer -> flush ();

header ('Content-Type: text/plain');
print "single: {$results['single-quote']}\ndouble: {$results['double-quote']}";

?>

Van dit script heb ik drie varianten, met daarin respectievelijk de volgende strings:

1. Avm # 6^% @ ml A_-12^*mw l31^`1 -> ]
2. Avm # 6^% $@ ml A_-12^*mw l31^`1 -> ]
3. Avm # 6^% \$@ ml A_-12^*mw l31^`1 -> ]

De testresultaten:

code:

VARIANT 1:
  poging 1:
    single: 2.32321882248
    double: 2.32834410667
  poging 2:
    single: 2.34591889381
    double: 2.33790397644
  poging 3:
    single: 2.29426908493
    double: 2.30964899063

VARIANT 2:
  poging 1:
    single: 2.33482122421
    double: 14.0099129677
  poging 2:
    single: 2.3703520298
    double: 13.3962008953
  poging 3:
    single: 2.32201814651
    double: 13.3124818802

VARIANT 3:
  poging 1:
    single: 2.36283707619
    double: 2.33323597908
  poging 2:
    single: 2.32685208321
    double: 2.34363484383
  poging 3:
    single: 2.27271413803
    double: 2.32194685936

Testomgeving:

• Windows XP
• Apache 2.0.49
• PHP 5.0.0RC3
• 1,7GHz Pentium-M

[AtleX]

Is het verschil bij variant 2 te verklaren? Volgens mij komt dat door die toegevoegde $

[Verwijderd]

AtleX schreef op 05 juli 2004 @ 16:14:
Is het verschil bij variant 2 te verklaren? Volgens mij komt dat door die toegevoegde $

yep, bij de 2e variant moet ie kijken wat er na de $ komt om te zien of het niet per ongeluk een variable is die ingevuld moet worden.

[AtleX]

Conclusie, singele-quotes is over het algemeen toch sneller?

[Verwijderd]

AtleX schreef op 05 juli 2004 @ 16:18:
Conclusie, singele-quotes is over het algemeen toch sneller?

Als je in je string een $ gebruikt terwijl dat niet nodig is (wanneer je in die string geen variabele gebruikt...) => Dan is single quote sneller.

Dus:

Het maakt qua snelheid pas uit, wanneer je dollartekens gaat gebruiken...
Zolang je geen dollartekens gebruikt, maakt het qua snelheid niets uit... Nou ja iets, want ook \n, \t etc moet geparsed worden

[ Voor 24% gewijzigd door Verwijderd op 05-07-2004 16:37 ]

[AtleX]

Verwijderd schreef op 05 juli 2004 @ 16:25:
[...]


Als je in je string een $ gebruikt terwijl je in die string geen variabele gebruikt...

Het maakt qua snelheid pas uit, wanneer je dollartekens gaat gebruiken...

Eehm, wat is het verschil tussen een dollarteken en $?

[crisp]

Verwijderd schreef op 05 juli 2004 @ 16:25:
[...]

Het maakt qua snelheid pas uit, wanneer je dollartekens gaat gebruiken...
Zolang je geen dollartekens gebruikt, maakt het qua snelheid niets uit... Nou ja iets, want ook \n, \t etc moet geparsed worden

Dit:

PHP:

$var = 'Hallo ' . $naam;

is sneller dan:

PHP:

$var = "Hallo $naam";

Ik gebruik altijd single quotes omdat het zich voorspelbaar gedraagt in alle gevallen.

[AtleX]

@Crisp:
Ik werk ook altijd op die manier. Niet alleen omdat het sneller is, maar het is ook beter leesbaar. Vooral in editors met syntax-coloring kan je sneller de code doorlezen op zoek naar fouten.

[Erkens]

crisp schreef op 05 juli 2004 @ 16:50:
Ik gebruik altijd single quotes omdat het zich voorspelbaar gedraagt in alle gevallen.

en dat is juist de reden waarom men single quotes moet gebruiken. Niet die paar microsec tijdswinst die je eventueel ermee kan behalen.

[PrisonerOfPain]

crisp schreef op 05 juli 2004 @ 16:50:
[...]

Dit:

PHP:

$var = 'Hallo ' . $naam;

is sneller dan:

PHP:

$var = "Hallo $naam";

Ik gebruik altijd single quotes omdat het zich voorspelbaar gedraagt in alle gevallen.

PHP:

$var = "Hallo {$naam}";

Is het snelst en IMHO het leesbaarst/makkelijkst omdat je de '.' nogal eens over het hoofd ziet

[ Voor 23% gewijzigd door PrisonerOfPain op 05-07-2004 17:03 . Reden: hehe, ja met een ' werkt dat niet nee.. ]

[Erkens]

PrisonerOfPain schreef op 05 juli 2004 @ 16:53:
[...]

PHP:

$var = 'Hallo {$naam}';

Is het snelst en IMHO het leesbaarst/makkelijkst omdat je de '.' nogal eens over het hoofd ziet

als je letterlijk 'Hallo {$naam}' in die var wilt hebben wel ja

maar hoe kan je met een goede editor die punt over het hoofd zien

[ Voor 16% gewijzigd door Erkens op 05-07-2004 16:58 ]

[Apache]

Het leest niet makkelijker want als je zo'n hele zin hebt zie je niet meteen dat er nog maar een variable op die lijn staat

Ik gebruik iig ook single quotes & concateneer wanneer nodig, zoals het ook in andere talen gebeurt, kan je trouwens aantonen dat {} sneller is dan single quotes en concateneren?

[Verwijderd]

Ik werk zelf nogal vaak met sprintf en de verwante functies. Als je 3 of meer variabelen in een string moet zetten gaat dit al sneller dan met:
• dubbele quotes en concatenation
• enkele quotes en concatenation
• dubbele quotes en in-string variabelen

Zonder variabelen is sprintf een kleine 3 keer trager, dat is dus niet zo heel handig om te gebruiken.
Met 1 variabele is het ongeveer 30-35% trager dan concatenation, maar is het al sneller dan een string met dubbele quotes en PHP variabelen erin.
Met 2 variabelen is het ongeveer 20-25% trager dan concatenation, en veel sneller dan dubbele quotes en in-string variabelen.
Met 3 variabelen is het ongeveer even snel als concatenation.
Met 4 variabelen of meer wint sprintf het, zeker als er ook nog eens expliciet getypecast moet worden.

sprintf kent ook nog eens een aantal handige extra'tjes zoals padding, number formatting, etc.

Ik gebruik dus bij voorkeur enkele quotes en (s)printf als er met variabelen wordt gewerkt. Je kunt ook eventueel sprintf en dubbele quotes gebruiken zolang je geen ongeëscapete dollartekens in je strings gebruikt.

[PrisonerOfPain]

Erkens schreef op 05 juli 2004 @ 16:58:
[...]

als je letterlijk 'Hallo {$naam}' in die var wilt hebben wel ja

Ik zou zweren dat daar "Hallo {$naam}" stond, maar ik zal het even aanpassen

maar hoe kan je met een goede editor die punt over het hoofd zien

Nou over het hoofd zien, vergeten :x als ik met een aantal regels klaar ben doe ik altijd even een "alt+tab" en "f5" om de laatse wijzigingen te zien en heel vaak bleek ik een '.' te zijn vergeten (en het is een hel als je dan moet gaan zoeken waar je die punt moet zetten) het ligt niet zo zeer aan m'n editor hoor (die is geweldig) maar aan het lettertype die maar een pixel voor een punt reserveerd.

@Apache, ik heb dat ooit gebenchmarked, ik zal het eens opzoeken (de resultaten staan wel ergens op internet)

[ Voor 12% gewijzigd door PrisonerOfPain op 05-07-2004 17:04 ]

[Erkens]

PrisonerOfPain schreef op 05 juli 2004 @ 17:03:
Nou over het hoofd zien, vergeten :x als ik met een aantal regels klaar ben doe ik altijd even een "alt+tab" en "f5" om de laatse wijzigingen te zien en heel vaak bleek ik een '.' te zijn vergeten (en het is een hel als je dan moet gaan zoeken waar je die punt moet zetten) het ligt niet zo zeer aan m'n editor hoor (die is geweldig) maar aan het lettertype die maar een pixel voor een punt reserveerd.

dan moet je een ander lettertype wellicht overwegen, of je editor instellen dat die concat punt bold gezet word ofzo
Maar als ik een punt vergeet dan krijg ik een "mooie" error van de php engine met daarop het regelnummertje van de fout.

Nog iets waarom je het beter niet zo moet doen is het volgende:

PHP:

$naam = 'Erkens';

echo "Hallo $naam";  // niks "mis" mee :P

echo "Hallo $name"; // oeps per ongeluk verkeerd geschreven, geen error :)

echo 'Hallo ', $naam; // prima
echo 'Hallo ', $name; // sorry een "foutmelding, $name is niet gedefinieerd :)

[PrisonerOfPain]

Erkens schreef op 05 juli 2004 @ 17:07:
dan moet je een ander lettertype wellicht overwegen, of je editor instellen dat die concat punt bold gezet word ofzo

Ik ben nou "{}" gewend, dus waarom zou ik?

Maar als ik een punt vergeet dan krijg ik een "mooie" error van de php engine met daarop het regelnummertje van de fout.

met

PHP:

$var = "foo" . $bar . "foobar" . $barfoo;

Weet je nog niet om welk stuk het ging, daar doelde ik op. Verder ken ik de parse error's van PHP al een flinke tijd hoor ;-)

[Verwijderd]

PHP:

$var = sprintf ( 'foo %s foobar %s',  $bar, $barfoo );

[Erkens]

PrisonerOfPain schreef op 05 juli 2004 @ 17:11:
[...]

Ik ben nou "{}" gewend, dus waarom zou ik?

[...]

met

PHP:

$var = "foo" . $bar . "foobar" . $barfoo;

Weet je nog niet om welk stuk het ging, daar doelde ik op. Verder ken ik de parse error's van PHP al een flinke tijd hoor ;-)

mja, dat neemt nog niet het tweede deel van mijn post weg

Verwijderd schreef op 05 juli 2004 @ 17:14:

PHP:

$var = sprintf ( 'foo %s foobar %s',  $bar, $barfoo );

volgens mij moet ik me hierin eens verdiepen, ziet er een stuk beter uit

[Verwijderd]

Om je nog even een praktischer voorbeeld te geven:

PHP:

printf ( '<a href="product.php?id=%u">%s</a>',
   $product['id'],
   htmlentities ( $product['name'] )
);

[PrisonerOfPain]

Verwijderd schreef op 05 juli 2004 @ 17:14:

PHP:

$var = sprintf ( 'foo %s foobar %s',  $bar, $barfoo );

sprintf gebruik ik eigenlijk alleen als ik meerdere standaard teksten heb waar telkens dezelfde waarde in moet. Dus bijvoorbeeld SQL-Queries tegen een database onafhankelijke class. Op de manier die jij nu voorsteld vind ik het een beetje overkill, PHP heeft operators om het truukje te doen, maar dan ga je een aparte functie gebruiken die hetzelfde doet..

[sjokki]

Na het lezen van deze thread weet ik wel waarom er zoveel brakke php-code is. Php programmeurs houden zich namelijk veel te veel bezig met discussiëren over kleinigheden zoals enkele vs dubbele quotes maar zien ondertussen belangrijke zaken over het hoofd .

Veel code is inderdaad moeilijk te begrijpen als je het niet zelf geschreven hebt. Maar de mensen die het wel geschreven hebben begrijpen het vaak prima omdat ze een bepaald systeem hebben gebruikt.

Een quote van c2:

spaghetti code often is all code that is not our own because it was generated by minds that think differently than us

Dat is op te lossen door met z'n allen op de zelfde manier te programmeren. En dat kan je bereiken door middel van coding standards en het gebruik van een framework.

[PrisonerOfPain]

sjokki schreef op 05 juli 2004 @ 17:36:
Veel code is inderdaad moeilijk te begrijpen als je het niet zelf geschreven hebt. Maar de mensen die het wel geschreven hebben begrijpen het vaak prima omdat ze een bepaald systeem hebben gebruikt.

Of je documenteert het systeem dat je gebruikt, schrijf op waarom je methode x gebruikt ipv methode y, schrijf ontwerp documenten, zeker als je weet dat je publieke code gaat schrijven. Ik heb ook wel eens gehad dat ik m'n eigen code niet meer begreep omdat ik het commentaar was 'vergeten' als je dat is overkomen denk je echt wel een tweede keer om commentaar te vergeten.

[alienfruit]

Hmm, ik hoop dan eigenlijk dat er in PHP5 standaard, de strict-typing functionaliteit aan staat, en de backward compatibility met PHP4 standaard uit. Om zodoende beginners te dwingen.

[PrisonerOfPain]

alienfruit schreef op 05 juli 2004 @ 18:00:
Hmm, ik hoop dan eigenlijk dat er in PHP5 standaard, de strict-typing functionaliteit aan staat, en de backward compatibility met PHP4 standaard uit. Om zodoende beginners te dwingen.

Helaas, de enige manier om 'types' af te dwingen in PHP is met typehints:

PHP:

<?php
class Foo
{
         public function Bar ()
         {
                  echo "FooBar";
         }
}

function BarFoo (Foo $FooFoo)
{
         $FooFoo->Bar();
}
?>

Je kan op die manier dus een class (of interface) afdingen als argument, maar verder als dat gaat het niet.

[stekkel]

crisp schreef op 05 juli 2004 @ 16:50:
[...]

Dit:

PHP:

$var = 'Hallo ' . $naam;

is sneller dan:

PHP:

$var = "Hallo $naam";

Ik gebruik altijd single quotes omdat het zich voorspelbaar gedraagt in alle gevallen.

Dat zou ik niet met stelligheid durven te beweren. Men vergeet namelijk wel eens dat concatenatie van strings ook tijd kost. Het is dus maar de vraag of het voordeel van single quotes bij korte strings opweegt tegen de concatenatie handeling.

[Verwijderd]

stekkel schreef op 05 juli 2004 @ 18:24:

Dat zou ik niet met stelligheid durven te beweren. Men vergeet namelijk wel eens dat concatenatie van strings ook tijd kost. Het is dus maar de vraag of het voordeel van single quotes bij korte strings opweegt tegen de concatenatie handeling.

Benchmark het maar. Concatenation is sneller.

[crisp]

We dwalen wel een beetje af met dat dubbel-quote vs enkel-quote gedoe. Het hele punt is al bewezen door het feit dat er meteen al gevraagd werd wat nou eigenlijk het verschil is. Dat geeft dus al aan dat veel mensen de reference niet doorlezen en/of klakkeloos alles overnemen wat ze aan voorbeeldcode zien.
Alle mensen die hier met goede alternatieven gestaafd met argumenten komen snappen het tenminste, die denken er tenminste over na, en dan maakt het op zich niet uit of je maniertje A of maniertje B gebruikt (het verschil qua performance is natuurlijk nagenoeg nihil) - je weet dan in ieder geval waar je mee bezig bent, en dat is m.i. het belangrijkste

[stekkel]

Verwijderd schreef op 05 juli 2004 @ 18:26:
[...]

Benchmark het maar. Concatenation is sneller.

Je hebt gelijk.

Op php 4.3.6 scheelt het ongeveer 50% en op php 4.2.3 ongeveer 75%.

edit:
Crisp, dat is inderdaad de kern van de zaak

[ Voor 14% gewijzigd door stekkel op 05-07-2004 18:45 ]

[Spruit_elf]

PrisonerOfPain schreef op 05 juli 2004 @ 13:49:
Bij ' worden (bijna) alle waarde's letterlijk genomen (behalve ' en \ geloof ik, die moet je escapen) je kan dus niet zetten '\n' om een newline af te drukken, bij " heb je een hoop meer mogenlijkheden, er zijn meer tekens om te escapen, je kan er variablen in zetten maar het is ook iets trager als '..

als je dan met single quotes geen \n meer kan gebruiken, hoe doen zorgen jullie er dan voor dat de uitgepoepte html een beetje leesbaar is.

zelf vind ik het namelijk erg prettig als de html uiteindelijk ook goed leesbaar is, dat helpt weer bij het opsporen van fouten, en zonder die \n loop het vreeselijk door elkaar.

een oplossing is om het zo tte doen

PHP:

<?
if(!$blaat){
?>
<html>
     <body>
          <p>Hier wat html
          </p>
     </body>
</html>
<?
}
?>

maar als je dan met variabelen wil werken dan wordt het er al helemaal neit beter op

PHP:

<?
if(!$blaat){
$foo = 'html'
?>
<html>
     <body>
          <p>Hier wat <?=$foo?>
          </p>
     </body>
</html>
<?
}
?>

dan is het hier vanwege de shorttags nog te overzien, maar zonder
zelf vind ik dat niet echt een oplossing.
wat is volgens jullie de "netste" methode? om dus zonder "overbodige" php dingen
zoals double quotes met \n (in het geval van geen variabelen)
om dan toch leesbaar html te krijgen? of vinden jullie dat niet erg belangrijk?

[.oisyn]

Verwijderd schreef op 04 juli 2004 @ 20:53:
Zelf heb ik dit lijstje gemaakt met punten waar code aan moet voldoen:
-goed uitbreidbaar -> veel code is niet eenvoudig recyclebaar en hier bedoel ik dan niet mee dat het niet te gebruiken is nadat alles is gecopyenpaste en daarna hier en daar iets is aangepast, maar dat er weinig gebruik wordt gemaakt van classes die weer eenvoudig aangeroepen kunnen worden indien het ergens nodig is. Misschien is OO dus een goeie oplossing.

OO in PHP
Brakke code wordt natuurlijk overal in geschreven, maar in PHP lijkt het toch wel het meest te gebeuren. Nou heeft dat natuurlijk voor een groot deel te maken met de relatief lage drempel om met php overweg te kunnen, anderzijds denk ik dat het ook komt door de taal zelf. Want laten we wel wezen, daar is dus totaal niet over nagedacht

En dan bedoel ik niet dingen als strong-typing; het blijft een scripttaal, en er kan wel degelijk baat zijn bij een loose-typed systeem. Waar ik echter wel een bloedhekel aan heb is hoe met scopes, references en classes omgegaan wordt, dat is gewoon ronduit ranzig. Ik ga het hier niet allemaal nog een keer uitgebreid op tafel leggen, dat heb ik al genoeg gedaan , maar laten ze eerst maar eens een keer een goede taal produceren met een handige feature-set en semantiek waarover nagedacht is, met een bijbehorende consistente, goed opgezette standaard library. Tot die tijd blijft zelfs de netste php code utter crap

[PrisonerOfPain]

mrcactus schreef op 06 juli 2004 @ 02:33:
[...]

als je dan met single quotes geen \n meer kan gebruiken, hoe doen zorgen jullie er dan voor dat de uitgepoepte html een beetje leesbaar is.

HTML echo'en vind ik ook al zo ranzig, maar goed als voorbeeld

PHP:

echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
      <head>
            <title>
                  Blaat
            </title>
      </head>
      <body>
            Test page
      </body>
</html>';

Staat ook in de manual overigens

zelf vind ik het namelijk erg prettig als de html uiteindelijk ook goed leesbaar is, dat helpt weer bij het opsporen van fouten, en zonder die \n loop het vreeselijk door elkaar.

Vind ik ook, het is toch een soort visite kaartje he

een oplossing is om het zo tte doen

PHP:

<?
if(!$blaat){
?>
<html>
     <body>
          <p>Hier wat html
          </p>
     </body>
</html>
<?
}
?>

maar als je dan met variabelen wil werken dan wordt het er al helemaal neit beter op

PHP:

<?
if(!$blaat){
$foo = 'html'
?>
<html>
     <body>
          <p>Hier wat <?=$foo?>
          </p>
     </body>
</html>
<?
}
?>

dan is het hier vanwege de shorttags nog te overzien, maar zonder
zelf vind ik dat niet echt een oplossing.
wat is volgens jullie de "netste" methode? om dus zonder "overbodige" php dingen
zoals double quotes met \n (in het geval van geen variabelen)
om dan toch leesbaar html te krijgen? of vinden jullie dat niet erg belangrijk?

Dat zou ik met alternatieve control structures oplossen, maar het is een manier

.oisyn schreef op 06 juli 2004 @ 02:58:
En dan bedoel ik niet dingen als strong-typing; het blijft een scripttaal, en er kan wel degelijk baat zijn bij een loose-typed systeem. Waar ik echter wel een bloedhekel aan heb is hoe met scopes, references en classes omgegaan wordt, dat is gewoon ronduit ranzig. Ik ga het hier niet allemaal nog een keer uitgebreid op tafel leggen, dat heb ik al genoeg gedaan , maar laten ze eerst maar eens een keer een goede taal produceren met een handige feature-set en semantiek waarover nagedacht is, met een bijbehorende consistente, goed opgezette standaard library. Tot die tijd blijft zelfs de netste php code utter crap

Om je dunk van PHP nog wat op te krikken, ik probeerde laatst de Directory (standaard class die Dir uitwerpt) class uit te breiden omdat ik 'm nogal kaal vond. Standaard heeft de Directory class geen constructor en mist het ook de twee variabele $handle en $path, dat is niet zo erg dat kunnen we oplossen, ik bedacht de volgende constructie:

PHP:

<?php
class myDir extends Directory
{
    private $handle;
    public $path;

    public function __construct ($file)
    {
        $this->handle = opendir (realpath ($file));
    }
}

$D = new myDir ('.');
echo $D->read();
?>

Maar deze gaf een error:

code:

Warning: Directory::read() [function.read]: Unable to find my handle property in
/usr/local/apache2/htdocs/dir.php on line 14

Wat bleek nou (na het doorspitten van de source van PHP, dit staat niet in de manual, blijkbaar) is dat $handle public moet zijn omdat de method's gewoon gemapped worden naar de standaard PHP functies (readdir, rewinddir en closedir) en die kan dus ook niet bij z'n handle op een dergelijke manier...

[creative8500]

PrisonerOfPain: Om je dunk van PHP nog wat op te krikken, [...]

En hoe bewijst PHP zich hier als goede programmeertaal, wat jou betreft?

[PrisonerOfPain]

creative8500 schreef op 06 juli 2004 @ 13:51:
En hoe bewijst PHP zich hier als goede programmeertaal, wat jou betreft?

Was sarcastisch bedoeld ik verbaadse mij er enorm over dat PHP niet ergens in interne mini-class (zodat het voor die class niet uit maakt of die parameter public is of niet) heeft maar het zo oploste.

PHP:

<?php
class Directory
{
        private $handle;
        public $path;

        public function __construct ($path)
        {
                $this->handle = opendir (realpath ($path));
        }

        public function read ()
        {
                return readdir ($this->handle);
        }

        public function close ()
        {
                closedir ($this->handle);
        }

        public function rewind ()
        {
                rewinddir ($this->handle);
        }
}
?>

Zo heb je het voordeel dat het niet uitmaakt of je $handle private maakt of niet en het lijkt me niet zo enorm veel werk (ik moet wel bekennen dat ik weinig kaas heb gegeten van PHP-core devven, maar ik zal het eens onderzoeken ) om na te bootsen. Ipv de IMHO erg gare oplossing die ze nu hebben gekozen..

[whoami]

Apache schreef op 05 juli 2004 @ 15:41:

edit:

@AtleX: woei, graag gedaan
en ACM had een PDF geschreven over beveiling van web applicaties, heb er geen url meer van, maar als hij dit leest wil hij hem misschien nog wel eens posten,

Dat artikel staat in de P&W FAQ.

[Grijze Vos]

mrcactus schreef op 06 juli 2004 @ 02:33:
[...]

als je dan met single quotes geen \n meer kan gebruiken, hoe doen zorgen jullie er dan voor dat de uitgepoepte html een beetje leesbaar is.

Om crisp maar even uit tig andere topics te quoten:

code:

define('CR', "\n");

echo 'blaat'.CR.'blaat';

[ Voor 6% gewijzigd door Grijze Vos op 06-07-2004 14:28 ]

[PrisonerOfPain]

Grijze Vos schreef op 06 juli 2004 @ 14:28:
[...]


Om crisp maar even uit tig andere topics te quoten:

code:

define('CR', "\n");

echo 'blaat'.CR.'blaat';

Het enige nut wat ik daarvan in zie is dat je snel van newline kunt wisselen, anders hoor je IMHO gewoon " te gebruiken hoor, daar is het voor bedoeld.

[Erkens]

PrisonerOfPain schreef op 06 juli 2004 @ 14:34:
[...]

Het enige nut wat ik daarvan in zie is dat je snel van newline kunt wisselen, anders hoor je IMHO gewoon " te gebruiken hoor, daar is het voor bedoeld.

vind ik juist onhandiger, en meer typ werk:

PHP:

echo 'blaat',"\n",'blaat';
// ipv
echo 'blaat',CR,'blaat';

[ Voor 11% gewijzigd door Erkens op 06-07-2004 14:38 ]

[.oisyn]

Mja ik gebruik eigenlijk gewoon altijd double-quotes, aangezien ik dat gewoon gewend ben als C++ programmeur Ik zie eigenlijk geen reden om single-quotes te gebruiken, last van dubbele slashes heb je toch wel. Nou ja goed, dan moet je de $ escapen om die te outputten, maar zo vaak komt dat niet voor, en bovendien kun je dan gelijk gebruik maken van control chars zoals \r en \n

[RwD]

Verwijderd schreef op 05 juli 2004 @ 16:25:
[...]


Als je in je string een $ gebruikt terwijl dat niet nodig is (wanneer je in die string geen variabele gebruikt...) => Dan is single quote sneller.

Dus:

Het maakt qua snelheid pas uit, wanneer je dollartekens gaat gebruiken...
Zolang je geen dollartekens gebruikt, maakt het qua snelheid niets uit... Nou ja iets, want ook \n, \t etc moet geparsed worden

Wat loop je tegen mij dan nog te zeggen dat ik geen gelijk heb als ik beweer dat single quotes sneller zijn? Mijn achterliggende gedachte was dat double quote strings nog geparsed worden, dus zo fout was die gedachte niet gezien de benchmarks na de jouwe....

(Bovendien had ik dit al een hele tijd geleden al eens gelezen in een artikel ik geloof op php.net)

[.oisyn]

Parsen is wat anders, je bedoelt scannen
Single-quoted strings moeten ook gescanned worden, namelijk op slashes. Zo'n scanner wordt meestal gegenereerd uit een lexical analyser generator, wat een O(n) algoritme gebruikt om tekens te vinden. Het aantal verschillende tekens dat gevonden moet worden maakt niet uit, waardoor een string met double quotes en zonder $ dus net zo snel is als een string met single quotes

[Verwijderd]

.oisyn schreef op 06 juli 2004 @ 15:14:
Parsen is wat anders, je bedoelt scannen
Single-quoted strings moeten ook gescanned worden, namelijk op slashes. Zo'n scanner wordt meestal gegenereerd uit een lexical analyser generator, wat een O(n) algoritme gebruikt om tekens te vinden. Het aantal verschillende tekens dat gevonden moet worden maakt niet uit, waardoor een string met double quotes en zonder $ dus net zo snel is als een string met single quotes

En dat komt ook naar voren als je de boel benchmarkt. Zolang je geen dollartekens ongeëscapet gebruikt zijn dubbele quotes net zo snel als enkele quotes.
Ik gebruik zelf bij voorkeur enkele quotes omdat ik dan zonder te escapen dubbele quotes kan gebruiken voor HTML output. Maar als je geen hekel hebt aan escapen kun je inderdaad prima dubbele quotes gebruiken.

[Olaf van der Spek]

mrcactus schreef op 06 juli 2004 @ 02:33:
dan is het hier vanwege de shorttags nog te overzien, maar zonder
zelf vind ik dat niet echt een oplossing.
wat is volgens jullie de "netste" methode? om dus zonder "overbodige" php dingen
zoals double quotes met \n (in het geval van geen variabelen)
om dan toch leesbaar html te krijgen? of vinden jullie dat niet erg belangrijk?

IMO is het totaal niet belangrijk.
Maar met een template engine is de PHP toch wel van de HTML te scheiden op een nette manier?

[megamuch]

Mag ik dan ook even de andere kant op pissen.

Erg veel kritiek hier op PHP omdat het ranzig is, en het niet goed omgaat met references, objecten en weet ik veel wat nog meer.

Like who the f*ck cares??

PHP is een simpele scripting taal met een berg aan functies die je in andere talen zelf zou moeten schrijven.

PHP is snel.
PHP is eenvoudig om te leren.
PHP heeft plenty of built-in functies die erg handig zijn.

En buiten dat, er is een gigantische support voor de taal. Hulp nodig? Check 1 van de 1001 sites over php en je kan je antwoord vaak genoeg wel vinden.

Waar mensen hier vooral aan voorbij gaan is het feit dat ze php willen gebruiken als volwaardige programmeer omgeving. Iets wat 90% van de php scripters niet nodig hebben, laat staan snappen.

Als ik kijk naar mezelf:
ik heb geen idee wat een object is
geen flauw idee wat ik met inheritance moet
public of private? yeah whatever

En toch kan ik met php aardige scripjes schrijven. Simpele websitejes bouwen met zoekmogelijkheden etc. Prima. Class downloaden en gebruiken in m'n scripts wil ook nog wel lukken.

En volgens mij hoor ik tot het merendeel van de php scripters. Die bouwen geen sites voor 100.000 users. Gewoon lekker prutsen en wat leuks bouwen. Iets waar PHP vanaf het begin ook voor bedoelt is. Het is allemaal wat uit de klauwen gegroeid, met een aantal onvolkomenheden. Deal with it.

Als je al die fancy dingen nodig hebt, pak dan .NET / java / <insert random taal> en laat php links liggen.


/end rant

[Verwijderd]

.oisyn schreef op 06 juli 2004 @ 15:14:
Parsen is wat anders, je bedoelt scannen
Single-quoted strings moeten ook gescanned worden, namelijk op slashes. Zo'n scanner wordt meestal gegenereerd uit een lexical analyser generator, wat een O(n) algoritme gebruikt om tekens te vinden. Het aantal verschillende tekens dat gevonden moet worden maakt niet uit, waardoor een string met double quotes en zonder $ dus net zo snel is als een string met single quotes

Amen, dat was dus mijn hele verhaal...

[Olaf van der Spek]

Verwijderd schreef op 04 juli 2004 @ 20:53:
-veilig -> het is al mooi om te zien dat addslashes veel gebruikt wordt (hoewel dit vaak zorgt voor een dubbel addslashes idee omdat standaard magic slash meuk van php aanstaat), maar de veel zo te downloade code is lek.

Maar wat is nou precies DE manier?
Met de magic_quotes_gpc functie is addslashes toch niet meer nodig?

[Janoz]

OlafvdSpek schreef op 06 juli 2004 @ 15:50:
[...]

Maar wat is nou precies DE manier?

PHP:

if (!get_magic_quotes_gpc()) {
   $lastname = addslashes($_POST['lastname']);
} else {
   $lastname = $_POST['lastname'];
}

Dit is de manier waarop het imho in alle te downloade server onafhankelijke voorbeelden zou moeten voorkomen.

[RwD]

.oisyn schreef op 06 juli 2004 @ 15:14:
Parsen is wat anders, je bedoelt scannen
Single-quoted strings moeten ook gescanned worden, namelijk op slashes. Zo'n scanner wordt meestal gegenereerd uit een lexical analyser generator, wat een O(n) algoritme gebruikt om tekens te vinden. Het aantal verschillende tekens dat gevonden moet worden maakt niet uit, waardoor een string met double quotes en zonder $ dus net zo snel is als een string met single quotes

Parsen/scannen, je wist wat ik bedoel. Ik wil nogal snel parsen zeggen terwijl ik vrijwel altijd scannen bedoel (ik werk momenteel met Omnimark, mocht je dat wat zeggen)

Punt is dat je zelf al aangeeft dat een string met dubbele quotes langzamer is. Dat ze ook even snel kunnen zijn doet er niet toe, alle toepassingen meegenomen is een dubbelquote gemiddeld langzamer dan een single quote string, en dus langzamer...

Of niet dan? Anders is een fiat net zo snel als een ferrari, tenzij de fiat een ferrari Enzo is, want een Ferrari valt onder het Fiat concern. <-- die laatste zin hoef je niet letterlijk te nemen, de vergelijking viel tijdens het typen buiten de context.
Ik bedoelde dat twee auto's dan ook even snel zijn, totdat je in eentje een dik persoon met veel dollars zet, die niet in de andere past. In principe ga je dan die persoon altijd in die ene auto proppen, en als iemand anders mee wil kan ie beter in de andere auto gaan zitten, die is meestal sneller...

[Verwijderd]

OlafvdSpek schreef op 06 juli 2004 @ 15:50:
[...]

Maar wat is nou precies DE manier?
Met de magic_quotes_gpc functie is addslashes toch niet meer nodig?

Uit de oude doos:

PHP:

/**
*  Apply magic quotes
*
*  @access public
*  @param  array|string  The input variable
*  @return void
*  @author Jorgen Horstink
*/
function apply_magic_quotes(&$arr)
{
  if (!ini_get('magic_quotes_gpc')) {
    if (is_array($arr)) {
      $c = sizeOf($arr);
      $a = array_keys($arr);
      for ($i = 0; $i < $c; $i++) {
        if (is_array($arr[$a[$i]])) {
          apply_magic_quotes($arr[$a[$i]]);
        } else {
          $arr[$a[$i]] = addslashes($arr[$a[$i]]);
          $arr[$a[$i]] = addslashes($arr[$a[$i]]);
        }
      }
    } elseif (is_string($arr)) {
      $arr = addslashes($arr);
      $arr = addslashes($arr);
    }
  }
}
?>

[ Voor 13% gewijzigd door Verwijderd op 06-07-2004 16:44 ]