Beginnersfouten tegengaan 
Door Roel PHP, 2 jaar geleden, 9.188x bekeken
In deze tutorial ga ik uitleggen hoe je netjes kunt programmeren en hoe je beginnersfouten tegen kunt gaan. Dit doe ik over verschillende onderdelen (hieronder te zien) en ik leg ook een klein stukje beveiliging uit en geef bij elk onderdeel een voorbeeld en waarom je het juist zo moet doen.
Wat bespreek ik?
- Leesbaarheid en duidelijkheid
- SQL-injection
- XSS-injection
- Gebruik van backticks in MySQL
- Correcte foutenafhandeling
- Geheugenefficiënt programmeren
Mocht je nog vragen hebben, dan kun je ze hieronder plaatsen of op het forum.
Gesponsorde koppelingen
Inhoudsopgave
- Leesbaarheid
- SQL-injection
- XSS-injection
- Gebruik van backticks in MySQL
- Correcte foutenafhandeling
- Geheugenefficiënt programmeren
- Slot
43 reacties op 'Beginnersfouten tegengaan'
Gesponsorde koppelingen
Hoi,
Daar heb je inderdaad gelijk in. Het is eigenlijk meer een tutorial waar leden naar kunnen verwijzen i.p.v. dat ze dingen blijven herhalen (eigenlijk alle punten in mijn tutorial).
Een andere naam zou beter zijn. Heb je misschien een voorstel?
Overigens werk ik nog niet echt met Zend e.d. dus kan ik hier moeilijk iets over vertellen, maar in de toekomst wil ik dit zeker doen!
Daar heb je inderdaad gelijk in. Het is eigenlijk meer een tutorial waar leden naar kunnen verwijzen i.p.v. dat ze dingen blijven herhalen (eigenlijk alle punten in mijn tutorial).
Een andere naam zou beter zijn. Heb je misschien een voorstel?
Overigens werk ik nog niet echt met Zend e.d. dus kan ik hier moeilijk iets over vertellen, maar in de toekomst wil ik dit zeker doen!
Beste Roel,
Daar lijkt het mij inderdaad meer geschikt voor. Gezien dat punt is het een mooie toevoeging!
Een betere naamgeving laat ik aan jouw over ;-)
Je hoeft niet met Zend te werken om hun coding standards te gebruiken. Ik dacht dat het wel een mooi idee zou zijn om diversen coding standards te tonen. De lezer kan dan zelf bepalen welke standard hij kiest.
Niels Kieviet
Daar lijkt het mij inderdaad meer geschikt voor. Gezien dat punt is het een mooie toevoeging!
Een betere naamgeving laat ik aan jouw over ;-)
Je hoeft niet met Zend te werken om hun coding standards te gebruiken. Ik dacht dat het wel een mooi idee zou zijn om diversen coding standards te tonen. De lezer kan dan zelf bepalen welke standard hij kiest.
Niels Kieviet
Bij het kopje 'correcte foutafhandeling' maak je gebruik van
Dit gebruikte ik ook altijd alleen nu is mij geleerd dat het netter is om:
te gebruiken.
Dit gebruikte ik ook altijd alleen nu is mij geleerd dat het netter is om:
te gebruiken.
- SanThe - op 04/12/2011 23:02:37:
$query bevat alleen een boolean (false) als de query mislukt is. Jij checked in feite op een true boolean en dat zal er nooit in zitten. Als ie gelukt is zit er een resource# in.
if($sql === false) is waarschijnlijk de beste optie. En als dat dus waar is, dan volgt de error.
if($sql === false) is waarschijnlijk de beste optie. En als dat dus waar is, dan volgt de error.
Tobias tobias:
Wat betreft het verschil tussen netjes en veilig: Een gehackte site ziet er vaak niet netjes meer uit ;-)
Daar ben ik het niet mee-eens Tobias. Een aantal jaar geleden is een site, die ik gerealiseerd heb, ook gehacked en volgens mij programmeer ik wel netjes. Ik was simpelweg iets vergeten. (Wat natuurlijk uit de boze is)
Quote:
$query bevat alleen een boolean (false) als de query mislukt is. Jij checked in feite op een true boolean en dat zal er nooit in zitten. Als ie gelukt is zit er een resource# in.
if($sql === false) is waarschijnlijk de beste optie. En als dat dus waar is, dan volgt de error.
if($sql === false) is waarschijnlijk de beste optie. En als dat dus waar is, dan volgt de error.
Dat is inderdaad de juiste manier. Het is sowieso belangrijk dat je per functie die gebruikt heel even kijkt wat de functie retourneert. (als dat het geval is)
Ik kan je zeggen, bij de meeste PHP connect functies retourneert de functie in het geval dat de connectie geslaagd is een resource. Kijk maar eens bij de volgende functies:
ldap_connect (Ligt bij ldap_connect welke versie je hebt wanneer je LDAP versie 2 gebruikt retourneert ldap_connect altijd een resource. Uit mijn hoofd: Bij success een resource type 3/4 en bij een fail een resource type 2/3)
mysql_connect
cubrid_connect
fbsql_pconnect
Bij de functie socket_connect (Waarvan je af kan vragen of het een echte connect functie is) krijg je daarin tegen wel een true/false terug.
Inhoudelijk commentaar
In hoofdstuk 3 (onderaan) maak je gebruik van htmlentities. Mooi dat je dat uitlegt, maar we hebben ook nog htmlspecialchars. Ik zou het een mooie toevoeging vinden wanneer je het verschil uitlegt. Pas geleden heeft onze vriend PHP Jasper een topic geopend waarin ik samen met Pim heb uit gelegd wat het verschil is. (het topic) Ook wordt in dat topic wat uitgelegd over ENT_QUOTES en UTF-8 encoding i.c.m de bovengenoemde functies.
Ook kwam ik in hoofdstuk 4 het volgende tegen:
"Het gebruik van or die en mysql_error op een live website is dus uit den boze, dat mag duidelijk zijn!"
Ik hoop niet dat je bedoeld dat ik in een liveomgeving alle mysql_error functies (die ik ergens in de code gebruik) moet verwijderen? Ik neem aan dat je op error_reporting doelt?
Tot slot, je zegt "het gebruik van or die op een live omgeving .... " terwijl je daarboven foutafhandeling op basis van een if/else structuur uitlegt?
Niels Kieviet
Beste Roel,
Nog heel even een kleine opmerking. (Ik zet dit heel even in een nieuwe post aangezien ik het anders onoverzichtelijk wordt)
Ik vind dat je in het eerste hoofdstuk ook nog heel even de leesbaarheid van een query moet toevoegen.
Daarnaast, in hoofdstuk 5 zet jij alle values (met mysql_real_escape_string) achter elkaar. Persoonlijk vind ik dat onoverzichtelijk. Zelf zet ik alle values op een aparte regel.
Niels Kieviet
Nog heel even een kleine opmerking. (Ik zet dit heel even in een nieuwe post aangezien ik het anders onoverzichtelijk wordt)
Ik vind dat je in het eerste hoofdstuk ook nog heel even de leesbaarheid van een query moet toevoegen.
Daarnaast, in hoofdstuk 5 zet jij alle values (met mysql_real_escape_string) achter elkaar. Persoonlijk vind ik dat onoverzichtelijk. Zelf zet ik alle values op een aparte regel.
Niels Kieviet
Ik zal dit toch eens grondig bekijken.
Op zich is dit heel interessant. Bv. als men nog eens voor de duizendste keer vraagt wat sql injection is ... dan heb je hier een plekje waar men direct naar kan verwijzen.
Nu, hoofdstuk "Leesbaarheid"...
Er is in php niet slechts 1 manier waarop je het goed kan doen.
Je hebt mensen die de openende accolade liever op de zelfde lijn zetten, anderen willen accolades die verticaal op de zelfde plaats staan.
Wat mij betreft is dat een kwestie van smaak.
Voor zover ik weet, is er geen algemene consensus.
Ook dat aanduiden van types.
Bekijk eens een willekeurige pagina op php.net, bv http://php.net/manual/en/function.strpos.php
Ik zie nergens type-aanduidingen.
Ook hier lijkt me dit vooral een kwestie van smaak.
Ik gebruik liefst de coding standards van drupal http://drupal.org/coding-standards .
Je zou kunnen uitleggen dat je slechts 1 model gebruikt en dat andere ook bestaan.
Maar voor de rest moet ik het nog eens grondig bekijken. Het ziet er interessant uit.
Op zich is dit heel interessant. Bv. als men nog eens voor de duizendste keer vraagt wat sql injection is ... dan heb je hier een plekje waar men direct naar kan verwijzen.
Nu, hoofdstuk "Leesbaarheid"...
Er is in php niet slechts 1 manier waarop je het goed kan doen.
Je hebt mensen die de openende accolade liever op de zelfde lijn zetten, anderen willen accolades die verticaal op de zelfde plaats staan.
Wat mij betreft is dat een kwestie van smaak.
Voor zover ik weet, is er geen algemene consensus.
Ook dat aanduiden van types.
Bekijk eens een willekeurige pagina op php.net, bv http://php.net/manual/en/function.strpos.php
Ik zie nergens type-aanduidingen.
Ook hier lijkt me dit vooral een kwestie van smaak.
Ik gebruik liefst de coding standards van drupal http://drupal.org/coding-standards .
Je zou kunnen uitleggen dat je slechts 1 model gebruikt en dat andere ook bestaan.
Maar voor de rest moet ik het nog eens grondig bekijken. Het ziet er interessant uit.
Een accolade op de zelfde lijn is even overzichtelijk als een accolade op de volgende lijn (wat mij betreft soms zelfs meer).
Zolang je maar een consistent systeem hebt en je er aan houdt.
In sommige talen/frameworks kan je enkel op deze manier indenteren.
Neem nu jQuery. Ik wil er niet aan denken hoe mensen dit zouden maken met elke openende accolade en rond haakje op een volgende lijn.
Okay, dit is niet php, ... maar toch.
(bv. http://docs.jquery.com/Tutorials:Getting_Started_with_jQuery )
Zolang je maar een consistent systeem hebt en je er aan houdt.
In sommige talen/frameworks kan je enkel op deze manier indenteren.
Neem nu jQuery. Ik wil er niet aan denken hoe mensen dit zouden maken met elke openende accolade en rond haakje op een volgende lijn.
Okay, dit is niet php, ... maar toch.
(bv. http://docs.jquery.com/Tutorials:Getting_Started_with_jQuery )
Leuke tutorial Roel! Een klein foutje dat ik op het eerste gezicht tegenkwam: in het laatste code blok op deze pagina gebruik je $sql in je if-statement terwijl dat $qSql moet zijn ;-)
MySQL kent ook een dual table; het is alleen niet (zoals bij Oracle) verplicht hem expliciet op te nemen in je query.
Dus: "select now();" en "select now() from dual;" zijn in MySQL equivalent. Wel heb ik gemerkt dat bijvoorbeeld phpMyAdmin niet goed werkt. Als je een database hebt geselecteerd mag je in PMA de "from dual" niet opgeven, en als je geen database hebt geselecteerd moet het juist wel. Via de command line werkt het echter wel goed. Ik durf niet te zeggen hoe de mysql-functies van PHP ermee omgaan en kan het helaas nu ook niet uitproberen.
Dus: "select now();" en "select now() from dual;" zijn in MySQL equivalent. Wel heb ik gemerkt dat bijvoorbeeld phpMyAdmin niet goed werkt. Als je een database hebt geselecteerd mag je in PMA de "from dual" niet opgeven, en als je geen database hebt geselecteerd moet het juist wel. Via de command line werkt het echter wel goed. Ik durf niet te zeggen hoe de mysql-functies van PHP ermee omgaan en kan het helaas nu ook niet uitproberen.
Kobar Secret,
Deze vragen horen denk ik eerder thuis bij de tutorial die ik pas geschreven heb: http://www.phphulp.nl/php/tutorial/scripting-ajax-html-css/html-in-2012/767/
Maar om toch te antwoorden:
1) Nee, HTML schrijf je niet om hoe het eruit ziet in de browser. Dat is CSS. HTML is het semantisch weergeven van tekst. Dat klinkt heel moeilijk, maar dat betekend dat elke tag een beschrijving heeft en dat je een tag moet gebruiken om een stukje tekst dezelfde beschrijving te geven. Een <h3> tag geeft aan dat het een titel is van level 3. Dat is nog behoorlijk hoog.
Een <b> tag is een oude tag (tegenwoordig gebruiken we <strong>) en dat zorgt ervoor dat er wat nadruk op de tekst gelegd wordt.
Een titel of een woordje met wat nadruk, daar zit natuurlijk een wereld van verschil in.
2) Een frame is slecht voor je SEO (zoekmachine vriendelijkheid), is moeilijk te stijlen, haalt eigenlijk 2 pagina's uit elkaar terwijl het 1 pagina is en ga maar door. Frames werden gebruikt in 2000 nu, 12 jaar later, hebben we al veel betere methoden. Precies zoals je zou vragen 'waarom heb jij Windows 7? Waarom geen Microsoft DOS?' Dat is een wereld van verschil tussen technologie en iedereen weet dat Windows 7 beter is.
3) Dit is hetzelfde als met puntje 1. Een <br> tag geeft een break aan. Het is dus een enter. Een <p> tag staat voor paragraph, alinea. Het verschil is dus dat je tekst in een p element ziet als een alinea en tekst met 2x een break erachter zit als een losstaand niets betekend zinnetje.
Deze vragen horen denk ik eerder thuis bij de tutorial die ik pas geschreven heb: http://www.phphulp.nl/php/tutorial/scripting-ajax-html-css/html-in-2012/767/
Maar om toch te antwoorden:
1) Nee, HTML schrijf je niet om hoe het eruit ziet in de browser. Dat is CSS. HTML is het semantisch weergeven van tekst. Dat klinkt heel moeilijk, maar dat betekend dat elke tag een beschrijving heeft en dat je een tag moet gebruiken om een stukje tekst dezelfde beschrijving te geven. Een <h3> tag geeft aan dat het een titel is van level 3. Dat is nog behoorlijk hoog.
Een <b> tag is een oude tag (tegenwoordig gebruiken we <strong>) en dat zorgt ervoor dat er wat nadruk op de tekst gelegd wordt.
Een titel of een woordje met wat nadruk, daar zit natuurlijk een wereld van verschil in.
2) Een frame is slecht voor je SEO (zoekmachine vriendelijkheid), is moeilijk te stijlen, haalt eigenlijk 2 pagina's uit elkaar terwijl het 1 pagina is en ga maar door. Frames werden gebruikt in 2000 nu, 12 jaar later, hebben we al veel betere methoden. Precies zoals je zou vragen 'waarom heb jij Windows 7? Waarom geen Microsoft DOS?' Dat is een wereld van verschil tussen technologie en iedereen weet dat Windows 7 beter is.
3) Dit is hetzelfde als met puntje 1. Een <br> tag geeft een break aan. Het is dus een enter. Een <p> tag staat voor paragraph, alinea. Het verschil is dus dat je tekst in een p element ziet als een alinea en tekst met 2x een break erachter zit als een losstaand niets betekend zinnetje.
Waar het dus op neerkomt, als ik iets code, heb ik bij bijv een <p> paragraaf </p> een beter overzicht omdat ik nu weet dat dit de kop van een paragraaf is ipv bij een <br><br> hoewel het uiteindelijk wel een beetje op hetzelfde neerkomt? behalve dan dat een <p> bold word?
Bedankt voor je vriendelijke en duidelijke antwoord, ben echt nog in de begin fase en lees tut over tut en doe cursus over curses om het te leren :)
Bedankt voor je vriendelijke en duidelijke antwoord, ben echt nog in de begin fase en lees tut over tut en doe cursus over curses om het te leren :)
Kobar, je schrijft HTML zodat een browser weet wat het is. Wij zien de pagina, door de stijlen zien wij wat belangrijk is en wat een titel is en wat juist niet belangrijk is.
Een browser is slechts een robot, het kan alleen de code bekijken. Als een browser dit krijgt:
Ziet een browser dit als 1 groot stuk tekst. Hij kan er niks mee.
Maar als je het zo ombouwt:
Ziet de browser er een titel en een alinea in, hij begrijpt waar je het over hebt en kan daaraan zijn stijlen aanpassen.
Ook is een zoekrobot (van google bijv.) veel geïnterreseerder in het laatste script dan in de eerste, omdat hij ook alleen de code kan lezen. En hoe blijer je de zoekrobot maakt hoe hoger je in de resultaten staat.
Een browser is slechts een robot, het kan alleen de code bekijken. Als een browser dit krijgt:
Ziet een browser dit als 1 groot stuk tekst. Hij kan er niks mee.
Maar als je het zo ombouwt:
Code (php)
1
2
2
<h3>Hallo World</h3>
<p>Hallo, dit is mijn eerste HTML site, ik ben druk bezig met leren</p>
<p>Hallo, dit is mijn eerste HTML site, ik ben druk bezig met leren</p>
Ziet de browser er een titel en een alinea in, hij begrijpt waar je het over hebt en kan daaraan zijn stijlen aanpassen.
Ook is een zoekrobot (van google bijv.) veel geïnterreseerder in het laatste script dan in de eerste, omdat hij ook alleen de code kan lezen. En hoe blijer je de zoekrobot maakt hoe hoger je in de resultaten staat.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
Inhoudsopgave
- Leesbaarheid
- SQL-injection
- XSS-injection
- Gebruik van backticks in MySQL
- Correcte foutenafhandeling
- Geheugenefficiënt programmeren
- Slot


PHP hulp
0 seconden vanaf nu