Best practice PHP: parametri di tipo
Ci sono le pratiche che apprendiamo a scuola, quelle che assumiamo per pigrizia, quelle che adottiamo per abitudine, sia a furia di vederle che copiando e incollando sistematicamente. Con il tempo e l'esperienza, è chiaro che stiamo cercando metodologie e sintassi sempre più chiare. Nonostante le tendenze che si distinguono attorno a ciascuna lingua, spesso siamo in grado di determinare leggendo il codice, quale del nostro team ha una tale sintassi In C #, i puristi prenderanno l'abitudine di iniziare tutte le loro interfacce con una "I" Ad esempio .
sommario
PHP, una sintassi libera… troppo libera?
Io stesso ho diverse abitudini che mi permettono di costruire il mio codice in modo regolare. Questo per orientarmi facilmente, per lavorare velocemente, ma anche per facilitare il debug e la lettura del mio codice per i miei colleghi.
Digita i suoi parametri, per cosa? E perché questa è una buona pratica?
In PHP, la sintassi è molto libera. Intendo molto libero dal fatto che il linguaggio non è molto prolisso. Senza essere un sostenitore di linguaggi come Java ad esempio, penso che digitarne i parametri non possa che aiutarci nel nostro lavoro.
Perché perdere tempo a scrivere il tipo di dati?
Sì, ma confrontiamo subito i pro ei contro.
Nei contro, senza essere brutti tempi, troverò difficile citare un altro argomento rispetto a quello che ho scritto sopra.
Tra i pro, potrei elencare un piccolo elenco:
- Mi aiuta a costruire il mio codice. Nel mio prototipo (dichiarazione della mia funzione), so che questo o quell'argomento deve essere un aRRay ou int.
- Questo mi permette di eseguire il debug più velocemente. Se hai dichiarato di volere un argomento di tipo Utente nel tuo metodo, PHP si aspetterà un'istanza utente. Oppure prova a dare una aRRay o qualsiasi altro tipo diverso da quello stipulato, causerà l'arresto immediato di PHP. Certo, l'errore rischia di essere abbastanza "duro", ma tutto il resto del tuo sviluppo non rischia di fallire.
- Ai miei colleghi piace leggere il mio codice come un libro. Infatti, quando sappiamo che il metodo setItem(…) accetta un argomento di tipo foo, aiuta. NO ?
12function setItem($articolo);function setItem(Foo $ oggetto);
Certo, questa lista contiene solo 3 punti, ma il nostro lavoro ci obbliga ad essere sempre sul sentiero di guerra e ad esplorare sempre nuove strade, vi consiglio di provare e vedere di persona.
Un problema sospeso con il tipo misto
In effetti, devo ammettere lo stesso una debolezza, il tipo misto. Ragazzo orribile e da bandire. Per coloro che hanno codificato in C/C++, è come dichiarare un puntatore di istanza con un (void *).
Vi consiglio il più possibile di non utilizzare questo tipo e di limitarne l'uso. Un esempio ?
Il metodo setPoireau(mixed $poireau) accetta i porri come parametri ma poiché non è digitato, puoi anche dargli un cucciolo di foca... Problematico.
Se volevi forzare ad avere i porri, sai cosa devi fare, e ammettiamo che hai una mente contorta, e che vorresti poter dare delle verdure, ti invito ad usare un'interfaccia (o un abstract di classe ) e definisci il tuo metodo in questo modo.
|
|
Sono d'accordo che questo esempio potrebbe non essere il migliore che ci sia, ma ha il merito di essere chiaro.
Conclusione
La dattilografia non è obbligatoria, ma rimane a disposizione di chiunque voglia lavorare in modo chiaro e pulito. Te lo consiglio vivamente.
Forse avremo il diritto, un giorno, di digitare il ritorno di un metodo che ci aiuti nella nostra ricerca di una semantica sempre migliore.