Qual è una buona convenzione di denominazione per le variabili di funzione di ampio ambito?

Question

Puoi avere diverse convenzioni di denominazione per membri della classe, oggetti statici, oggetti globali e strutture. Alcuni esempi sono come di seguito.

_member
m_member

o nel caso Java, l'utilizzo di this.member .

Ma esiste una buona tecnica o convenzione di denominazione per l'ambito delle variabili di funzione che trasmette quando una singola variabile ha un ambito di funzione completo o un ambito di durata breve?

void MyFunction()
{
  int functionScopeVariable;

  if(true)
  {
    //no need for function variable scope naming convention
  }
}

Answer 1

Tendiamo a usare un prefisso l_ nelle nostre funzioni per " local. " E, ha funzionato abbastanza bene.

Answer 2

In realtà incoraggio a delegare questa attività all'IDE / editor che usi.

No, in realtà non sto parlando di variabili di denominazione, che è ancora meglio fatto da un essere umano. Ma il compito fondamentale di tali strategie di denominazione è mostrarti quale tipo di variabile rappresenta un nome.

Praticamente ogni IDE degno di nota può definire stili diversi (colori, caratteri, tipi di carattere, ...) a diversi tipi di variabili (membro di istanza, membro statico, argomento, variabile locale, ...) lasciando l'IDE dirti che tipo di variabile in realtà ti libera dal dover digitare quelle (altrimenti inutili) pre o suffissi ogni volta.

Quindi il mio consiglio: usa nomi significativi senza prefisso o suffisso.

Answer 3

Un metodo consiste nel seguire la linea guida secondo cui maggiore è l'ambito della variabile, più lungo è il nome. In questo modo, le variabili globali ottengono nomi descrittivi lunghi mentre le cose limitate dall'ambito come la variabile indice del ciclo possono essere piccole come singole lettere.

Answer 4

Uso prefissi o convenzioni di denominazione speciali su variabili globali, statiche e dei membri, quindi non devo usare prefissi sui locali. Preferisco avere la possibilità di utilizzare nomi di variabili locali brevi, in particolare per le variabili di ciclo.

Answer 5

C'è un argomento secondo cui non dovresti avere "funzioni di ambito di grandi dimensioni", quindi non ci dovrebbero essere problemi con la denominazione, basta usare le convenzioni di denominazione delle variabili "funzione di ambito piccolo".

Answer 6

La guida di MSFT e altre guide di stile per i campi di istanze private è _memberName (notazione del caso cammello con il prefisso " _ " ). Questa è anche la convenzione utilizzata nel codice sorgente di molti tutorial Microsoft recenti.

Lo uso perché è più corto, non ungherese, e R # lo supporta come regola predefinita per i campi di istanze private.

Mi piace anche perché in qualche modo oscura i campi privati ??da Intellisense, come dovrebbe, dal momento che dovresti preferire prima accedere ai tuoi membri pubblici. Se voglio accedere alla proprietà Nome e inizio a digitare " Na " il primo suggerimento è il nome della proprietà dell'istanza pubblica racchiuso in Pascal. Nei rari casi in cui desidero accedere direttamente al campo privato, ciò mi costringe a prendere una decisione consapevole di iniziare a digitare " _ " ;, quindi ottengo l'elenco completo dei miei campi privati ??in Intellisense apparire.

Ho anche visto una guida che dice che dovrebbe essere _MemberName se è il campo di supporto per una proprietà pubblica denominata MemberName (notazione del caso Pascal con il prefisso " _ ") Io personalmente non ' non mi piace perché penso che la M maiuscola sia ridondante, aggiunge sequenze di tasti non necessarie e non aggiunge alcuna informazione aggiuntiva.

Answer 7

Dipende tutto da ciò che le linee guida di stile per il linguaggio suggeriscono se ce ne sono.

Answer 8

Suppongo che tutto vada bene purché trasmetta il significato relativo al suo utilizzo.

Answer 9

Preferisco mantenerlo semplice, utilizzo:

 m_varname - Class member variables
 g_varname - Global variables

Answer 10

Uso la stessa convenzione che uso per i membri della classe. L'IDE dovrebbe occuparsi di trovare la tua dichiarazione. Se una funzione è così ampia e confusa da diventare un problema, c'è un problema più grande che deve essere l'indirizzo.