Standard di codifica .NET / C # consigliati? [chiuso]

Quali standard di codifica pensi siano importanti per i progetti .NET / C #? Potrebbe trattarsi di qualsiasi cosa trattando le parentesi graffe e la spaziatura e la pedanteria del genere. Oppure potrebbero essere domande più fondamentali come ad esempio quali spazi dei nomi in .NET Framework evitare, best practice con i file di configurazione, ecc.

Cerca di evitare di creare un post che è semplicemente il corollario di un altro. Ad esempio, sarebbe bene avere un post incentrato su parentesi graffe. Non abbiamo bisogno di due per supportare uno stile rispetto all'altro. L'idea non è quella di votare per il vostro standard per animali domestici, ma piuttosto di dare forma a ciò che dovrebbe essere pensato durante la creazione di standard.

Ecco la guida ufficiale di Microsoft sugli standard di codifica per .NET Framework versione 4.0.

Se vuoi la versione precedente per 1.1, prova qui .

Non seguo necessariamente questo fino a una "T", come si suol dire. Tuttavia, in caso di dubbio, questo è il posto migliore per iniziare a essere coerente con l'attuale framework .NET, che lo rende più facile per tutti, indipendentemente dal fatto che siano nuovi o meno per il tuo particolare progetto.

Potrebbe voler dare un'occhiata a StyleCop . Puoi persino incorporarlo in alcuni sistemi di build in modo che gli errori di stile interrompano la build. Le impostazioni predefinite sono per lo più congruenti con ciò che la SM suggerisce per le linee guida (come pubblicato da altri).

Puoi anche modificare le regole di default.

Linee guida da Microsoft:

• .NET - http://msdn.microsoft.com/en-us/library/czefa0ke.aspx
• C # - http://blogs.msdn.com/brada/articles/361363.aspx

Lo abbiamo adottato nel nostro ufficio. È scritto da Lance Hunt ed è abbastanza completo:

http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx

Inizia con FxCop . Ti parlerà delle violazioni delle migliori pratiche nel tuo codice esistente.

Provo a scegliere un insieme comune di stili da varie fonti. Alcuni che non sono stati menzionati prima:

• la documentazione dalle Linee guida per la codifica C # - ultimo aggiornamento nel 2010
• IDesign C # Coding Standard - ultimo aggiornamento nel 2008
• Philips Healthcare - C # Coding Standard - ultimo aggiornamento nel 2009
• Manuale Encodo C # - ultimo aggiornamento nel 2009

Devo raccomandare gli standard resi disponibili da SSW (una società di consulenza australiana).

Non solo codifica, ma Project Management ecc ... Una risorsa incredibilmente preziosa.

http://www.ssw.com.au/ssw/standards/default.aspx

I metodi dovrebbero essere brevi

La maggior parte dei metodi dovrebbe usare la maggior parte dei campi in una classe.

Scegli bene i tuoi nomi.

Ad esempio, leggere il libro Clean Code

Sto usando le seguenti applicazioni per mantenere uno standard di codifica oltre alle regole del camelback, al nome del metodo e così via.

GhostDoc : aggiunge un commento generato automaticamente in cima a ciascun metodo. L'applicazione fornisce un buon riassunto iniziale del metodo. (gratuito)

http://submain.com/products/ghostdoc.aspx

Resharper - analisi del codice e refactoring http://www.jetbrains.com/resharper/

StyleCop - Come pulizia finale prima del check-in su TFS. (gratuito)

http://code.msdn.microsoft.com/sourceanalysis

Odio gli standard di codifica stabiliti, sono tutti preoccupati di dirti di non commettere alcuni errori stupidi o di dirti come formattare il tuo codice in un modo o nell'altro. Tutto ciò è banalità.

Voglio dire, ti diranno quanti spazi mettere tra gli operatori, come correggere le variabili, quali prefissi 'ungheresi' usare (es. _ Per i membri), consigli contrastanti (es. Non puoi chiamare una classe Cxyz ma devi chiama un'interfaccia Ixyz), come impaginare il tuo codice (metti la tua variabile in cima alla classe o in fondo)

Tutti sono inutili nel quadro generale.

Ciò che conta per scrivere codice efficace, mantenibile e leggibile non è mai menzionato in questi standard.

Ad esempio: metti le tue variabili in cima o in fondo alla tua classe? Bene, chi se ne frega: ciò che conta è se raggruppate le variabili per area funzionale. Ciò che conta (lo saprai se hai mai visto 20 variabili sparse per il luogo).

Ti dicono di mettere le parentesi graffe in determinati punti. Grande affare! Riesco a leggere il codice tra parentesi in stile K&R e ANSI, non importa. Ciò che conta è se tutte le classi di Windows sono differenziate in qualche modo (come essere suffisso con Form o Dlg o altro) in modo da poter vedere quali file contengono il codice della finestra e quali sono oggetti ordinari.

Roba del genere è molto più importante dei punti minori che normalmente contengono gli standard. Non so perché si siano sviluppati in questo modo, ma spesso sono solo un sacco di regole che ostacolano una codifica efficace e produttiva.

I miei standard cercano di concentrarsi maggiormente sull'organizzazione di codice e file. Abbiamo alcuni standard che si riferiscono a dove verranno trovati i file. Ad esempio, per i non sviluppatori i ragazzi possono guardare uno dei nostri progetti e raccogliere immediatamente i file di documentazione di cui hanno bisogno. Allo stesso modo, proviamo a strutturare il codice del progetto in modo simile ad altri progetti come pratico (nota: come pratico, non in un modo fortemente prescritto che potrebbe non essere appropriato in ogni momento) e fondamentalmente proviamo a fare delle linee guida standard che può essere modificato secondo necessità.

In breve: sono lì per aiutarci a lavorare insieme, non come un insieme di regole restrittive che devono sempre essere seguite.

Avvertenza: pragmatismo di seguito - La domanda sembra essere formulata per suscitare un dibattito sullo stile "corretto" di parentesi graffe, ecc. Non sopporto di perdere tempo con queste sciocchezze.

1. Installa ReSharper , lascia le impostazioni predefinite, fai quello che dice.

2. Profitto: tutti i membri del tuo team avranno lo stesso stile che sarà dannatamente vicino alle linee guida di Microsoft, deviando solo su alcuni punti in cui gli standard di Resharper riflettono ciò che è effettivamente più ampiamente utilizzato nel settore e sono (probabilmente) miglioramenti.

Meno tempo il tuo team impiega a creare e fare riferimento a qualche documento o libro enorme, o a dickering su curly bracese altre inanità, più codice verrà eseguito. ReSharper imporrà il nome e lo stile durante la digitazione. Fatto. End-of-dibattito. Nulla di cui discutere. Andare avanti.

Detto questo, una lettura del classico Code Complete , li aiuterà a comprendere la logica alla base degli standard di codifica e offrirà molti spunti utili per veicolare efficacemente il significato attraverso il codice, cosa che un documento standard o un programma di ispezione non possono fare.

Se vuoi intensificare ciò che il resharper può fare per te, aggiungi StyleCop con il plug-in StyleCop per ReSharper. Come accennato, ci saranno alcuni piccoli conflitti tra le linee guida MS e le impostazioni predefinite di ReSharper. Vorrei solo andare con ReSharper su quelli. Qualunque sia la parte che prendi, salva i risultati nel file di configurazione di ReSharper, condividili con il tuo team ed esegui.

(No, non sono uno shill a pagamento per ReSharper, sono solo un cliente felice. Oltre alle sue molte altre funzionalità, gestisce i problemi di stile di base in modo più conveniente rispetto a qualsiasi documento standard o sistema di revisione del codice - lasciando la potenza delle cose importanti .)