Sembra che ci sia un'opinione divisa su questo argomento, e volevo ottenere informazioni da persone sul fatto che abbiano trovato l'uso di prefissi e suffissi di sottolineatura per essere utili con la codifica o meno.
Sai, codice come questo:
class MyClass
{
private int _someInteger; // some advocate local vars prefixed with underscore
private void DoSomething(bool someBoolParam_) {...} // and params suffixed_...
}
Odio i rumori nel codice che semplicemente ribadiscono ciò che è o dovrebbe essere ovvio. Il rumore silenzioso come i caratteri di sottolineatura iniziali o finali è fastidioso. Il rumore che distrugge la leggibilità, come "m_x" o "xParam" o "getX" è peggio.
Se ci sono così tante variabili in ambito che non puoi ricordare quali sono locali e quali sono membri della classe, hai troppe variabili nell'ambito. O il metodo o la classe dovrebbero essere divisi. Probabilmente entrambi.
Il mio team C # usa il prefisso di sottolineatura per i membri privati, dato che funziona molto bene con Intellisense perché mentre si scrive codice è possibile digitare underscore e filtrare tutto tranne i membri privati.
Per il suffisso parametro, non ho mai visto quello stile in C #. In C #, i nomi dei parametri fanno parte della visibilità pubblica, quindi il suffisso sarà visibile anche al consumatore di classe. Lo stile discriminante tra la convenzione di denominazione dei parametri del metodo pubblico e privato lo renderà più confuso.
In .NET Framework, l'involucro Camel è raccomandato per il nome del parametro.
Da un punto di vista c / c ++
I caratteri di sottolineatura del prefisso sono sicuri solo con variabili minuscole, e anche allora i caratteri di sottolineatura double sono riservati
I suffissi su suffisso sono sempre sicuri, ma portano a costruzioni molto brutte come member_->pointer o member_[3]
Sono dell'opinione che le convenzioni di stile dovrebbero essere invocate per rendere chiara la natura di una cosa quando si nomina bene e applicare il principio del minimo stupore non è abbastanza.
Quindi in JavaScript, per esempio, le maiuscole ci aiutano con il seguente:
function plainOlFunction(){...
function ClassLikeConstructor(){...
Considero ragionevole l'uso di una convenzione perché le funzioni possono essere utilizzate come costrutti di tipo classe che costruiscono istanze o metodi. Conoscere l'intento immediatamente è utile.
Allo stesso modo in Java, C #, e presumo che le classi C ++ vengano capitalizzate in modo da conoscere la differenza tra:
SomeClass.someStaticMethod();
someInstance.someInstanceMethod();
La ragione per cui sono timido riguardo alle convenzioni di stile eccessive, tuttavia, è che molti sviluppatori li prendono come licenza per essere pigri sulla denominazione. Ho lavorato con il ragazzo i cui parametri sono stati tutti demarcati da p_ senza nome dopo che p_ ha superato più di 4 caratteri. E le sue funzioni sono iniziate con f_ , ecc ... Leggendo il suo codice potrebbe essere l'inferno. (difficile dare al ragazzo una brutta recensione del codice anche se da quando ha anche avviato la compagnia)
Quindi perché _somePrivateField ? Se ti trovi nella classe TransactionManager, dovrebbe essere abbastanza ovvio che transactions sarà un campo privato in cui sono archiviate tutte le transazioni. Potrebbe essere una var locale o una param ma l'uso e il contesto dovrebbero renderlo abbastanza chiaro.
Perché someParam_ ? Dovresti davvero sapere quali sono i parametri della funzione con cui hai a che fare, a meno che qualcuno non se ne sia andato e ne faccia troppi per ricordarlo facilmente (più di 4 lo spinge IMO). Quindi, in quel caso, la necessità dell'identificazione param è in realtà solo un attivatore dell'eccessivo uso del param in cui probabilmente le strutture dati dovrebbero essere entrate in gioco o ci fosse bisogno di più di un metodo.
Quindi questo?
function screwTheNextGuy(
p_ew,
p_bleah,
p_yuck,
p_ick,
p_why,
p_RUcRius,
p_ugh,
p_drlord,
p_noob,
p_nomore,
p_coderage
){...
o questo?
function makeTheNextGuyHappy( relatedSetOfValues, anotherSetOfValues ){...
Un'altra convenzione comune con cui non sono d'accordo separa in qualche modo i metodi dai non-metodi. Perché ne abbiamo bisogno quando la lingua parlata ci permette di distinguere il nome dal verbo? Abbiamo bisogno di un suggerimento per sapere se è pubblico o privato o dovrebbe essere di nuovo abbastanza ovvio dal punto di vista di qualsiasi cosa che non avresti bisogno di esporre come privato?
Più specificamente sul tema dei caratteri di sottolineatura, le cose importanti da controllare sono le convenzioni di qualunque lingua tu sia, perché esistono molte cose. Un singolo prefisso di sottolineatura è popolare per private vars ma anche per un file di tipo include e lo stesso si applica spesso a un oggetto che rappresenta quel file. In genere non toccherei mai i caratteri di sottolineatura doppia per uso comune, poiché rappresentano oggetti magici, costanti, nomi riservati, cose da fare e non so cos'altro. Principalmente li uso come separatori per indicare una convenzione di stile in primo luogo. Ad esempio, intendo $_jQueryObject anziché $phpDevWritingJavaScriptVarNames . Quindi sì come quello sciocco p_ ma con un vero nome a destra.
Il carattere di sottolineatura post-param è decisamente strano. Leggiamo da sinistra a destra in modo che in realtà sarebbe abbastanza facile perdere su una scansione veloce. Non lo userei se pensassi che fosse necessaria una convenzione di stile.
Come regola generale, penso che sia meglio usare le convenzioni di stile con parsimonia e fare in modo che quando stabilisci le convenzioni pensi al prossimo ragazzo quanto a te stesso perché nessuno dovrebbe ricordare cosa p_fg e% si supponeva chep_deo fosse alla linea 500 di un'enorme funzione con una dozzina di parametri. Il fatto che siano ovviamente parametri non è tanto utile quanto avere un'idea dei valori che detengono.
Leggi altre domande sui tag coding-style coding-standards