Qual è la procedura migliore per denominare metodi privati ​​e statici privati ​​in C#?

Question

Sto cercando di capire qual è il modo più intelligente per nominare metodi privati ​​e metodi statici privati ​​in C#.

Contesto: So che la procedura migliore per i membri privati ​​è prefisso-sottolinea + camelcase. Potresti discutere di questo con me, ma credimi ho visto abbastanza codice da professionisti che seguono questa convenzione, è lo standard del settore qualificato.

So anche che il caso pascal è lo standard del settore per i metodi pubblici. Ma ho visto una combinazione di nomi di stili di test (ad esempio method_must_return_false_occasionally) a caso pascal, camelcase e prefisso underscore + camelcase, per metodi statici privati ​​e privati.

Ma qual è lo stile migliore per la denominazione di metodi statici privati ​​e privati ​​in C#?

Se ci sono determinati stili che vengono utilizzati da alcuni metodi privati ​​e non da altri, posso capirlo, basta spiegare.

Grazie per la lettura.

Answer 1

Partenza del Naming Guidelines Microsoft e Brad Abram di Style Guide

Si dice che tutti i metodi dovrebbero essere PascalCase

public void DoWork() {} 
private void StillDoWork() {} 
private static void ContinueToDoWork() {} 

Answer 2

non so su standard di settore, ma usano involucro Pascal anche per i metodi privati ​​e I non fare distinzioni per i metodi statici.

Answer 3

Il naming guidelines per lo sviluppo di librerie di classi .NET non fa distinzioni tra l'utilizzo pubblico e privato e consiglia la causa Pascal per i metodi statici.

EDIT: La mia pratica personale è quella di utilizzare l'involucro Pascal per metodi e proprietà, camel per campi, parametri e variabili locali. Quando si fa riferimento a membri di istanze all'interno della classe, utilizzo this. per distinguere dai membri della classe e dai parametri quando necessario. Non ho idea se mi qualifico come "professionista hardcore", ma vengo pagato. :-)

EDIT 2: Da quando ho scritto questo originale, ho cambiato lavoro. Lo standard di codifica che seguiamo è diverso dai miei sentimenti personali e facciamo prefisso campi privati ​​con caratteri di sottolineatura. Ho anche iniziato a utilizzare ReSharper e i nostri standard (generalmente) seguono le regole predefinite. Trovo che posso facilmente vivere con i caratteri di sottolineatura. Io uso solo this quando assolutamente richiesto in quanto non si adatta ai nostri standard di codice. La coerenza supera la preferenza personale.

Answer 4

Una scelta è quella di utilizzare uno strumento che impone di essere coerente, ad esempio style cop (se si utilizza reSharper, esiste un plug-in per il cop di stile su codeplex). La maggior parte degli strumenti sembra far rispettare (? Suggerire) le linee guida di Microsoft in quanto consentono di ottenere alcuni test per ottenere l'approvazione della piattaforma MS del proprio codice.

Answer 5

Ogni luogo in cui ho lavorato lo ha sempre fatto in modo diverso.

Ritengo che, in qualità di sviluppatore professionista, parte del professionista riguardi l'inserimento in nuovi team, che potrebbero avere convenzioni di codifica diverse.

Essere in grado di cambiare stile e affrontare la dissonanza cognitiva che questo crea nelle prime settimane, fa parte della professione.

Vorrei iniziare a considerare la varietà di progetti open source e simili e vedrete un'ampia varietà di schemi.

Ho anche visto il underscore casi di casi in cui CamelCase e Pascal dividono i comuni e talvolta i team, il che rappresenta il punto di uno schema di codifica.

Quindi, a meno che il progetto non sia un unico sviluppatore, nel qual caso sei libero, prova a scoprire cosa piace utilizzare il resto del team e cosa rende più facile la comprensione del team.

L'altra cosa che vorrei prendere in considerazione è la complessità del codice in termini OO se si tratta di un progetto semplice o di un progetto OO complesso con modelli multipli o si sta utilizzando un IOC, quindi si inizia a eseguire uno "spike" su tipi diversi di standard di codifica e poi guarda come appare fisicamente il codice quando lo stai usando - guarda bene a te e alla squadra o sembra brutto.

Answer 6

La convenzione weird_underscore_naming è tipicamente limitata ai test perché li rende più leggibili ed è fortemente incoraggiata da BDD. Ricorda che, mentre un metodo descrive in modo breve quello che fa (DepositMoney), i test devono descrivere quello che stanno facendo, cioè, Negative_deposits_must_be_caught