Custodia Pascal o Camel Caring per codice C #?

Question

Ho discusso con i miei colleghi sull'involucro di Pascal (caso di cammello superiore) e inferiore CamelCasing . Sono usati per ridurre l'intelaiatura del cammello per qualsiasi cosa, dai nomi delle tabelle nei database SQL alla denominazione delle proprietà nel codice C #, ma mi piace meglio l'involucro Pascal, l'involucro inferiore del cammello per le variabili e l'involucro Pascal per le proprietà:

string firstName;
public string FirstName {
...
}

Ma sono abituati a questo:

string _firstname;
public string firstName {
...
}

Cerco di tenere il passo con il loro "standard" quindi il codice sembra lo stesso ma non mi piace.

Ho visto che almeno il framework .NET utilizza questa convenzione ed è così che provo a mantenere il mio codice, ad es .:

System.Console.WriteLine("string")

Cosa usi / preferisci e perché? Mi dispiace se qualcun altro ha posto questa domanda ma ho cercato e non ho trovato nulla.

Aggiornamento: Ho fornito un esempio di metodo e non una proprietà ma è la stessa. Come ho affermato nel primo paragrafo, i miei colleghi usano la convenzione Pascal per tutto (variabili, metodi, nomi di tabelle, ecc.)

Answer 1

Uso ciò che utilizza il Framework, in quanto è la migliore pratica di fatto. Tuttavia, fintanto che il codice nella tua azienda sta coerentemente usando il loro stile, allora ti conviene molto abituarti. Se ogni sviluppatore ha il proprio standard, allora non esiste alcun standard.

Answer 2

Un link alle linee guida di progettazione ufficiali Aiuto. In particolare, leggi la sezione Stili di capitalizzazione .

Nel grande schema delle cose, Pascal vs Camel non ha molta importanza e non è probabile che convincerai nessuno a tornare su una base di codice esistente solo per cambiare il caso dei nomi. La cosa veramente importante è che vuoi essere coerente all'interno di una data base di codice.

Sono felice solo se non usi l'ungherese.

Answer 3

Dovresti dare un'occhiata al nuovo strumento di Microsoft, StyleCop per controllare il codice sorgente C #. Tieni anche d'occhio FxCop per il controllo compilato. Assemblee nette. FxCop si concentra maggiormente sui dettagli di ciò che fa il codice, non sul layout, ma ha alcune regole di denominazione relative a nomi visibili pubblicamente.

StyleCop definisce uno standard di codifica, che ora viene promosso da Microsoft come standard di settore. Controlla il codice sorgente C # rispetto allo standard. StyleCop aderisce al tuo stile PascalCase.

Far entrare le persone su StyleCop (o qualsiasi altro standard del genere) può essere difficile, è piuttosto un ostacolo e StyleCop è abbastanza esaustivo. Ma il codice dovrebbe essere a uno standard uniforme - e uno standard personale è meglio di nessuno, lo standard aziendale è migliore di uno personale e uno standard del settore è il migliore di tutti.

È molto più facile convincere le persone all'avvio di un progetto: si sta formando un team e non esiste un codice esistente da convertire. E puoi mettere strumenti (FxCop, StyleCop) per interrompere la build se il codice non soddisfa gli standard.

Dovresti usare lo standard per il linguaggio e il framework - il codice SQL dovrebbe usare gli standard SQL e il codice C # dovrebbe usare gli standard C #.

Answer 4

Per le interfacce pubbliche è necessario attenersi al design del framework MS .NET linee guida: " Convenzioni di capitalizzazione " ;.

Per i membri non esposti, qualunque cosa tu e i tuoi colleghi siate d'accordo.

Answer 5

Io (e il mio team) preferisco riservare i capitali iniziali per i nomi delle classi.

Perché? Gli standard Java si stanno propagando, credo.

Answer 6

Da Guida per gli sviluppatori di .NET Framework Convenzioni di capitalizzazione , Case-Sensitivity:

  

Esistono le linee guida per la capitalizzazione   unicamente per facilitare gli identificatori   leggi e riconosci. L'involucro non può essere   usato come mezzo per evitare il nome   collisioni tra elementi della biblioteca.

     

Non dare per scontato che tutta la programmazione   le lingue fanno distinzione tra maiuscole e minuscole. Loro sono   non. I nomi non possono differire per caso   da solo.

Answer 7

Ho appena trovato Standard di codifica per .Net .

Answer 8

Il case Pascal dovrebbe essere usato per Proprietà. Per quanto riguarda i nomi variabili, alcune persone usano _ e alcune persone usano m_ e alcune persone usano semplicemente il vecchio involucro di cammello. Penso che fintanto che sei coerente qui, non dovrebbe importare.

Answer 9

Immagino che tu debba tollerare ciò che dice lo standard di codifica per il tuo posto di lavoro, per quanto personalmente non ti piaccia. Forse un giorno in futuro sarai in grado di dettare i tuoi standard di codifica.

Personalmente mi piace che i database utilizzino i nomi del modulo "nome_proprietà", "nome_base", ecc. per le tabelle e i campi, mentre l'equivalente del codice del modello di database sarebbe "nome_proprietà"; e "tankID". Non mi piace anche "quotare" e "; denominazione quando " fooName " è disponibile. Ma devo ripetere che questo è soggettivo e persone diverse avranno idee diverse su ciò che è buono e cattivo a causa della loro precedente esperienza e istruzione.

Answer 10

In realtà, non esiste un "quot" standard " convenzione su questo. C'è una linea guida modificata da Microsoft da qualche parte, e come con qualsiasi altra linea guida sulla convenzione di denominazione, sicuramente ce n'è un'altra che la smentisce, ma ecco cosa ho capito come "convenzione di alloggiamento C # standard".

1. PerWordCaps nei nomi dei tipi (classi, enumerazioni), costanti e proprietà.
2. camelCase per variabili locali molto lunghe e variabili protette / private
3. Nessun ALL_CAPS mai (beh, solo nel compilatore definisce, ma non nel tuo codice)
4. Sembra che alcune delle classi di sistema utilizzino nomi sottolineati (_name) per le variabili private, ma immagino che provenga dallo sfondo dello scrittore originale poiché la maggior parte di loro proviene direttamente dal C ++. Inoltre, nota che VB.NET non fa distinzione tra maiuscole e minuscole, quindi non saresti in grado di accedere alle variabili protette se estendi la classe.

In realtà, FxCop applicherà un alcune di queste regole, ma (AFAIK) ignora qualunque ortografia usi per le variabili locali.

Answer 11

Mi piacciono le convenzioni di codifica enunciate nelle Aardvark'd specifiche del progetto

Answer 12

Quell'esempio di .NET che hai pubblicato era una funzione. Lo "standard" adottato per metodi / funzioni è un caso di cammello con cappuccio (o Pascal, se vuoi chiamarlo così).

Mi attengo alla custodia del cammello dove posso. Ti consente di conoscere facilmente la differenza tra una variabile e un metodo.

Inoltre, sono un fan di applicare un carattere di sottolineatura davanti alle variabili di classe locali. Ad esempio: _localVar .

Answer 13

Il giorno in cui ho smesso di programmare, è quando Microsoft renderà CamelCase standard in C #. Perché la mia logica cresciuta ha molte ragioni per PascalCase, a differenza della logica dei bambini, a cui importa solo nomi più brevi o più facili da scrivere.

E a proposito: CamelCasing proviene principalmente dallo stile di libreria C ++ STD, il vecchio linguaggio nativo ereditato da C. Quindi Java ereditato da C ++. Ma C # - è un linguaggio completamente nuovo - pulito e bello, con nuove regole. I vecchi tag devono programmare su Java o C ++, le persone di nuova generazione devono programmare su C # e non devono mai interagire.

Considera questo esempio: 1) PascalCase: list.Capacity.ToString (); 2) CamelCase: list.capacity.toString ();

In (1) abbiamo CAMEL CASE a lungo termine !!! significa listCapacityToString. In (2) abbiamo cazzate: listcapacitytoString.

Ecco come ho letto. E perché CamelCase non è illogico per la sua idea. Potrei uccidere per PascalCase, non toccarlo mai, bambini di qualsiasi età.

Microsoft - per sempre o fino a quando non usano PascalCase.

Answer 14

Qualunque cosa tu preferisca è ciò che conta, ovviamente aderendo principalmente allo standard del team. In privato, il codice che desideri, non influisce sul prodotto finito, sia che tu abbia chiamato la variabile someVariable o SomeVariable.