PHP coding standard

Introduzione al coding standard in PHP

Transcript

1. PHP Coding standard e-xtrategy lab
2. Coding standard Linee guida per la scrittura del codice necessarie per garantire un alto livello di interoperabilità Fanno riferimento ad aspetti del codice quali: convenzioni sui nomi, organizzazione dei blocchi di codice, commenti, indentazione, strutture di controllo, ecc
3. Perchè ? • migliora la leggibilità • migliora la manutenibilità • aumenta l’interoperabilità (es: PSR-0) Questi aspetti sono molto importanti sia su progetti individuali che su progetti in team (opensource)
4. Come ? Viene definito un documento contenente tutte le regole da seguire Non importa cosa ci sia scritto nel documento, l’importante è che sia condiviso Le regole non vengono applicate dai compilatori quindi il software può funzionare anche senza l’applicazione del coding standard
5. Nel PHP ? Uno sviluppatore si trova spesso a dover scegliere e combinare framework e librerie in un singolo progetto. E’ importante che il codice PHP aderisca ad un coding standard che faciliti la vita a chi sviluppa Aderire ad un coding standard significa rendere più facile la vita dello sviluppatore
6. Nel PHP ? Il Framework Interop Group ha proposto e approvato una serie di linee guida conosciute come PSR-0, PSR-1, PSR-2 e PSR-3 (PHP Specification Request). Sono semplicemente delle linee guida che progetti importanti come Drupal, Zend, Symfony, CakePHP, phpBB, AWS SDK, FuelPHP, Lithium, ecc stanno adottando.
7. Nel PHP ? Dovremmo scrivere codice che aderisce ad uno dei principali coding standard definiti in PHP: • PSR-* • PEAR • ZEND
8. PSR-0 Descrive i requisiti necessari ai quali ci si deve uniformare per garantire l''interoperabilità tra gli autoloader Link al progetto su github
9. PSR-1 Definisce i requisiti base di coding standard per la scrittura del codice • Nei file si DEVONO usare soltanto le tag <?php o <?=. • I file DEVONO usare soltanto UTF-8 senza BOM per il codice PHP. • I file DOVREBBERO o dichiarare i simboli (classi, funzioni, costanti, etc.) o causare effetti collaterali (es. generare output, cambiare le impostazioni .ini, etc.) ma NON DOVREBBERO fare entrambe le cose. • I namespace e i nomi delle classi DEVONO seguire il PSR-0. • I nomi delle classi DEVONO essere dichiarati in StudlyCaps. • Le costanti di classe DEVONO essere dichiarate tutte maiuscole con underscore come separatore. • I nomi dei metodi DEVONO essere dichiarati in camelCase.
10. PSR-1 • non vengono imposti vincoli per i nomi delle proprietà. Qualsiasi sia la convenzione usata per i nomi, questa DOVREBBE essere applicata in modo consistente ad un livello ragionevole di visibilità. La visibilità potrebbe essere a livello di vendor, di pacchetto, di classe o di metodo Link al progetto su github
11. PSR-2 Estende il PSR-1 coding standard Ridurre l'attrito cognitivo quando il codice viene esaminato da diversi autori. Tutto questo è ottenuto grazie ad una serie di regole e aspettative condivise su come formattare il codice PHP.
12. PSR-2 • Il codice DEVE seguire il PSR-1. • Il codice DEVE usare 4 spazi per l'indentazione, non le tabulazioni. • NON DEVE esserci un limite rigido alla lunghezza della riga; il limite debole DEVE essere di 120 caratteri; le righe DOVREBBERO essere di 80 caratteri o meno. • DEVE esserci una riga vuota dopo la dichiarazione del namespace, e DEVE esserci una riga vuota dopo il blocco delle dichiarazioni use. • La graffa di apertura per le classi DEVE andare sulla riga seguente, e la graffa di chiusura DEVE andare su una nuova riga dopo il corpo. • La graffa di apertura per i metodi DEVE andare sulla riga seguente, e la graffa di chiusura DEVE andare su una nuova riga dopo il corpo. • La visibilità DEVE essere dichiarata su tutte le proprietà e i metodi; abstract e final DEVONO essere dichiarate prima della visibilità; static DEVE essere dichiarata dopo la visibilità. • Le keyword delle strutture di controllo DEVONO avere uno spazio a seguire (es: if (qualcosa) { .. } ); i metodi e le chiamate a funzioni NON DEVONO.
13. PSR-2 • La graffe di apertura per le strutture di controllo DEVONO andare sulla stessa riga, e le graffe di chiusura DEVONO andare su una nuova riga dopo il corpo. • Le parentesi di apertura per le strutture di controllo NON DEVONO avere uno spazio a seguire, e le parentesi di chiusura per le strutture di controllo NON DEVONO avere uno spazio a precedere. Link al progetto su github
14. PSR-3 Descrive un interfaccia comune per librerie di logging L’intento è quello di unificare operazioni di loggin sotto un interfaccia comune e condivisa tra librerie diverse Link al progetto su github
15. ..e Drupal ? Ha un suo coding standard utilizzato per il core, moduli contrib e moduli custom Basato sul coding standard di PEAR https://drupal.org/coding-standards
16. Link utili PRS-* Coding Standard Fixer : imposta il codice al livello PSR-* desiderato Code Sniffer : analizza i file sorgenti riportando eventuali violazioni dello standard. I coding standard di default sono PEAR, Zend. Permette di scrivere estensioni per analizzare il codice con altri standard.
17. Link utili Plugin Sublime text 2 per PSR-* Coding Standrd fixer PHPSTORM formatta di default il codice in PSR-1 PSR-2 Neatbeans si può configurare per il PSR-1 e PSR-2
18. Link utili Configurare netbeans per il drupal cs