Share
Due volte al mese, rivisitiamo alcuni dei post preferiti dei nostri lettori da tutta la storia di Nettuts+.
La leggibilità del codice è un argomento universale nel mondo della programmazione per computer. È una delle prime cose che impariamo come sviluppatori. Questo articolo illustrerà le quindici best practice più importanti quando si scrive codice leggibile.
Gli IDE (Integrated Development Environment) hanno fatto molta strada negli ultimi anni. Ciò ha reso il commento del tuo codice più utile che mai. Seguire determinati standard nei tuoi commenti consente agli IDE e ad altri strumenti di utilizzarli in modi diversi.
Considera questo esempio:
I commenti che ho aggiunto alla definizione della funzione possono essere visualizzati in anteprima ogni volta che utilizzo quella funzione, anche da altri file.
Ecco un altro esempio in cui chiamo una funzione da una libreria di terze parti:
In questi particolari esempi, il tipo di commento (o documentazione) utilizzato è basato su PHPDoc e l'IDE è Aptana.
Presumo che tu sappia già che dovresti indentare il tuo codice. Tuttavia, vale la pena notare che è una buona idea mantenere lo stile di indentazione coerente.
Ci sono più di un modo per indentare il codice.
function foo () if ($ maybe) do_it_now (); ancora(); else abort_mission (); finalize ();
function foo () if ($ maybe) do_it_now (); ancora(); else abort_mission (); finalize ();
function foo () if ($ maybe) do_it_now (); ancora(); else abort_mission (); finalize ();
Ho usato il codice nello stile n. 2 ma di recente sono passato al n. Ma questa è solo una questione di preferenza. Non esiste uno stile "migliore" che tutti dovrebbero seguire. In realtà, il miglior stile, è uno stile coerente. Se fai parte di una squadra o se contribuisci con il codice a un progetto, dovresti seguire lo stile esistente che viene utilizzato in quel progetto.
Gli stili di indentazione non sono sempre completamente distinti l'uno dall'altro. A volte, mescolano regole diverse. Ad esempio, in PEAR Coding Standards, la parentesi di apertura "" va sulla stessa linea delle strutture di controllo, ma vanno alla riga successiva dopo le definizioni delle funzioni.
Stile PERA:
function foo () // posizionato sulla riga successiva se ($ forse) // posizionato sulla stessa riga do_it_now (); ancora(); else abort_mission (); finalize ();
Si noti inoltre che stanno utilizzando quattro spazi invece di tabulazioni per i rientri.
Ecco un articolo di Wikipedia con esempi di stili di rientro diversi.
Commentare il tuo codice è fantastico; tuttavia, può essere esagerato o semplicemente essere ridondante. Prendi questo esempio:
// ottiene il codice paese $ country_code = get_country_code ($ _ SERVER ['REMOTE_ADDR']); // se il prefisso internazionale è USA se ($ country_code == 'US') // visualizza l'input del modulo per lo stato echo form_input_state ();
Quando il testo è così ovvio, non è davvero produttivo ripeterlo nei commenti.
Se devi commentare quel codice, puoi semplicemente combinarlo su una singola riga invece:
// mostra la selezione dello stato per gli utenti statunitensi $ country_code = get_country_code ($ _ SERVER ['REMOTE_ADDR']); if ($ country_code == 'US') echo form_input_state ();
Più spesso, alcune attività richiedono poche righe di codice. È una buona idea mantenere queste attività all'interno di blocchi di codice separati, con alcuni spazi tra di loro.
Ecco un esempio semplificato:
Accentsconagua
// ottiene l'elenco dei forum $ forums = array (); $ r = mysql_query ("ID, nome, descrizione FROM forum"); while ($ d = mysql_fetch_assoc ($ r)) $ forums [] = $ d; // carica i template load_template ('header'); load_template ( 'forum_list', $ forum); load_template ( 'piè di pagina'); L'aggiunta di un commento all'inizio di ogni blocco di codice sottolinea anche la separazione visiva.
Il PHP stesso a volte è colpevole di non seguire schemi di denominazione coerenti:
Prima di tutto, i nomi dovrebbero avere confini di parole. Ci sono due opzioni popolari:
Avere opzioni diverse crea una situazione simile agli stili di rientro, come ho detto prima. Se un progetto esistente segue una certa convenzione, dovresti farlo. Inoltre, alcune piattaforme linguistiche tendono a utilizzare un determinato schema di denominazione. Ad esempio, in Java, la maggior parte del codice usa i nomi di camelCase, mentre in PHP, la maggior parte degli usi sottolinea il sottotitolo.
Questi possono anche essere mescolati. Alcuni sviluppatori preferiscono utilizzare caratteri di sottolineatura per funzioni procedurali e nomi di classi, ma usano camelCase per i nomi dei metodi di classe:
class Foo_Bar public function someDummyMethod () function procedural_function_name ()
Quindi, di nuovo, non esiste un evidente stile "migliore". Essere coerenti.
DRY è l'acronimo di Do not Repeat Yourself. Conosciuto anche come DIE: Duplicazione è male.
Il principio afferma:
"Ogni pezzo di conoscenza deve avere una singola, non ambigua, autorevole rappresentazione all'interno di un sistema."
Lo scopo per la maggior parte delle applicazioni (o computer in generale) è di automatizzare le attività ripetitive. Questo principio dovrebbe essere mantenuto in tutto il codice, anche nelle applicazioni web. Lo stesso pezzo di codice non dovrebbe essere ripetuto più e più volte.
Ad esempio, la maggior parte delle applicazioni web consiste di molte pagine. È molto probabile che queste pagine conterranno elementi comuni. Intestazioni e piè di pagina sono di solito i migliori candidati per questo. Non è una buona idea tenere copia e incollare queste intestazioni e piè di pagina in ogni pagina. Ecco Jeffrey Way che spiega come creare modelli in CodeIgniter.
$ This-> load-> view ( 'include / header'); $ This-> load-> view ($ main_content); $ This-> load-> view ( 'include / piè di pagina');
Troppi livelli di nidificazione possono rendere il codice più difficile da leggere e seguire.
function do_stuff () //? if (is_writable ($ folder)) if ($ fp = fopen ($ file_path, 'w')) if ($ stuff = get_some_stuff ()) if (fwrite ($ fp, $ stuff)) //? else return false; else return false; else return false; else return false;
Per motivi di leggibilità, di solito è possibile apportare modifiche al codice per ridurre il livello di nidificazione:
function do_stuff () //? if (! is_writable ($ folder)) return false; if (! $ fp = fopen ($ file_path, 'w')) return false; if (! $ stuff = get_some_stuff ()) return false; if (fwrite ($ fp, $ stuff)) //? else return false;
I nostri occhi sono più a loro agio quando leggono colonne di testo alte e strette. Questo è esattamente il motivo per cui gli articoli di giornale assomigliano a questo:
È una buona pratica evitare di scrivere linee orizzontali lunghe di codice.
// bad $ my_email-> set_from ('[email protected] ') -> add_to ('[email protected]') -> set_subject ('Methods Chained') -> set_body ('Qualche messaggio lungo') -> inviare(); // good $ my_email -> set_from ('[email protected] ') -> add_to ('[email protected]') -> set_subject ('Methods Chained') -> set_body ('Qualche messaggio lungo') -> inviare(); // bad $ query = "ID SELECT, nome utente, first_name, last_name, stato FROM utenti LEFT JOIN user_posts USING (users.id, user_posts.user_id) WHERE post_id = '123'"; // good $ query = "ID SELECT, nome utente, first_name, last_name, stato FROM utenti LEFT JOIN user_posts USING (users.id, user_posts.user_id) WHERE post_id = '123'"; Inoltre, se qualcuno intende leggere il codice da una finestra di terminale, ad esempio gli utenti di Vim, è una buona idea limitare la lunghezza della linea a circa 80 caratteri.
Tecnicamente, è possibile scrivere un intero codice dell'applicazione in un singolo file. Ma quello si rivelerebbe un incubo da leggere e mantenere.
Durante i miei primi progetti di programmazione, ho saputo dell'idea di creare "include files". Tuttavia, non ero ancora nemmeno lontanamente organizzato. Ho creato una cartella "inc", con due file al suo interno: db.php e functions.php. Man mano che le applicazioni crescevano, anche il file delle funzioni diventava enorme e non mantenibile.
Uno degli approcci migliori è utilizzare uno schema o imitare la struttura delle cartelle. Ecco come appare CodeIgniter:
Normalmente, le variabili dovrebbero essere descrittive e contenere una o più parole. Ma questo non si applica necessariamente alle variabili temporanee. Possono essere più corti di un singolo personaggio.
È buona norma utilizzare nomi coerenti per le variabili temporanee che hanno lo stesso tipo di ruolo. Ecco alcuni esempi che uso di solito nel mio codice:
// $ i per i contatori di loop per ($ i = 0; $ i < 100; $i++) // $j for the nested loop counters for ($j = 0; $j < 100; $j++) // $ret for return variables function foo() $ret['bar'] = get_bar(); $ret['stuff'] = get_stuff(); return $ret; // $k and $v in foreach foreach ($some_array as $k => $ v) // $ q, $ r e $ d per mysql $ q = "SELECT * FROM table"; $ r = mysql_query ($ q); while ($ d = mysql_fetch_assocr ($ r)) // $ fp per i puntatori di file $ fp = fopen ('file.txt', 'w'); L'interazione con il database è una parte importante della maggior parte delle applicazioni web. Se stai scrivendo query SQL non elaborate, è una buona idea tenerle anche leggibili.
Anche se le parole speciali SQL e i nomi delle funzioni non fanno distinzione tra maiuscole e minuscole, è pratica comune capitalizzarle per distinguerle dai nomi delle tabelle e delle colonne.
SELEZIONA id, nome utente FROM utente; UPDATE utente SET last_login = NOW () WHERE id = '123' SELEZIONA id, nome utente DALL'utente u SINISTRA UNISCITI user_address ua ON (u.id = ua.user_id) WHERE ua.state = 'NY' GROUP BY u.id ORDER BY u.username LIMIT 0,20
Questo è un altro principio che si applica a quasi tutti i linguaggi di programmazione in tutti gli ambienti. Nel caso dello sviluppo web, il "dato" di solito implica l'output HTML.
Quando PHP è stato rilasciato per la prima volta molti anni fa, è stato visto principalmente come motore di template. Era comune avere grandi file HTML con poche righe di codice PHP in mezzo. Tuttavia, le cose sono cambiate nel corso degli anni e i siti web sono diventati sempre più dinamici e funzionali. Il codice è ora una parte enorme delle applicazioni Web e non è più una buona pratica combinarlo con l'HTML.
Puoi applicare il principio alla tua applicazione da solo oppure puoi utilizzare uno strumento di terze parti (motori di template, framework o CMS) e seguire le loro convenzioni.
Quadri PHP popolari:
Motori di modelli popolari:
Sistemi di gestione dei contenuti popolari
Puoi scegliere di non usare un motore di template di fantasia, e invece di usare semplicemente PHP inline nei tuoi file template. Ciò non viola necessariamente la "Separazione di codice e dati", purché il codice in linea sia direttamente correlato all'output e sia leggibile. In questo caso dovresti considerare l'utilizzo della sintassi alternativa per le strutture di controllo.
Ecco un esempio:
Ciao, nome utente; ?>
|La mia bacheca
titolo; ?>
Forum come $ forum):?>id, $ forum-> titolo)?> (Threads-> count (); ?> discussioni)
descrizione; ?>
Questo ti consente di evitare un sacco di parentesi graffe. Inoltre, il codice ha un aspetto simile al modo in cui l'HTML è strutturato e rientrato.
La programmazione orientata agli oggetti può aiutarti a creare un codice ben strutturato. Ma ciò non significa che devi abbandonare completamente la programmazione procedurale. In realtà la creazione di un mix di entrambi gli stili può essere buona.
Gli oggetti dovrebbero essere usati per rappresentare i dati, di solito residenti in un database.
class User public $ username; pubblico $ first_name; public $ last_name; pubblico $ email; funzione pubblica __construct () //? public function create () //? public function save () //? public function delete () //?
Le funzioni procedurali possono essere utilizzate per compiti specifici che possono essere eseguiti indipendentemente.
function capitalize ($ string) $ ret = strtoupper ($ string [0]); $ ret. = strtolower (substr ($ string, 1)); return $ ret;
I progetti Open Source sono costruiti con l'input di molti sviluppatori. Questi progetti devono mantenere un alto livello di leggibilità del codice in modo che il team possa lavorare insieme nel modo più efficiente possibile. Pertanto, è una buona idea sfogliare il codice sorgente di questi progetti per osservare cosa stanno facendo questi sviluppatori.
Quando si "refactoring", si apportano modifiche al codice senza modificare alcuna delle sue funzionalità. Puoi pensarlo come un "ripulire", al fine di migliorare la leggibilità e la qualità.
Questo non include correzioni di bug o l'aggiunta di nuove funzionalità. Potresti refactoring il codice che hai scritto il giorno prima, mentre è ancora fresco nella tua testa, in modo che sia più leggibile e riutilizzabile quando potresti potenzialmente vederlo tra due mesi. Come dice il motto: "Refactor presto, refactoring spesso".
È possibile applicare una qualsiasi delle "migliori pratiche" di leggibilità del codice durante il processo di refactoring.
Spero che questo articolo ti sia piaciuto! Qualche cosa che ho perso? Fammi sapere tramite i commenti. E se vuoi migliorare la tua codifica, ci sono molti script e app disponibili per aiutarti su Envato Market. Guarda cosa è più popolare questa settimana.
