Ci sono suggerimenti per lo sviluppo di un documento sugli standard di codifica C # / sulle migliori pratiche? [chiuso]

Sono un neolaureato in AI (circa 2 anni) che lavora per un'operazione modesta. Mi è toccato (principalmente perché sono il primo 'adottante' nel dipartimento) a creare un documento standard di codifica C # di base (leggi utile?).

Penso che dovrei spiegare che probabilmente sono l'ingegnere del software più giovane, ma non vedo l'ora di fare questo compito, spero che potrei effettivamente essere in grado di produrre qualcosa di metà utilizzabile. Ho fatto una ricerca piuttosto ampia di Internet e ho letto articoli su ciò che un documento sugli standard di codifica dovrebbe / non dovrebbe contenere. Sembra un posto come un altro dove chiedere qualche suggerimento.

Mi rendo conto che potenzialmente sto aprendo una porta a un intero mondo di disaccordo sul "miglior modo di fare le cose". Capisco e rispetto sia il fatto innegabile che ogni programmatore ha un metodo preferito per risolvere ogni singolo compito, di conseguenza non sto cercando di scrivere qualcosa di così draconicamente proscriptivo da soffocare il talento personale ma cercare di ottenere una metodologia generale e concordato standard (ad es. convenzioni di denominazione) per aiutare a rendere il codice delle persone più leggibile.

Quindi ecco qua ... qualche suggerimento? Qualcuno?

Iniziamo con

• Linee guida .NET di Microsoft: http://msdn.microsoft.com/en-us/library/ms229042.aspx (collegamento aggiornato per .NET 4.5)
• Linee guida C # di Microsoft: http://blogs.msdn.com/brada/articles/361363.aspx .

e quindi documentare le differenze e le aggiunte a quella base.

IDesign ha un documento sugli standard di codifica C # che viene comunemente utilizzato. Vedi anche le Linee guida per la progettazione del framework 2a edizione .

Definire ironicamente gli standard attuali è probabilmente la parte facile.

Il mio primo suggerimento sarebbe quello di ottenere suggerimenti dagli altri ingegneri su ciò che ritengono debbano essere coperti e quali linee guida ritengono importanti. Applicare qualsiasi tipo di linee guida richiede un certo grado di buy-in da parte delle persone. Se lasci cadere improvvisamente un documento su di essi che specifica come scrivere il codice incontrerai resistenza, che tu sia il ragazzo più giovane o più anziano.

Dopo aver ricevuto una serie di proposte, inviale al team per feedback e revisione. Ancora una volta, convincere le persone a comprarle tutte.

Potrebbero già essere adottate pratiche di codifica informali (ad es. Prefissare variabili membro, nomi di funzioni di camelcase). Se questo esiste e la maggior parte del codice è conforme ad esso, pagherà per formalizzare il suo utilizzo. L'adozione di uno standard contrario causerà più dolore di quanto valga la pena, anche se è qualcosa generalmente raccomandato.

Vale anche la pena considerare il refactoring del codice esistente per soddisfare i nuovi standard di codifica. Questo può sembrare una perdita di tempo, ma avere un codice che non soddisfa gli standard può essere controproducente in quanto avrai un miscuglio di stili diversi. Inoltre lascia alle persone un dilemma se il codice in un determinato modulo debba essere conforme al nuovo standard o seguire lo stile di codice esistente.

Ho sempre usato il pdf di Juval Lowy come riferimento durante gli standard di codifica / le migliori pratiche internamente. Segue molto vicino a FxCop / Source Analysis , che è un altro strumento prezioso per assicurarsi che lo standard venga seguito. Tra questi strumenti e riferimenti, dovresti essere in grado di elaborare uno standard piacevole che a tutti i tuoi sviluppatori non dispiacerà seguire ed essere in grado di applicarli.

Gli altri poster ti hanno indicato la linea di base, tutto ciò che aggiungerei è rendere il tuo documento breve, dolce e al punto, impiegando una forte dose di Strunk e White per distinguere i "must have" da "sarebbe bello se ".

Il problema con i documenti sugli standard di codifica è che nessuno li legge davvero come dovrebbero, e quando li leggono, non li seguono. La probabilità che un tale documento venga letto e seguito varia inversamente con la sua lunghezza.

Sono d'accordo che FxCop sia un buon strumento, ma troppo di questo può togliere tutto il divertimento dalla programmazione, quindi fai attenzione.

Non scrivere mai i tuoi standard di codifica usando quelli MS (o quelli Sun o ... come appropriato per la tua lingua). L'indizio è nella parola standard, il mondo sarebbe un posto molto più facile da programmare se ogni organizzazione non avesse deciso di scrivere la propria. Chi pensa davvero di imparare un nuovo insieme di "standard" ogni volta che cambi team / progetti / ruoli è un buon uso del tempo di chiunque. Il massimo che dovresti mai fare è riassumere i punti critici ma ti sconsiglio di farlo anche perché ciò che è critico varia da persona a persona. Altri due punti che vorrei fare sugli standard di codifica

1. La chiusura è abbastanza buona - La modifica del codice per seguire gli standard di codifica della lettera è una perdita di tempo purché il codice sia abbastanza vicino.
2. Se stai modificando il codice che non hai scritto, segui gli "standard di codifica locali", ovvero fai in modo che il tuo nuovo codice assomigli al codice circostante.

Questi due punti sono la realtà per il mio desiderio che tutti scrivessero un codice simile.

Ho trovato la seguente documentazione molto utile e concisa. Viene dal sito idesign.net ed è stato creato da Juval Lowy

Standard di codifica C #

NB: il link sopra è ora morto. Per ottenere il file .zip devi fornire loro il tuo indirizzo email (ma non lo useranno per il marketing ... onestamente) Prova qui

Ho appena iniziato in un luogo in cui gli standard di codifica impongono l'uso di m_ per le variabili membro, p_ per i parametri e prefissi per i tipi, come 'str' per le stringhe. Quindi, potresti avere qualcosa del genere nel corpo di un metodo:

m_strName = p_strName;

Orribile. Davvero orribile.

Aggiungerei Code Complete 2 all'elenco (so che Jeff è una specie di fan qui) ... Se sei uno sviluppatore junior, il libro ti tornerà utile per impostare la tua mente in un modo che getta le basi per il meglio ci sono pratiche di scrittura del codice e creazione di software.

Devo dire che ci sono arrivato un po 'tardi nella mia carriera, ma governa molti modi in cui penso alla programmazione e allo sviluppo del framework nella mia vita professionale.

Vale la pena dare un'occhiata;)

Le regole di Microsoft sono un ottimo punto di partenza. Puoi farli rispettare con FxCop.

Sarei tentato di applicare lo StyleCop di Microsoft come standard. Può essere applicato al momento della creazione. ma se hai un codice legacy, applica semplicemente StyleCop su un nuovo codice.

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

Alla fine avrà un'opzione refactor per ripulire il codice.

http://blogs.msdn.com/sourceanalysis/

Personalmente mi piace quello che IDesign ha messo insieme. Ma non è per questo che sto postando ...

La parte difficile della mia azienda è stata quella di prendere in considerazione tutte le diverse lingue. E so che la mia compagnia non è sola su questo. Usiamo C #, C, assembly (produciamo dispositivi), SQL, XAML, ecc. Sebbene ci siano alcune somiglianze negli standard, ognuno di solito viene gestito in modo diverso.

Inoltre, credo che standard di livello superiore abbiano un impatto maggiore sulla qualità del prodotto finale. Ad esempio: come e quando utilizzare i commenti, quando le eccezioni sono obbligatorie (ad esempio eventi avviati dall'utente), se (o quando) utilizzare le eccezioni rispetto ai valori di ritorno, qual è il modo oggettivo per determinare quale dovrebbe essere il codice del controller rispetto al codice di presentazione, ecc. Non fraintendetemi, sono necessari anche standard di basso livello (la formattazione è importante per la leggibilità!) Ho solo un orientamento verso la struttura generale.

Un altro pezzo da tenere a mente è il buy-in e l'applicazione. Gli standard di codifica sono fantastici. Ma se nessuno è d'accordo con loro e (probabilmente ancora più importante) nessuno li impone, allora è tutto per nulla.

Mentre scrivevo sia quello pubblicato per Philips Medical Systems sia quello su http://csharpguidelines.codeplex.com, potrei essere un po 'di parte, ma ho più di 10 anni per scrivere, mantenere e promuovere standard di codifica. Ho provato a scrivere quello CodePlex con differenze di opinioni in mente e ho speso la maggior parte dell'introduzione su come gestirlo nella tua particolare organizzazione. Leggilo e forniscimi un feedback .....

Regole SSW

Include alcuni standard C # + molto altro .... principalmente focalizzati sugli sviluppatori Microsoft

Molto probabilmente sei impostato per fallire. Benvenuti nel settore.

Non sono d'accordo - fintanto che crea il documento, il peggio che può accadere è che venga dimenticato da tutti.

Se altre persone hanno problemi con il contenuto, puoi chiedere loro di aggiornarlo per mostrare ciò che preferiscono. In questo modo è fuori dal piatto e gli altri hanno la responsabilità di giustificare i loro cambiamenti.

Recentemente ho trovato il manuale Encodo C # , che include idee provenienti da molte altre fonti (IDesign, Philips, MSDN).

Un'altra fonte potrebbe essere Linee guida per la codifica .NET Professional C # / VB .

Sono un grande fan del libro di Francesco Balena " Linee guida e buone pratiche per gli sviluppatori VB e C # ".

È molto dettagliato e copre tutti gli argomenti essenziali, non solo ti dà la regola, ma spiega anche il motivo dietro la regola e fornisce anche un'anti-regola in cui potrebbero esserci due migliori pratiche opposte. L'unico aspetto negativo è che è stato scritto per gli sviluppatori .NET 1.1.

Il nostro intero standard di codifica recita approssimativamente "Usa StyleCop".

Vedi questo: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx .

Devo suggerire il documento dotnetspider.com .
È un documento eccezionale e dettagliato, utile ovunque.

Ho usato Juval prima e questo è finito se non eccessivo, ma sono pigro e ora solo conforme alla volontà di Resharper .

Puoi dare un'occhiata a questo, i primi 7 standard di codifica e documenti guida per gli sviluppatori C # /. NET http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html spero che questo aiuti

Penso di fare eco agli altri commenti qui che le linee guida per la SM già collegate sono un ottimo punto di partenza. Modello il mio codice in gran parte su quelli.

Il che è interessante perché il mio manager mi ha detto in passato che non gli piace molto: D

Amico, hai un compito divertente davanti a te. Buona fortuna, e per favore chiedi se hai bisogno di qualcosa di più :)

Lo standard di Philips Medical Systems è ben scritto e segue principalmente le linee guida Microsoft: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

I miei standard si basano su questo con alcune modifiche e alcuni aggiornamenti per .NET 2.0 (lo standard Philips è scritto per .NET 1.x quindi è un po 'datato).

Seguo anche Resharper. Anche la linea guida menzionata sul blog di scott guthrie http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net .aspx e http://csharpguidelines.codeplex.com/releases/view/46280

Nel codice che scrivo di solito seguo le Linee guida di progettazione .NET Framework per le API esposte pubblicamente e le Linee guida per la codifica mono per il casing e il rientro dei membri privati . Mono è un'implementazione open source di .NET e penso che quei ragazzi conoscano il loro business.

Odio il modo in cui il codice Microsoft spreca spazio:

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

Ciò che potresti trovare strano nelle linee guida Mono, è che usano schede a 8 spazi. Tuttavia, dopo un po 'di pratica, ho scoperto che in realtà mi aiuta a scrivere codice meno complicato applicando una sorta di limite di rientro.

Adoro anche come hanno messo uno spazio prima di aprire la parentesi.

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

Ma per favore, non imporre nulla del genere se ai tuoi colleghi non piace (a meno che tu non sia disposto a contribuire a Mono ;-)