Che tipo di prefisso usi per le variabili membro?

https://stackoverflow.com/questions/111605

02-07-2019
|

Domanda

Senza dubbio, è essenziale per comprendere il codice fornire un prefisso alle variabili membro in modo che possano essere facilmente distinte da "normale". variabili.

Ma che tipo di prefisso usi?

Ho lavorato su progetti in cui abbiamo usato m_ come prefisso, su altri progetti abbiamo usato solo un trattino basso (che personalmente non mi piace, perché solo un trattino basso non è abbastanza dimostrativo).

Su un altro progetto abbiamo usato un lungo prefisso, che includeva anche il tipo di variabile. mul_ ad esempio è il prefisso di una m variabile di brace di tipo u non firmata l ong.

Ora fammi sapere che tipo di prefisso usi (e per favore forniscici una ragione).

EDIT: La maggior parte di voi sembra codificare senza prefissi speciali per le variabili membro! Dipende dalla lingua? In base alla mia esperienza, codice C ++ tende a utilizzare un trattino basso o m_ come prefisso per le variabili membro. E le altre lingue?

Soluzione

Senza dubbio, è essenziale per comprendere il codice fornire un prefisso alle variabili membro in modo che possano essere facilmente distinte da "normale". variabili.

Contesto questo reclamo. Non è minimamente necessario se si ha l'evidenziazione della sintassi decente. Un buon IDE può permetterti di scrivere il tuo codice in inglese leggibile e può mostrarti il ??tipo e l'ambito di un simbolo in altri modi. Eclipse fa un buon lavoro evidenziando le dichiarazioni e gli usi di un simbolo quando il punto di inserimento si trova su uno di essi.

Modifica, grazie slim: un buon evidenziatore di sintassi come Eclipse ti permetterà anche di usare testo in grassetto o corsivo, o cambiare del tutto i caratteri. Ad esempio, mi piace il corsivo per le cose statiche.

Un'altra modifica: pensala in questo modo; il tipo e l'ambito di una variabile sono informazioni secondarie. Dovrebbe essere disponibile e facile da scoprire, ma non gridare a te. Se usi prefissi come m_ o tipi come LPCSTR , questo diventa rumore, quando vuoi solo leggere le informazioni principali & # 8211; l'intento del codice.

Terza modifica: vale indipendentemente dalla lingua.

Altri suggerimenti

Non uso alcun prefisso. Se corro il rischio di mescolare variabili locali o parametri del metodo con i membri della classe, il metodo o la classe sono troppo lunghi e traggono vantaggio dalla scissione .

Questo (probabilmente) non solo rende il codice più leggibile e in qualche modo "fluido", ma soprattutto incoraggia classi e metodi ben strutturati . Alla fine, si riduce quindi a un problema completamente diverso rispetto al prefisso o al non prefisso dillema.

AGGIORNAMENTO: beh, il gusto e le preferenze cambiano, no ... Adesso uso il trattino basso come prefisso per le variabili membro poiché si è dimostrato utile nel riconoscere le variabili locali e dei membri nel lungo periodo. Soprattutto i nuovi membri del team a volte hanno difficoltà quando i due non sono facilmente riconoscibili.

Nessuno. Usavo il carattere di sottolineatura, ma ne ho parlato in un progetto in cui agli altri non piaceva e non l'ho perso. Un IDE decente o una memoria decente ti diranno cos'è una variabile membro e cosa no. Uno degli sviluppatori del nostro progetto insiste nel mettere " questo. & Quot; di fronte a ogni variabile membro e lo umorizziamo quando stiamo lavorando su aree di codice nominalmente "sue".

Solo trattino basso.

Nel mio caso, lo uso perché è quello che dice il documento sugli standard di codifica sul mio posto di lavoro. Tuttavia, non riesco a vedere il punto di aggiungere m_ o qualche cosa orribile ungherese all'inizio della variabile. Il "solo trattino basso" minimalista lo rende leggibile.

È più importante essere coerenti di ogni altra cosa, quindi scegli qualcosa su cui tu e i vostri compagni di squadra potete concordare e attenervi. E se la lingua in cui stai codificando ha una convenzione, dovresti cercare di attenervi. Niente è più confuso di una base di codice che segue una regola di prefisso in modo incoerente.

Per c ++, c'è un altro motivo per preferire m_ a _ oltre al fatto che _ a volte prefigura le parole chiave del compilatore. La m sta per variabile membro. Questo ti dà anche la possibilità di chiarire le ambiguità tra i locali e le altre classi di variabili, s_ per statico e g_ per globale (ma ovviamente non usare i globali).

Per quanto riguarda i commenti che l'IDE si prenderà sempre cura di te, l'IDE è davvero l'unico modo in cui stai guardando il tuo codice? Il tuo strumento diff ha lo stesso livello di qualità per l'hilighting della sintassi del tuo IDE? Che dire dello strumento di cronologia delle revisioni del controllo del codice sorgente? Non hai mai nemmeno cat file di un file sorgente sulla riga di comando? Gli IDE moderni sono fantastici strumenti di efficienza, ma il codice dovrebbe essere facile da leggere indipendentemente dal contesto in cui lo stai leggendo.

Preferisco usare questa parola chiave. Ciò significa this.data o this- > data invece di alcuni nomi dipendenti dalla comunità.

A causa:

con gli IDE di oggi digitando this. popup intellinsense
è ovvio per tutti senza conoscere i nomi definiti

Le variabili di prefisso BTW con lettere per indicare il loro tipo sono obsolete con buoni IDE e mi ricordano questo Articolo di Joel

Usiamo m_ e poi una notazione Simonyi leggermente modificata, proprio come Rob ha detto in una risposta precedente. Quindi, il prefisso sembra utile e m_ non è troppo invadente e facilmente ricercabile.

Perché notazione? E perché non seguire (per .NET) le raccomandazioni sulla notazione di Microsoft che si basano sull'involucro dei nomi?

Prima domanda: come sottolineato, VB.NET è indifferente al case. Lo stesso vale per i database e (soprattutto) i DBA. Quando devo mantenere dritto l'ID cliente e l'ID cliente (ad esempio in C #), mi fa male al cervello. Quindi il case è una forma di notazione, ma non molto efficace.

La notazione con prefisso ha valore in diversi modi:

Aumenta la comprensione umana del codice senza usare l'IDE. Come nella revisione del codice - che inizialmente trovo ancora più facile da fare sulla carta.
Hai mai scritto T-SQL o altri proc memorizzati RDBMS? L'uso della notazione con prefisso sui nomi delle colonne del database è DAVVERO utile, specialmente per quelli a cui piace usare gli editor di testo per questo tipo di cose.

Forse in breve, il prefisso come forma di notazione è utile perché ci sono ancora ambienti di sviluppo in cui gli IDE intelligenti non sono disponibili. Pensa all'IDE (uno strumento software) che ci consente alcune scorciatoie (come la digitazione intellisense), ma non comprende l'intero ambiente di sviluppo.

Un IDE è un ambiente di sviluppo integrato nello stesso modo in cui un'automobile è una rete di trasporto: solo una parte di un sistema più grande. Non voglio seguire un'auto " auto " convenzione come stare su strade segnalate, quando a volte è più veloce solo per camminare attraverso un terreno libero. Affidarsi all'IDE per tenere traccia della digitazione variabile sarebbe come avere bisogno del GPS dell'auto per attraversare il lotto libero. Meglio avere le conoscenze (anche se può essere strano avere " m_intCustomerID ") in una forma portatile piuttosto che correre di nuovo in macchina per ogni piccolo cambio di rotta.

Detto questo, la convenzione m_ o " questo " le convenzioni sono entrambe leggibili. Ci piace m_ perché è facilmente ricercabile e consente comunque alla digitazione variabile di seguirlo. Ha convenuto che un carattere di sottolineatura semplice viene utilizzato da troppe altre attività del codice quadro.

Usando C #, sono passato dal prefisso "m _" a solo un carattere di sottolineatura , poiché "m_" è un'eredità da C ++ .

Le Linee guida ufficiali di Microsoft ti dicono di non usare alcun prefisso e di usare il caso di cammello su membri privati ?? e caso di pascal su membri pubblici . Il problema è che questo si scontra con un'altra linea guida della stessa fonte, che afferma che dovresti rendere tutto il codice compatibile con tutte le lingue utilizzate in .NET . Ad esempio, VB.NET non fa differenza tra involucri.

Quindi solo un trattino basso per me. Ciò consente inoltre di accedere facilmente tramite IntelliSense e il codice esterno che chiama solo i membri pubblici non deve vedere i caratteri di sottolineatura visivamente disordinati.

Aggiornamento: non credo che C # " questo. " -prefix aiuti il ??" Io. " in VB, che visualizzerà comunque "Me.age" lo stesso di " Me.Age " ;.

Dipende da quale framework sto usando! Se sto scrivendo un codice MFC, uso m_ e la notazione ungherese. Per altre cose (che tende ad essere STL / Boost) quindi aggiungo un suffisso di sottolineatura a tutte le variabili membro e non mi preoccupo della notazione ungherese.

Classe MFC

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

Classe STL

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

Ora questo può sembrare un po 'strano - due stili diversi - ma funziona per me e scrivere un sacco di codice MFC che non usa lo stesso stile dell'MFC stesso sembra brutto.

I prefisso le variabili membro con 'm' e i parametri (nella funzione) con 'p'. Quindi il codice sarà simile a:

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

Trovo che questo ti dica rapidamente l'ambito di base di qualsiasi variabile - se non c'è un prefisso, allora è un locale. Inoltre, quando leggi una funzione non devi pensare a ciò che viene passato e a ciò che è solo una variabile locale.

Dipende molto dalla lingua. Sono un tipo C ++ e prefissare tutto con trattino basso è un po 'complicato. Il linguaggio riserva elementi che iniziano con la sottolineatura per l'implementazione in alcuni casi (a seconda dell'ambito). C'è anche un trattamento speciale per il doppio trattino basso o il trattino basso seguito da una lettera maiuscola. Quindi dico solo di evitare quel casino e semplicemente scegliere qualche altro prefisso. 'm' è ok IMO. 'm_' è un po 'troppo, ma neanche terribile. Una questione di gusti davvero.

Ma fai attenzione a quei _leadingUnderscores. Rimarrai sorpreso da quanti interni di compilatore e librerie sono così chiamati, e c'è sicuramente spazio per incidenti e confusione se non stai estremamente attento. Basta dire di no.

Il più delle volte uso Python. Python richiede di utilizzare self.foo per accedere all'attributo foo dell'istanza della classe corrente. In questo modo, il problema di confondere variabili locali, parametri e attributi dell'istanza su cui lavori è risolto.
In generale, mi piace questo approccio, anche se non mi piace essere costretto a farlo. Quindi, il mio modo ideale per farlo è di non farlo e usare una qualche forma di accesso agli attributi su questo o su sé per recuperare le variabili membro. In questo modo, non devo ingombrare i nomi con metadati.

Se la lingua supporta la parola chiave this o Me , non utilizzare alcun prefisso e utilizzare invece tale parola chiave.

un altro trucco è convenzione di denominazione :

Tutte le variabili membro sono nominate come al solito, senza alcun prefisso (o 'this.' è normale farlo nel progetto)

Ma saranno facilmente differenziati dalla variabile locale perché nel mio progetto, quelle variabili locali sono sempre chiamate:

a Qualcosa: rappresenta un oggetto.
alcuni ManyThings: elenco di oggetti.
è AState o ha SomeThing: per lo stato booleano.

Qualsiasi variabile che non inizia con 'a', 'some' o 'is / has' è una variabile membro.

Dato che VB.NET non fa distinzione tra maiuscole e minuscole, aggiungo il prefisso alle variabili membro con un carattere di sottolineatura e cammello per il resto del nome. Scrivo in maiuscolo i nomi delle proprietà.

Dim _valueName As Integer

Public Property ValueName() As Integer

Sono con le persone che non usano i prefissi.

Gli IDE sono così buoni al giorno d'oggi, è facile trovare le informazioni su una variabile a colpo d'occhio dalla colorazione della sintassi, dalle descrizioni dei comandi del mouse e da una facile navigazione fino alla sua definizione.

Questo è in cima a ciò che puoi ottenere dal contesto delle variabili e delle convenzioni di denominazione (come lowerCamelCase per variabili locali e campi privati, UpperCamelCase per proprietà e metodi ecc.) e cose come " hasXXXX " e "isXX" per i booleani.

Non uso prefissi da anni, ma ero un "questo." prefisso mostro ma me ne sono andato a meno che non sia assolutamente necessario (grazie, Resharper).

Sono strano e prefisso le variabili membro con le iniziali dal nome della classe (che è racchiuso in un cammello).

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

La maggior parte delle persone di Delphi usa semplicemente F.

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

Un singolo _ utilizzato solo come indicatore visivo. (C #)

aiuta a raggruppare i membri con intellisense.
più facile individuare le variabili membro durante la lettura del codice.
più difficile nascondere una variabile membro con una definizione locale.

`_` anziché `questo.`

Uso anche _ invece di questo. perché è solo più corto ( 4 in meno) ed è un buon indicatore delle variabili membro. Inoltre, usando questo prefisso puoi evitare conflitti di denominazione. Esempio:

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}

Confronta con questo:

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}

Trovo il primo esempio più breve e più chiaro.

Dipende dal tipo di lingua in cui lavori.

In C # puoi fare riferimento a qualsiasi membro usando il prefisso "this", ad es. 'this.val', il che significa che non sono necessari prefissi. VB ha una capacità simile a "Me".

Nelle lingue in cui è presente una notazione integrata per indicare l'accesso dei membri, non vedo il punto nell'uso di un prefisso. In altre lingue, immagino abbia senso usare qualunque sia la convenzione comunemente accettata per quella lingua.

Nota che uno dei vantaggi dell'utilizzo di una notazione integrata è che puoi anche usarlo quando accedi a proprietà e metodi della classe senza compromettere le convenzioni di denominazione per quelle (che è particolarmente importante quando accedi a membri non privati) . Il motivo principale per l'utilizzo di qualsiasi tipo di indicatore è come una bandiera che stai causando possibili effetti collaterali nella classe, quindi è una buona idea averlo quando si usano altri membri, indipendentemente dal fatto che siano un campo / proprietà / metodo / ecc. .

Uso il caso del cammello e sottolineo come molti qui. Uso il trattino basso perché lavoro con C # e mi sono abituato a evitare la parola chiave "this" nei miei costruttori. Cammello sulle varianti con ambito metodologico, quindi il trattino basso mi ricorda con quale ambito sto lavorando in quel momento. Altrimenti non penso che importi finché non si tenta di aggiungere informazioni non necessarie che sono già evidenti nel codice.

Ho usato il prefisso m_ in C ++ ma in C # preferisco semplicemente usare il caso camel per il campo e il caso pascal per la sua proprietà.

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

Mi piace m_ ma fintanto che viene usata la convenzione nella base di codice, mi va bene.

Il tuo mul_ esempio si sta dirigendo verso la notazione ungherese delle app di Charles Simonyi.

Preferisco mantenere le cose semplici ed è per questo che mi piace usare m_ come prefisso.

In questo modo è molto più facile vedere dove devi andare per vedere la dichiarazione originale.

Tendo a usare m_ in C ++, ma non mi dispiacerebbe lasciarlo via in Java o C #. E dipende dallo standard di codifica. Per il codice legacy che ha una combinazione di trattino basso e m_ riforterei il codice su uno standard (data una dimensione del codice ragionevole)

Uso @.

: D j / k - ma se dipende dal tipo di lingua. Se ha getter / setter, di solito metto un _ davanti alla variabile del membro privato e il getter / setter avrà lo stesso nome senza il _. Altrimenti, di solito non ne uso nessuno.

Per i miei progetti uso _ come postfix (come notato sopra da Martin York, _ come prefisso è reserver dallo standard C / C ++ per le implementazioni del compilatore) e i quando lavoro su Progetti Symbian .

In Java, una convenzione comune è quella di prefigurare le variabili membro con " my " andUseCamelCaseForTheRestOfTheVariableName.

Nessuno se non necessario, sottolineatura singola in caso contrario. Si applica a Python.

Se è davvero necessario aggiungere un prefisso alle variabili membro, preferirei sicuramente m_ a solo un trattino basso. Trovo un carattere di sottolineatura di per sé riduce la leggibilità e può essere confuso con parole riservate in C ++.

Tuttavia, dubito che le variabili dei membri necessitino di una notazione speciale. Anche ignorando l'aiuto dell'IDE, non è ovvio il motivo per cui ci sarebbe confusione tra ciò che è un locale e ciò che è una variabile membro.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow

Che tipo di prefisso usi per le variabili membro?

_ anziché questo.

`_` anziché `questo.`