Gebruik van PSR's
Wanneer maak je hier (prive, zakelijk) gebruik van? Wat is de meerwaarde voor jou of jouw bedrijf?
Ben hier benieuwd naar, omdat de PSR's mij niet vanzelfsprekend lijken.
In een IDE zit een code formatter, bij autoloading is het gewoon handig om de namespace hetzelfde te hebben als je mapstructuur, en veel dingen gebruik je niet direct, zoals caching, serializable link interface definities.
Echter, werk je er uitsluitend zelf aan, dan heeft het (wat mij betreft) niet per se meerwaarde. Soms werken je eigen oplossingen prettiger, natuurlijker, handiger. Ik zou dan zeggen: hanteer je eigen oplossing.
Niet iedereen zal het hier overigens mee eens zijn, want er zijn ook leden die juist strak vasthouden aan de geldende conventies. Dat mag uiteraard, maar aan het eind van de rit is het een persoonlijke keuze.
Over conventies is vaak wel goed nagedacht, dus het is goed om ernaar te kijken en er wellicht iets van te leren. Maar persoonlijk zie ik het niet als 'verplichtingen'.
De PSR's lijken een beetje op standaardisatie van een algemene manier van werken voor (onderdelen van) verschillende raamwerken. Een soort ISO-light voor PHP frameworks. Maar zoals we al 5 jaar lang weten werkt niet alles hetzelfde.
Vandaar dat ik me afvraag hoe PSR's door mensen gebruikt worden om samenhang te creëren en uitwisselbaarheid van code en/of samenwerking tussen individuen/bedrijven te vergroten. Dat kan interessant zijn voor het aantrekken en behouden van grotere klanten, die behoefte hebben aan de veilige keuze dat er een grote organisatie achter de software staat.
Ik vond nog twee artikels over de PSR's:
https://phpthewrongway.com/#following-the-php-fig-standards-religiously
https://phptherightway.com/#code_style_guide
Maar ik blijf vooral benieuwd naar ervaringen van anderen.
Let op: Dit is mijn mening. Het is niet goed, fout of de beste manier, het is hoe ík dingen fijn vind werken.
Ik zie deze standaarden vooral als "best-practice guide", het zijn geen regels die in steen staan. Dat geld overigens ook voor design patterns (soms werkt je eigen oplossing gewoon beter dan "de standaard").
Wij maakten wel gebruik van PSR-1 en PSR-2 coding standards (PSR-2 is inmiddels vervangen).
Het voordeel van coding standards is dat alle sources er hetzelfde uit zien voor iedereen. Doe je dat niet dan word het een rotzooitje van verschillende stijlen (accolade op dezelfde regel of de volgende? inspringen met tabs of 4 spaties. of 6?, etc.)
Dit werd ook door een linter getrokken als Git pre-commit hook zodat je nooit code kon wijzigen in iets wat niet aan de standaard voldoet.
Omdat we gebruik maakten van ZendFramework/Apigility kregen we automagisch PSR-7 en PSR-0 en nog een paar die ik vergeet er bij (PSR-0 is ook vervangen).
Op dat moment is het gewoonweg simpeler om te voldoen aan de specificatie, dat maakt test-driven development (TDD) m.i. ook een stuk makkelijker omdat je duidelijke(re) kaders hebt.
De rest gebruik ik niet (bewust) en heb ik ook nog nooit doorgelezen.
Kortom:
- Ik vind de coding-standards fijn om toe te passen. Dat hoeft niet (exact) die van het PSR te zijn, zolang je het maar consistent toepast (en afdwingt in een team).
- Het is makkelijker om standaarden te gebruiken als die in je upstream code ook gebruikt worden. Waarom zelf prutsen als het standaard alles al voor je uitschrijft?
Wat van toepassing is op standaarden maar ook op composer-packages en designpatterns:
- Hergebruik wat al bestaat voor je zelf het wiel opnieuw gaat uitvinden.
- Gebruik het juiste gereedschap voor de juiste taak. Je hebt voor een portfolio-website niet een event-sourced CQRS applicatie nodig.
Ik gebruik verschillende PSR-standaarden en die kun je niet op één grote hoop vegen, omdat het tools met uiteenlopende functies zijn. Een hamer is geen zaag.
- PSR-1 en PSR-12 voor syntaxis;
- PSR-5 voor commentaar;
- PSR-4 voor autoloaders;
- PSR-3 voor loggers;
- PSR-6, PSR-11 en/of PSR-16 voor caches en andere storage;
- PSR-7, PSR-15, PSR-17 en PSR-18 voor HTTP.
De laatste categorie is, denk ik, de belangrijkste, omdat deze voorziet in interoperability met andere client/server-webapplicaties, waaronder guzzle en Drupal — en dus alles dat daarmee is gebouwd.