Gebruik van PSR's

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ad Fundum

Ad Fundum

19/01/2021 09:53:01
Quote Anchor link
Velen kennen wel coding standards voor PHP, de PSR's van de PHP Framework Interop Group.

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.
 
PHP hulp

PHP hulp

19/03/2024 04:08:31
 
Ozzie PHP

Ozzie PHP

19/01/2021 11:33:30
Quote Anchor link
Ik denk dat het er vanaf hangt wie jouw code gebruikt. Zou je bijv. internationaal werken, of werken verschillende bedrijven aan jouw code, dan kunnen conventies handig zijn.

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'.
 
Ad Fundum

Ad Fundum

20/01/2021 07:22:44
Quote Anchor link
Bedankt voor je reactie Ozzie!

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.
Gewijzigd op 20/01/2021 07:46:48 door Ad Fundum
 
Thom nvt

Thom nvt

20/01/2021 08:34:27
Quote Anchor link
Bij mijn vorige werk als PHP developer (inmiddels al 2 jaar overgestapt op Cloud Engineer) gebruikten wij een deel van de PSR-standaarden.

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.
 
Ward van der Put
Moderator

Ward van der Put

20/01/2021 09:26:23
Quote Anchor link
Ook een standaard, of nadrukkelijker zélfs een standaard, is een tool. Gebruik de tools die je nodig hebt én gebruik ze goed, anders kun je beter gaan zoeken naar andere tools. A fool with a tool is still a fool.

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.