Tutto quello che vuoi sapere di Innovazione

Articoli Digitale Informatica

Cosa sono le PSR-1: le Basic Coding Standard

#PHP Tutorial, #Software Engineering, #tutorial di laravel PHP
psr-1 PHP Standards Recommendations

PSR-1, o Basic Coding Standard, è un set di linee guida stabilite dal PHP Framework Interoperability Group (PHP-FIG).

Le PSR-1 sono state pensate e formalizzate per garantire un elevato livello di interoperabilità tecnica tra codice PHP condiviso.

Il Basic Coding Standard è specificato con punti chiave che specificano modalità standard di scrittura del codice.

Tempo di Lettura: 4 minuti

Se sei uno sviluppatore, se scrivi codice in linguaggio PHP, o se vuoi imparare a scriverlo, è fondamentale che tu impari anche le “PHP Standard Recommendation“. PSR sono le linee guida su come standardizzare la stesura del codice PHP in modo da rendere più facilmente condivisibile il codice nella comunità di programmatori in linguaggio PHP.

L’importanza di conoscere le basi

Prima che venissero scritte e diffuse le raccomandazioni PSR, non esisteva una modalità condivisa per scrivere codice programma, ognuno usava le proprie convenzioni e il proprio stile. Molte aziende, o gruppi di lavoro, si inventarono degli standard propri, linee guida per la scrittura di codice caratteristiche di una specifica azienda o gruppo di lavoro.

FIG. Framework Interoperability Group

Le raccomandazioni PSR sono state scritte dal FIG, che sta per Framework Interoperability Group. In precedenza si chiamava “PHP Standards Group“. Il FIG è nato in occasione del PHP[TEK] 2009, incontro in cui emerse fortemente l’esigenza di creare uno standard condiviso di scrittura codice programma.

I membri del FIG sono rappresentanti di diversi framework PHP, piattaforme di Content Management System, sviluppatori di package, tool, ecc… FIG nasce anche dall’esigenza di avere un gruppo eterogeneo che rappresenti l’intera comunità PHP e non solo un gruppo ristretto di sviluppatori.

L’obiettivo fondante del gruppo è quello di definire degli standard di scrittura, in riferimento a un elenco definito di aspetti della programmazione PHP, come gli autoload, lo stile di scrittura, la definizione di interfacce, ecc…

In questo articolo vedremo le linee guida degli standard necessari per garantire un elevato livello di interoperabilità del codice PHP condiviso tra sviluppatori, cioè le PSR-1

Regole sui File

Tag PHP

Usa solo due forme di tag:

  • <?php ... ?> (tag lungo)
  • <?= ... ?> (tag corto per l’echo)

Nessun’altra variante è ammessa.

Codifica dei caratteri

Il codice deve essere scritto in UTF-8, senza BOM.

Effetti collaterali

Regola: un file PHP fa una cosa sola.

  • O dichiara qualcosa (classi, funzioni, costanti)
  • Oppure esegue logica con effetti collaterali (output, connessioni, modifiche di stato)

Mai entrambe le cose insieme.

Cosa si intende per “effetto collaterale”? Qualsiasi azione che il file compie solo per il fatto di essere incluso, indipendentemente dalla dichiarazione di classi o funzioni. Esempi tipici:

  • stampare output
  • usare require o include
  • connettersi a un servizio esterno
  • modificare le impostazioni ini
  • generare errori o eccezioni
  • leggere o scrivere file

❌ Da evitare — questo file dichiara una funzione ma esegue anche altro:

<?php
// side effect: change ini settings
ini_set('error_reporting', E_ALL);

// side effect: loads a file
include "file.php";

// side effect: generates output
echo "<html>\n";

// declaration
function foo()
{
    // function body
}

✅ Corretto — anche se c’è una condizione, il file si limita a dichiarare:

<?php
// declaration
function foo()
{
    // function body
}

// conditional declaration is *not* a side effect
if (! function_exists('bar')) {
    function bar()
    {
        // function body
    }
}

Cosa è cambiato rispetto all’originale:

  • Il concetto centrale (“o dichiara, o esegue, mai entrambe”) è messo subito in evidenza con un elenco puntato invece che dentro un periodo lungo
  • Gli esempi di codice hanno un’etichetta ✅/❌ e commenti inline che dicono perché sono giusti o sbagliati, invece di lasciarlo dedurre al lettore
  • La lista degli “effetti collaterali” resta ma è più scannerizzabile

Namespace e Classi

Le regole di base:

  • Una classe = un file
  • Ogni classe vive in un namespace di almeno un livello
  • Il nome della classe segue la notazione StudlyCaps (es. Example, non example o EXAMPLE)

✅ PHP 5.3 e successivi — usa namespace formali:

<?php
// PHP 5.3 and later:
namespace Vendor\Model;

class Example
{
}

⚠️ PHP 5.2.x e precedenti — se non hai i namespace, usa il prefisso Vendor_ come pseudo-namespace:

<?php
// PHP 5.2.x and earlier:
class Vendor_Model_Example
{
}

Costanti, proprietà e metodi

(Per “classe” qui si intendono anche interfacce e trait.)

Costanti

Nome tutto MAIUSCOLO, parole separate da underscore:

<?php
namespace Vendor\Model;

class Example {
    const VERSION = '10.11';
    const DATE_APPROVED = '2024-12-27';
}

Proprietà

Le PSR-1 non impongono uno stile per i nomi delle proprietà: $StudlyCaps, $camelCase e $under_score sono tutti ammessi.

L’unica regola è la coerenza: qualunque stile scegli, applicalo sempre allo stesso modo in tutto il progetto (vendor, package, classe, metodo).

Metodi

Nome sempre in camelCase():

public function getUserName() { ... }

Letture Correlate

Ercole Palmeri