PSR-Duh!

In een vorige les hier over Nettuts +, leer je over PSR; In dit artikel is echter niet ingegaan op het integratieproces van die coderingsstijl in uw projecten. Laten we dat oplossen!

Notitie: dit artikel gaat ervan uit dat je PSR-Huh hebt gelezen en begrijp waar PSR naar verwijst. Laten we beginnen met de eerste standaard: PSR-0.

PSR-0 - De Autoloading-standaard

De PHPCS-plugin is de meest nuttige tool die ik heb gebruikt.

In het verleden hebben we PHP-bestanden op twee manieren opgenomen:

• Gebruik een gigantisch blok van include-statements bovenaan elk bestand.
• Lijst alles bevat in een enkel bestand en bevat dat ene bestand binnen uw project.

Er zijn voor- en nadelen aan beide benaderingen, maar ik denk dat we het er allemaal over eens zijn dat het evenmin optimale of moderne oplossingen zijn. PHP5 introduceerde het concept van autoloading-bestanden op basis van hun klassenamen; PSR-0 is dus bedoeld om bestandsnamen consistent te houden.

Namespaces hebben niets te maken met bestandsnamen of autoloading; je kunt technisch verschillende namespaces in hetzelfde bestand declareren. De volgende code is bijvoorbeeld perfect geldig.

  
Er zijn er twee Hallo klassen in dit ene bestand, maar ze bevinden zich binnen verschillende naamruimten. De laatste twee regels van deze code geven een instantie van de Hallo() klassen op hun respectieve naamruimten. De eerste uitgangen "Nettuts +", terwijl de tweede echo's "Gabriel." Met naamruimten kunt u onderscheid maken tussen twee klassen met dezelfde naam, net zoals u gewend bent met mappen op uw bureaublad. De PSR-0-standaard maakt eenvoudig gebruik van de voordelen van naamruimten, waardoor het eenvoudig is om uw klassen automatisch te laden. Door uw bestanden consequent een naam te geven, kunt u een functie maken die automatisch de benodigde bestanden opzoekt.
 
Om PSR-1 compliant te zijn, moet je ook PSR-0 volgen.
 
Zorg ervoor dat u de volledige standaard leest, maar om samen te vatten:
 
 
Elke klasse moet worden namespaced met de naam van het project (of maker).
 
Underscores binnen de klassennaam moeten worden geconverteerd naar directoryscheidingstekens.
 
Bestanden moeten de .php uitbreiding.
 
 
Een klasseverwijzing van bijvoorbeeld:
 
 \ Nettuts \ Database \ SQL_Postgres
 
als je PSR-0 volgt, moet dit naar dit pad worden vertaald:
 
 ./Nettuts/Database/SQL/Postgres.php
 
Hoe kunnen we deze functionaliteit implementeren? De meest voor de hand liggende oplossing is om Composer te gebruiken, die wordt geleverd met een PSR-0-compatibele autoloader. Als u Composer gebruikt in uw projecten (en dat zou u moeten doen), kies dan voor de autoloader in plaats van deze zelf te schrijven.
 
Met een lader die voldoet aan PSR-0 kunt u een basispad opgeven en de lader op de hoogte stellen in welke directory het eerst moet worden gekeken. Maak een eenvoudige om te beginnen composer.json bestand met de volgende JSON:
 
 "autoload": "psr-0": "Nettuts": "./", "Gmanricks": "vendor /"
 
Dit JSON-bestand vertelt Composer dat we de PSR-0-standaard willen gebruiken om alles automatisch te laden Nettuts-namespaced-bestanden met de huidige map (de hoofdmap) als het basispad. We willen ook alle klassen autoload met de Gmanricks naamruimte, ten opzichte van de verkoper map (bijv. ./ Verkoper / Gmanricks / ClassName).
 
Type nu "componist installeren"om autoload-klassen te genereren, of"componist dump-autoload"bij volgende bewerkingen om de autoload-klassen te regenereren. Vergeet ook niet om de autoloader ergens vroeg in uw project te vereisen.
 
  
Composer is je beste optie, maar er kunnen scenario's zijn wanneer je een kleine, eenvoudige autoloader wilt. De PHP-FIG biedt een voorbeeldautoloader die u kunt gebruiken:
 
 function __autoload ($ className) $ className = ltrim ($ className, '\\'); $ fileName = "; $ namespace ="; if ($ lastNsPos = strrpos ($ className, '\\')) $ namespace = substr ($ className, 0, $ lastNsPos); $ className = substr ($ className, $ lastNsPos + 1); $ fileName = str_replace ('\\', DIRECTORY_SEPARATOR, $ namespace). DIRECTORY_SEPARATOR;  $ fileName. = str_replace ('_', DIRECTORY_SEPARATOR, $ className). '.Php'; vereisen $ fileName; 
 
Het is belangrijk op te merken dat deze loader alle klassen probeert te laden met behulp van de PSR-standaard in de huidige map.
 
Nu we met succes klassen kunnen autoloaden, gaan we verder met de volgende standaard: de standaard coderingsnorm.
 
 
PSR-1 - De standaard voor standaard codering
 
PSR-1 definieert algemene coderingsrichtlijnen, die in twee delen kunnen worden verdeeld.
 
Naamconventies
 
Met naamruimten kunt u onderscheid maken tussen twee klassen met dezelfde naam.
 
Zoals met elke programmeertaal, maakt het volgen van naamconventies uiteindelijk het eenvoudiger om uw code te lezen en te onderhouden. Hier zijn een paar regels om te volgen:
 
 
Klasse namen gebruiken PascalCase.
 
Methodenamen moeten in staan camelCase.
 
Constanten vereisen alle hoofdletters, waarbij elk woord wordt gescheiden door een onderstrepingsteken (bijv. CONSTANT_VARIABLE).
 
 
Code conventies:
 
Er is meer aan de hand dan conventies benoemen; volg deze richtlijnen ook:
 
 
Alleen gebruiken  of  in uw code. Sluit PHP niet binnen een klas af.
 
Bestanden moeten symbolen aangeven of gebruiken.
 
Bestanden moeten in de indeling UTF-8 zijn zonder BOM voor PHP-code
 
 
De meeste hiervan spreken voor zichzelf, maar de middelste conventie is enigszins verwarrend. Het dicteert in wezen dat elke verklaring, of het nu gaat om functies, klassen, enz., Gescheiden moet worden in hun eigen bestanden. Dit bevordert niet alleen best practices zoals code-hergebruik en scheiding, maar het houdt uw code netjes en schoon.
 
Het is vermeldenswaard dat elke PSR-standaard voortbouwt op de vorige PSR-standaard. Als zodanig, om PSR-1 compliant te zijn, moet je ook PSR-0 volgen. Door deze twee standaarden te volgen, zal uw code correct namespaced en autoloaded zijn. Er is echt geen reden om ze niet te volgen.
 
Ja, sommige ontwikkelaars klagen over PSR en volgen liever andere conventies, maar door deze standaard te volgen, kunt u code met iedereen delen zonder u zorgen te maken over de consistentie ervan. Dat gezegd hebbende, niemand dwingt hier je hand. Het is gewoon een aanbevolen richtlijn.
 
De volgende standaard, PSR-2, duikt in op de details van hoe je je code moet structureren.
 
 
PSR-2 - De geavanceerde coderingsstandaard
 
PSR-2 duikt in de details van hoe u uw code moet structureren.
 
Vervolgens komen we tot de enige norm waar ontwikkelaars van PHP het meest mee worstelen; in feite is dit de reden waarom ik ervoor koos om dit artikel te schrijven.
 
PSR-2 definieert veel regels, waarvan er veel hieronder worden opgesomd:
 
 
Er moeten vier spaties worden gebruikt in plaats van tabbladen.
 
De ideale lengte van een regel moet minder dan 80 tekens lang zijn, maar een zachte limiet van 120 tekens moet op alle regels worden toegepast.
 
Er zou een lege regel moeten zijn onder de namespace en gebruik declaraties.
 
Een openingsbeugel van een methode of klasse moet op zijn eigen lijn staan.
 
De sluitbeugel van een methode of klasse moet direct na het lichaam op de lijn gaan.
 
Alle eigenschappen en methoden vereisen een zichtbaarheidsniveau.
 
De 'abstract'/'laatste'zoekwoorden moeten vóór de zichtbaarheid verschijnen'statisch'gaat na.
 
De trefwoorden van de controlestructuur moeten worden gevolgd door één spatie.
 
De openingsbrace van een controlecertificaat moet op dezelfde regel staan ​​als de instructie.
 
 
 
 Zorg ervoor dat u de volledige specificatie bekijkt voor een volledig overzicht. 
 
 
PSR-2 is net zo belangrijk als PSR-1 (en PSR-0). Het is van plan om de code gemakkelijk te kunnen lezen en onderhouden. Maar zoals ze zeggen, "De duivel is in de details."Er zijn veel details om te onthouden, wat moeilijk kan zijn als je programmeergewoonten verschillen van wat de standaard definieert. Gelukkig, als je aan boord bent, zijn er tools die je helpen om je te houden aan PSR-0, PSR-1 en PSR-2 Misschien is de beste tool de Sublime Text plug-in, PHPCS.
 
 
PHPCS - PHP Code Sniffer
 
De PHPCS-invoegtoepassing is de handigste tool die ik heb gebruikt om code in vorm te krijgen. Hiermee kunt u er niet alleen voor zorgen dat uw code voldoet aan de PSR-normen, maar wordt ook de linter van PHP gebruikt om te controleren op syntaxisfouten. Dit is een geweldige tijdsbesparing; u hoeft zich geen zorgen meer te maken over syntaxisfouten wanneer u uw code test in de browser.
 
Installeer het pakket via Sublime Package Control (het wordt Phpcs genoemd) of, als alternatief, met Git, met behulp van de volgende opdrachten:
 
 cd ~ / Bibliotheek / Toepassing \ Ondersteuning / Sublieme \ Tekst \ 2 / Pakketten / git clone git: //github.com/benmatselby/sublime-phpcs.git Phpcs
 
Hiermee installeer je de plug-in, maar je hebt een paar afhankelijkheden nodig voordat je PHPCS kunt configureren. Nogmaals, de gemakkelijkste manier om ze te installeren is met Composer. Blader naar een map van uw keuze en maak een composer.json bestand met de volgende JSON:
 
 "name": "Nettuts PHPCS Demo", "require": "squizlabs / php_codesniffer": "*", "fabpot / php-cs-fixer": "*", "phpmd / phpmd": "*" 
 
Hiermee installeert u de drie afhankelijkheden in de huidige map. Open een terminalvenster naar uw installatielocatie en typ componist installeren, en het zal de nodige pakketten downloaden.
 
Nu kunt u de plug-in in Sublime Text configureren. Navigeer naar 'Voorkeuren'> 'Pakketinstellingen'> 'PHP Code Sniffer'> 'Instellingen - Gebruiker'.
  
De plug-in moet weten waar de drie afhankelijkheden zich bevinden, evenals de norm waaraan we onze code willen houden:
 
 "phpcs_additional_args": "--standard": "PSR2", "-n": "", "phpcs_executable_path": "DEPENDENCY_PATH / vendor / bin / phpcs", "phpmd_executable_path": "DEPENDENCY_PATH / vendor / bin / phpmd "," php_cs_fixer_executable_path ":" DEPENDENCY_PATH / vendor / bin / php-cs-fixer "
 
Deze instellingen informeren PHPCS dat we de PSR2-standaard willen bereiken en het pad van elke afhankelijkheid willen bieden. Vergeet niet te vervangen DEPENDENCY_PATH met je eigenlijke pad.
 
Start Sublime opnieuw en de code sniffer scant uw code wanneer u uw PHP-bestanden opslaat.
  
Door met de rechtermuisknop in de editor te klikken, worden ook een aantal nieuwe opties weergegeven, zoals het wissen van foutmarkeringen en het proberen de niet-standaard problemen op te lossen. Gezien het punt van dit artikel echter is om u aan de standaard te laten wennen, stel ik voor om uw code handmatig te corrigeren en de automatische fixeerbad voorzien zijn van.
 
 
Conclusie
 
De PSR-standaarden zijn gemaakt zodat code gemakkelijk van project tot project kan worden hergebruikt, zonder in te boeten aan consistentie in codestijl. Hoewel ze in het begin misschien overweldigend lijken, kunt u de ideeën en hulpmiddelen van dit artikel gebruiken om u te helpen de overstap te maken.
 
Om nog een keer te herhalen: niemand dwingt je om de manier waarop je code in PHP verandert te veranderen. Het is gewoon een handleiding, oorspronkelijk bedoeld voor interoperabiliteit van het framework. Dat gezegd hebbende, bij Nettuts + vinden we het een goede gewoonte om te volgen. Maak nu je eigen mening! Als u vragen heeft, laten we ze hieronder horen!



		
			
	   
	




Code