You may want to put some text here

Overzichtelijk leren programmeren in PHP

Wat ik jullie vandaag ga tonen is hoe je ordelijk en overzichtelijk kan programmeren in PHP. Om dit te doen moet je niet meer alleen aandacht besteden aan de werking van een script, maar ga je ook kijken naar de opbouw en consistentie in een script.

Vaak wordt dit aanzien als tijdsverlies maar dit is zeker niet het geval. Het zal je zelfs over een langere periode gezien tijd besparen en het zal aangenamer zijn om scripts die je een half jaar geleden gemaakt hebt te wijzigen of uit te breiden.

Consistentie van je script

Hiermee bedoel ik dat je consistent moet zijn in het gebruik van spaties, acolades en naamgevingen. Om even een voorbeeldje te geven van een niet cosistent script:

$MijnNaam = "Wim";
$leeftijd = "23";
echo "Mijn naam is $MijnNaam en ik ben " . $leeftijd . ' jaar oud.';

Op zich is er niet echt iets mis met dit script want het resultaat is:

Mijn naam is Wim en ik ben 23 jaar oud

en dit is ook wat we wilden bereiken echter is de consitentie hier ver te zoeken. De ene keer begint een variable naam met een kleine letter en dan weer met een grote letter. De ene keer wordt er een dubble acolade gebruikt, de andere keer een enkele. Een script dat op deze manier is opgebouwd is helemaal niet aangenaam om te wijzigen en je zal veel tijd verliezen omdat je constant zal moeten gaan kijken: hoe had ik die variable nu weer genoemd, omdat er helemaal geen logica in de naamgeving zit.

Zou het niet mooier en professioneler overkomen als we het script op deze manier schrijven:

$mijnnaam = "Wim";
$mijnleeftijd = "23";
echo "Mijn naam is " . $mijnnaam . " en ik ben " . $mijnleeftijd . " jaar oud.";

Dit script is meteen veel duidelijker en overzichtelijker. Dit komt doordat er consistentie in de naamgeving en het gebruik van acolades zit.

Stijl document

De bedoeling is dat je een klein documentje gaat maken met voorbeelden van hoe jouw scripts opgebouwd en gestructureerd zijn. Dit document ga je dan altijd gebruiken om je scripts te maken. Als je dan een script dat je een halfjaar geleden gemaakt hebt terug moet wijzigen dan zal dat geen probleem zijn want je weet meteen hoe deze opgebouwd is. Het document moet geen boek zijn van 200 pagina’s maar een korte beschrijving van wat regels. Een voorbeeldje van enkele regels die ik in mijn document heb staan zijn:

Variablen

  • Namen van variablen moeten volledig met kleine letters geschreven worden.
  • Spaties worden vervangen door een underscore(_).
  • Variables zoveel mogelijk bovenaan in het script declareren. Bijvoorbeeld $mijn_naam = “”;
  • Waarde aan een variable toekennen met een dubbele acolade.

Klasses

  • Private variable beginnen met een underscore en als eerste letter een kleine letter gevolgd door camelcase notatie.
    private $_totalScore = 0;
  • Protected variable beginnen met een kleine letter gevolgd door camelcase notatie.
  • Public variable beginnen met een hoofdletter gevolgd door camelcase notatie.
  • Private en protected methods(functies) beginnen met een kleine letter gevolgd door camelcase notatie.
  • Public methods beginnen met een hoofdletter gevolgd door camelcase notatie.

Na zo’n lijst van puntjes voeg ik ook nog eens enkele script voorbeelden toe aan mijn document. Hieronder zie je een voorbeeld van hoe ik mijn klasses altijd opbouw.

<?php

/**
 * Class beschrijving
 *
 * @author 		naam <email>
 * @copyright  		naam jaar
 * @license 		licensie
 * @version 		versienummer
 * @package 		Applicatienaam
 *
 */
class ClassName {

	/**
	 * Constructor
	 */
	public function __construct(){}

	/**
	 * Destructor
	 */
	public function __destruct(){}

	/********************* PROPERTY ********************/

	/**
	 * Omschrijving
	 *
	 * @access private
	 * @var type $_property
	 */
	private $_property;

	/********************* PRIVATE *********************/

	/**
	 * Function omschrijving
	 *
	 * @author 		naam <email>
	 * @access 		private
	 * @param 		type $parameter
	 * @return 		type
	 */
	private function privateMethod(){}

	/********************* PUBLIC **********************/

	/**
	 * Function omschrijving
	 *
	 * @author 		naam <email>
	 * @access 		public
	 * @param 		type $parameter
	 * @return 		type
	 */
	public function PublicMethod(){}

}

?>

Als je op deze manier altijd je klasses opbouwt dan ga je ook veel sneller bepaalde code vinden die je nodig hebt. Zo weet je als je opzoek bent naar een bepaalde private variable dat deze zich ergens in het midden van het script zal bevinden.

Boven elke method en variable zeg ik ook telkens waar deze voor dient en wat deze eventueel als parameters aaneemt. Ook geef ik aan wat de methods als type variable teruggeven. Zo weet je altijd wat je terug kan verwachten als je een bepaalde method aanroept.

Bij elke method vernoem ik ook wie deze heeft aangemaakt en zijn email adres. Als je dan in team werkt en je hebt een vraag over een bepaalde method weet je meteen bij wie je moet zijn voor vragen.

Het voordeel van dit type notatie is ook dat als je de Zend editor gebruit dat bij het aanroepen van een zelf geschreven classes , Zend ook aangeeft welke paramters je moet meegeven, en een beschrijving van de method en het return type. Zo moet je niet altijd gaan zien naar de method zelf wat je moet meegeven als parameters.

Hieronder zie je een voorbeeld van hoe de code aanvulling in de Zend editor eruit ziet van een klasse die ik volgens de bovenstaande stijl heb geschreven.


Door dat ik aan elke method een beschrijving meegeef krijg ik deze ook te zien bij het aanroepen van deze method in de editor.

Werken in team

Als je met een team aan één project wilt gaan werken dan moet je echt een stijl document maken. Doe je dit niet dan is het project gedoemd om een rommeltje te worden wat uiteindelijk zal gaan leiden tot fouten en dubbele code.

Heb je bijvoorbeeld al een stijl document dan kan je meteen in een team beginnen te programmeren. Je geeft iedere programmeur een examplaar van het document en iedereen zal volgens dezelfde stijl programmeren waardoor elke programmeur ook veel sneller veranderingen kan gaan maken aan code, ook al is deze door een ander teamlid geschreven.

Conclusie

Door gebruik te maken van een stijl document ga je heel wat bloed, zweet en tranen besparen tijdens het wijzigen van oudere code en het werken in team. Ik gebruik deze manier van werken nu ongeveer al een half jaar en ik zou niet meer zonder kunnen. Het moeilijkste zal in het begin zijn om je aan de regels van je eigen document te houden maar na een tijdje wordt het een gewoonte om op deze manier te werken.

Ik raad iedereen deze manier van werken ook aan voor het programmeren met andere talen zoals C#, C, Java enzoverder. Ik doe dit persoonlijk zelfs voor mijn CSS stylesheets.

The Author of this post is Wim Mostmans

Wim Mostmans heeft een eigen webontwikkeling bedrijf Sitebase waar hij voltijds voor werkt. Hij beheert ook nog enkele websites waaronder deze en een Computerforum. Blijf op de hoogte van waar Wim mee bezig is door hem te volgen op Twitter.

2 Responses »

  1. Bedankt voor de handige tips!

    Maar er staan wel ontzettend veel spelfouten in je stuk.

    Gr.

Leave a Comment