Sui nomi delle funzioni custom in PHP
Venerdì 26 Giugno 2009 - 08:54
di Gabriele Romanato
Le convenzioni adottate nella scrittura del codice servono sostanzialmente ad aumentarne la leggibilità. Tuttavia, alcune convenzioni possono rendere difficile tale lettura se non usate in modo corretto. In PHP, una convenzione non scritta vuole che i nomi delle funzioni definite dal programmatore vengano scritte in lettere minuscole, usando un underscore per separare i componenti di un nome composto. Esempio:
function validate_form () {
//...
}
Il problema insito in questa convenzione è che anche le funzioni built-in del linguaggio seguono la medesima regola di scrittura. Quando il nostro codice diventa complesso, risulta quindi difficile identificare a colpo d’occhio le nostre funzioni personalizzate. Il problema diventa più evidente se lavoriamo in team e magari il nostro codice viene letto da uno sviluppatore che non ha ancora maturato una solida conoscenza delle funzioni built-in. La soluzione consiste nell’adottare una notazione camel case, come la seguente:
function validateForm () {
//...
}
In questo modo risulta più semplice indentificare a colpo d’occhio le funzioni custom distinguendole da quelle built-in. Questa convenzione è stata già adottata con successo in altri linguaggi, come JavaScript. Alla prossima!
Categoria: PHP e Open Source | Permalink
Commenti
1
Dipende…
Se si tratta di funzione normale utilizzo la notazione pascal_case, mentre per i metodi di classi uso il camelCase…
Lavorando principalmente ad oggetti, ed utilizzando classi “collezioni” con metodi statici per funzioni per conto loro, il problema di identificare le funzioni builtin da quelle mie praticamente non sussiste.In ogni caso si distinguono perché nel mio codice le funzioni hanno nomi descrittivi e non troncati, cosa che le varie funzioni builtin praticamente non hanno (strtr?)… :)
2
Magari pecco di presunzione, ma le funzioni php le riconosco al volo, non potrei recitarle tutte a memoria, ma quando ne vedo la riconosco :-)
3
Il punto non è tanto confondersi quanto definire in modo chiaro e comprensibile a tutti (dirigenti e project manager compresi) lo standard da adottare.
Io mi trovo molto bene quando il gruppo si siede un pomeriggio al tavolo e definisce le regole di scrittura del codice, quando ciò non accade è il caos.
4
imo quella notazione non serve per distinguere le funzioni da quelle builtin ( tutti gli editor php le evidenziano con un colore diverso ) ma proprio per aumentare la leggibilità e avere una notazione standard sia per i nomi delle variabili sia per le funzioni si usa quella
# - postato da Mario - 26 Giugno 2009 - 22:50
5
Ciao,
volevo farvi vedere il problema della leggibilità del codice da un altro punto di vista.L’uso dei DSL (Domain Specific Language).
I DSL sono delle estensioni del linguaggio , utilizzando sempre la sintassi del linguaggio, per definire meglio il problema che deve essere risolto dal programma.Faccio un esempio in ruby di un dsl per fare la ricerca di un volo e farsi ritornare un risultato:
result=search.for :flight do
from :milan
to : rome
at :date => “12/09/2009″, :time => ‘04:00′
with_carriers [:az,:lh]
endQuesto approccio permette diverse cose:
- non è più il programmatore che si deve adattare al linguaggio per risolvere il problema, ma è il linguaggio che viene esteso e adattato per descrivere meglio la problematica.
Praticamente creiamo l’ambiente più confortevole in modo che il programmatore abbia un linguaggio più vicino al dominio di risoluzione del problema.- Prima si parte definendo come dovrà essere il DSL, dopo di che si passa all’implementazione del linguaggio.
Questo permette di farsi una idea di quali problemi dovranno essere descritti, e permette anche al cliente di fargli vedere se il linguaggio si avvicina alle problematiche. (Solitamente il commitente ha più esperienza del programmatore nel campo dove lavora e in cui deve essere applicato il programma).- Avvicinandosi maggiormente al linguaggio naturale permette una maggiore facilità sia a programmatori che si avvicinano al nuovo programma, sia a chi a pochissima esperienza di linguaggi di programmazione.
Mi è capitato recentemente su una presentazione di jquery, dove c’erano sia programmatori server side che gente che fa solo html e css, di fare dei test presentando delle sequenze di comandi in jquery e chiedere a chi osservava cosa avrebbe fatto la sequenza di comandi.
E proprio chi faceva html ha saputo essere molto più bravo di programmatori classici a risolvere i test.
Questo perchè al di la di essere una libreria, jQuery è un DSL in javascript fatto apposta per risolvere problematiche nella manipolazione del DOM, ed usa un linguaggio che è molto vicino a chi lavora giornalmente con css e html.
E secondo me è dovuto proprio a questo il successo di questa libreria: essere riuscita ad avvicinarsi al linguaggio, al gergo, che ogni giorno chi fa html parla col computer# - postato da sasuke - 28 Giugno 2009 - 15:04
6
utilizzo entrambe le notazioni, specialmente la camel case
7
Concordo in pieno con sasuke ma aggiungo che non mi pare abbia centrato l’obiettivo dell’articolo proposto da Gabriele.
Voglio dire che in ogni caso un briefing prima di partire con un progetto in team ci vuole e questo anche per stabilire delle linee comuni di comportamento proprio sui nomi di funzioni/variabili/commenti eccetera, anche per le persone che arriveranno in un secondo tempo.
Io ho lavorato poco in team e mi spiace, perché quelle poche volte che l’ho fatto mi sono divertito; devo dire però che erano team di persone abbastanza omogenee dove non c’era il “professore” che comanda su tutti e non ti da lo spazio per esprimerti.
Quindi in poche parole, che lavori in team o da solo devi darti delle regole e soprattutto non iniziare a codificare come un pazzo senza sapere cosa stai facendo.m.
# - postato da Marco Grazia - 29 Giugno 2009 - 10:36
8
Grazie a tutti per i commenti. Lo scopo era sottolineare la necessità di convenzioni condivise. Lungi da me ogni diktat!
# - postato da Gabriele Romanato - 29 Giugno 2009 - 12:33
9
si so che il mio commento non era proprio azzeccato col post.
Ma volevo proporre un punto di vista alternativo mi sembrava interessante.i DSL ad esempio sono usati anche in zend, grazie all’uso della chainability e dei method missing.
Parlo delle form e degli oggetti per gestire le tabelle# - postato da sasuke - 29 Giugno 2009 - 12:47
10
Interessantissimo il punto di vista di sasuke che mi ha fatto riflettere. Un simile approccio da parte di chi ha disegnato una libreria come JQuery fa si che il programmatore riesca ad immergersi molto più rapidamente nella “novità”. Almeno a me è successo così ^^ . Mentre per l’articolo di Gabriele, posso affermare che mi è capitato molto spesso di vedere tale apprioccio, ovvero il camelCase; probabilmente perchè viene utilizzato in moltissimi linguaggi dopo la venuta del messia (OOP :)
11
Mah, al giorno d’oggi si vedono piu programmatori che scrivono funzioni con nomi allucinanti per non far modificare il codice ad altri che programmatori che semplificano la struttura.
Cosa non si fa per ricattare le aziende per cui si lavora gh# - postato da Emanuele Graziano - 20 Ottobre 2009 - 20:01