Clean php code & comments
Code (php)
1
2
3
4
5
2
3
4
5
if($var = 1){
return 100;
}else{
return 200;
}
return 100;
}else{
return 200;
}
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
if($var = 1)
{
return 100;
}
else
{
return 200;
}
{
return 100;
}
else
{
return 200;
}
Code (php)
1
2
3
4
2
3
4
if($var = 1)
return 100;
else
return 200;
return 100;
else
return 200;
Code (php)
1
($var = Y) ? 100 : 200;
Ook qua "comments" schrijven is er nog wat verwarring langs mijn kant. Ik zag bijvoorbeeld programmeurs bepaalde comment blokken schrijven met heel wat *'s en /'s in één blok.
En ook over het schrijven van de query's kan wel het één en ander worden gezegd. Ik ga bijvoorbeeld zo te werk:
Code (php)
1
2
3
4
2
3
4
" SELECT c.id, c.name, s.name AS status
FROM campaign AS c
INNER JOIN campaign_status AS s ON c.status_id = s.id
WHERE archive = 'N'";
FROM campaign AS c
INNER JOIN campaign_status AS s ON c.status_id = s.id
WHERE archive = 'N'";
Maar dan net iets netter onder elkaar geschreven (lukt niet goed met de code tags).
Is er ergens op het web een pagina te vinden waar dit thema aan bod komt? Of is er iemand die z'n eigen stramien wat uit kan leggen? Alvast bedankt!
Gewijzigd op 07/12/2012 09:02:57 door Sam Clauw
Welke je gebruikt is niet zo van belang. Wel belangrijk is dat je consequent die standaard blijft gebruiken. Bovenstaande voorbeeld van het gebruik van if statements zou je dus niet moeten kunnen geven. Kies een standaard en blijf erbij. Dat is niet overigens niet voor 'het nu', maar 'de toekomst'. Als je over een jaar of wat nog eens de code bekijkt wil je hetzelfde zien als dat je dan aan het schrijven bent. Dat leest makkelijker en helpt je begrijpen wat er staat.
Wat betreft commentaar zie je voornamelijk dat mensen de phpdoc standaards aanhouden. Grofweg is dat het volgende:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
/**
* Some test function description
* @param int $a
* @param int $b
* @return int
*/
function test( $a, $b ){
//do something with $a and $b
$c = $a + $b;
//return the value
return $c;
}
?>
/**
* Some test function description
* @param int $a
* @param int $b
* @return int
*/
function test( $a, $b ){
//do something with $a and $b
$c = $a + $b;
//return the value
return $c;
}
?>
Waarbij de @param en @return speciale identifiers zijn die bij het parsen van een phpdoc automatisch worden verwerkt. Inmiddels is dit zo veel gebruikt, dat veel mensen (ik ook) deze stijl gebruiken zonder verder echt gebruik te maken van phpdoc.
Bij commentaar is uniformiteit net zo belangrijk, misschien nog wel belangrijker. Goed commentaar, waarbij het omschrijvings blok aangeeft wat de functie doet en in de functie iedere commentaar regel extra uitleg geeft bij een paar regels code, is nog veel belangrijker om code te snappen dan de code zelf.
Overigens zijn de extra regels commentaar die ik nu als voorbeeld heb gebruikt niet echt goed. Wat je wilt in die regels is niet simpel herhalen wat er gebeurt, maar voornamelijk waarom het gebeurt. Commentaar moet extra informatie geven of iets duidelijker maken, niet simpelweg vertellen wat je ook direct in de code kan zien. In dit simpele voorbeeld was dat echter wat lastig....
Gewijzigd op 07/12/2012 09:22:11 door Erwin H
Vooral dan dit:
Erwin H op 07/12/2012 09:21:42:
Welke je gebruikt is niet zo van belang. Wel belangrijk is dat je consequent die standaard blijft gebruiken.
Behalve dat ik graag een spatie zie tussen ) en { op lijn 8 :)
@ TS:
Bij mij wordt dat dus
Ik werk graag volgens de drupal code standards ( http://drupal.org/coding-standards )
Wat indenteren betreft:
De sluitende accolade bevindt zich precies onde de plek waar het commando begon.
Dus de } staat nu onder de i van if.
Trouwens: if($var = 1) zal altijd 1 en dus true geven.
Gewijzigd op 07/12/2012 10:31:49 door Kris Peeters
Deze Group heeft 3 PHP standards gemaakt, deze wijzen voor hoe je code schrijft. Deze PSR standaards kun je hier vinden: https://github.com/php-fig/fig-standards/tree/master/accepted
Ik heb ook eens wat op een rijtje gezet: https://gist.github.com/3923547 En ik ben bezig met een heel groot document waar je al mijn 'standards' kunt lezen.
Het kiezen in welke standaard je script is een zeer persoonlijke keuze (en als je gaat meewerken in groten projecten of binnen een bedrijf moet je je aan die standaard houden). Wel is het goed je altijd te houden aan de zelfde standaard, consistentie is de key tot overzichtelijke code.