Quale convenzione di denominazione utilizzare per i parametri di funzione C #

13

Ci sono situazioni in cui un nome passato in Parameter sarà Cast in un nuovo tipo, ma il nome dell'oggetto Passed dovrebbe rimanere simile. Per il caso di Attributi di classe, possiamo usare questo operatore, ma per quanto riguarda la variabile locale nelle funzioni. Quale convenzione di codifica è ampiamente utilizzata.

esempio,

void MyFunc(BaseClass myPara)
{
  DerivedClass _mypara = (BaseClass)myPara;
}

o al contrario

void MyFunc(BaseClass _myPara)
{
  DerivedClass mypara = (BaseClass)_myPara;
}

o qualsiasi altra convenzione

    
posta Shamim Hafiz 25.04.2011 - 11:23
fonte

6 risposte

11

Il prefisso di parametri o variabili locali con un carattere di sottolineatura non è molto idiomatico in C #, non è molto facile da leggere e non è spesso usato (anche se è legale, quindi sei libero di farlo se lo desideri).

Il nome migliore per il parametro e la variabile è un nome descrittivo. Devi pensare perché stai cambiando il tipo, qual è la ragione del cast. Quindi dovresti riuscire a trovare 2 nomi diversi. Per esempio. hai passato una "persona" e l'hai convertita in un "cliente", allora potresti usare la persona e / o il cliente nei nomi delle variabili, forse.

Se davvero non riesci a pensare a 2 nomi diversi, allora userei "as" nel nome ( c'era una domanda su questo sito pochi giorni fa su questo ). Per esempio. useresti "myParaAsDerived" per la variabile locale.

Se possibile non lo userei, penserei seriamente al problema che stai risolvendo e a quali nomi significativi potresti essere usato, ma se tutto il resto fallisce, questo è abbastanza leggibile.

    
risposta data 25.04.2011 - 11:30
fonte
9

Prima di usare

void MyFunc(BaseClass _myPara)
{
} 

È chiaramente sbagliato! come molti standard di codifica c # usano un prefisso "_" su tutti i nomi di campi ! Il codice deve essere facile da capire da un altro programmatore, quindi il codice non dovrebbe essere scritto in modo da ingannare molti programmatori C #.

Dati tutti i vantaggi dei piccoli metodi, io personalmente non vedo alcuna necessità di una convenzione di denominazione per separare le variabili locali dai parametri. Se i metodi hanno così tanti parametri e variabili locali che non puoi dire cosa sta succedendo senza una convenzione di denominazione, hai problemi più grandi. (Questo è ben trattato nel Clean Code Book , un libro in Java ma ho comunque trovato un grande vantaggio come programmatore C #)

    
risposta data 13.07.2011 - 10:21
fonte
4

Se vuoi prefissarli con qualcosa allora dovresti usare p_ per parametro: in generale credo che probabilmente faresti arrabbiare un sacco di persone se lo facessi. MA essere coerenti, non limitarti a farlo in un posto solo perché hai bisogno di due nomi diversi per le variabili a cui vuoi dare lo stesso nome.

Una buona regola generale con la denominazione delle variabili va come;

  • Se solo un tipo di oggetto lo chiama per la sua funzione:

    var builder = new PizzaBuilder();
    
  • Se hai più di un nome per la loro funzione e specializzazione:

    var pizzaBuilder = new PizzaBuilder();
    var milkShakeBuilder = new MilkShakeBuilder();
    
risposta data 25.04.2011 - 15:27
fonte
4

Le convenzioni di denominazione C # ti offriranno:

  • Uso di PascalCasing per metodi, proprietà pubbliche e nomi di classi
  • Uso di IPascalCasing (notare la I all'inizio) per i nomi di interfaccia
  • Uso di camelCasing per i parametri del metodo e le variabili locali
  • Uso di _underscoredCamelCasing per campi privati di classe

E per favore, stai lontano dalla notazione ungherese. È inutile e non aderisce alle convenzioni C #.

    
risposta data 13.07.2011 - 10:20
fonte
2

La sottovalutazione nella denominazione delle variabili può essere inutile dato che la parola chiave "this" fa riferimento in modo specifico alle variabili di livello di classe. Se vuoi saperne di più sulle convenzioni di denominazione delle variabili dagli esperti ti suggerisco di dare un'occhiata al famigerato articolo "Ottinger's Rules for Variable and Class Naming" di Tim Ottinger, un articolo supportato dal mentore di codice pulito Robert C. Martin .

Ottinger afferma che il tuo codice deve rimanere il più leggibile possibile, come una prosa ben scritta, quindi ...

public void Function(string p_Parameter1, string p_Parameter2)

... sarebbe più leggibile come ...

public void Function(string parameter1, string parameter2)

... dove parametro1 e 2 sono nomi descrittivi per le variabili corrispondenti.

Ecco il link, vale la pena dare un'occhiata: Link

    
risposta data 25.04.2011 - 21:13
fonte
-3

Credo nel suffisso dei parametri: stringa s_, int i_, ecc.

Credo anche che i nomi di parm dovrebbero essere brevi e generici il più possibile.

Ora per i motivi:

  • Nella funzione, non si desidera modificare il parametro in alcun modo, se è necessaria una versione modificata, creare una nuova variabile per inserirla. La denominazione dei parmi con un suffisso assicurerà che non li si assegni se presti attenzione.
  • Le eccezioni a questa regola arrivano quando il parm è ref o out. Anche se uso ancora il suffisso su quelli.
  • Perché nomi generici brevi? Dovresti documentare la tua funzione in modo da sapere che cosa è veramente nel senso descrittivo. In questo modo, l'utilizzo di brevi generici è utile quando si creano gruppi di funzioni simili o si ritaglia un corpo di una funzione per il trasporto su un'altra funzione come punto di partenza per la modifica.
  • Il vero vantaggio dei nomi generici è che non devi ricordare quello che hai chiamato quel parametro nella maggior parte dei casi. Sai che stai ottenendo una stringa, quindi il suo s_, ecc. E non devi chiederti se è 'nomefile' o era 'percorso file' o era 'percorso intero', è l'unica stringa in modo che sia 's _'.

Ogni cosa ha dei compromessi e se usi qualcosa dipenderà molto da come si adatta al tuo stile attuale.

    
risposta data 13.07.2011 - 09:58
fonte

Leggi altre domande sui tag