Ci sono suggerimenti per lo sviluppo di un programma in C# coding standard / best practices documento?[chiuso]

StackOverflow https://stackoverflow.com/questions/14967

  •  08-06-2019
  •  | 
  •  

Domanda

Io sono un recente AI laureati (circa 2 anni) che lavorano per una modesta operazione.È toccato a me (principalmente come io sono il primo "adopter" in dipartimento) per creare una base (lettura utile?) C# standard di codifica documento.

Penso che dovrebbe spiegare che io sono probabilmente il più junior software engineer andare, ma non vedo l'ora a questo compito, come spero possa essere effettivamente in grado di produrre qualcosa di metà utilizzabile.Ho fatto una bella ricerca approfondita di Internet e di leggere articoli su ciò che un standard di codifica documento dovrebbe / non dovrebbe contenere.Questo mi sembra un ottimo luogo per chiedere alcuni consigli.

Mi rendo conto che sono potenzialmente aprendo una porta su un mondo di disaccordo e 'il modo migliore di fare le cose'.Io capisco e rispetto il fatto innegabile che ogni programmatore è un metodo preferito per la risoluzione di ogni singola attività, come risultato, io non sto cercando di scrivere qualcosa di così draconianly proscriptive come per soffocare un tocco personale, ma per cercare di ottenere una metodologia generale e delle norme concordate (ad es.convenzioni di denominazione per contribuire a rendere gli individui più leggibile il codice.

Così qui va ....qualche suggerimento?A tutti?

È stato utile?

Soluzione

Iniziamo con

e poi documentare le differenze e le aggiunte a quella di base.

Altri suggerimenti

IDesign ha un C# standard di codifica documento che è comunemente usato.Vedi anche il Quadro di Linee guida per la Progettazione 2a Ed.

Ironia della sorte impostazione standard attuali sono probabilmente la parte più facile.

Il mio primo suggerimento sarebbe quello di suscitare suggestioni da altri ingegneri su ciò che si sente dovrebbe essere coperto, e quali sono le linee che si sentono sono importanti.Applicazione di qualsiasi tipo di linee guida richiede un livello di buy-in a partire dalle persone.Se improvvisamente si rilascia un documento che specifica come scrivere il codice che si incontrano resistenza, se siete più junior o senior ragazzo.

Dopo una serie di proposte, poi li mandano al team per il feedback e revisione.Di nuovo, convincere la gente ad acquistare in loro.

Ci può essere già informale pratiche di codifica adottati (e.g prefisso variabili membro, camelcase nomi di funzione).Se questo esiste, e la maggior parte del codice è conforme ad esso, poi saranno loro a pagare per formalizzare il suo utilizzo.L'adozione di un contrasto standard sta per causare più dolore di quanto ne vale la pena, anche se è qualcosa che generalmente raccomandato.

Vale anche la pena di considerare il refactoring del codice esistente per soddisfare le nuove codifiche standard.Questo può sembrare uno spreco di tempo, ma avendo il codice che non soddisfa gli standard può essere controproducente in quanto si avrà una mescolanza di stili diversi.Inoltre, lascia la gente in un dilemma del codice in un certo modulo deve essere conforme ai nuovi standard o seguire il codice esistente stile.

Io ho sempre usato Juval Lowy s pdf come riferimento quando si fa la codifica standard / best practices internamente.Segue molto vicino a FxCop/L'Analisi Delle Fonti, che è un altro strumento prezioso per assicurarsi che la norma è seguita.Tra questi strumenti e riferimenti, si dovrebbe essere in grado di venire con un bel standard che tutti gli sviluppatori non si preoccupano di seguito ed essere in grado di farle rispettare.

Altri manifesti hanno illustrato al basale, di tutto vorrei aggiungere è rendere il documento breve, dolce e al punto, impiegando una dose pesante di Strunk e White per distinguere i "must", da "sarebbe bello se".

Il problema con gli standard di codifica dei documenti è che nessuno li legge come dovrebbero, e quando li leggo, non li seguono. La probabilità di un tale documento, di essere letta e seguita è inversamente proporzionale alla sua lunghezza.

Sono d'accordo FxCop è un buon strumento, ma anche molto di questo può prendere tutto il divertimento a destra, fuori di programmazione, in modo da essere attenti.

Mai scrivere il proprio standard di codifica utilizzare il MS quelli (o il Sole o ...come appropriato per la lingua).L'indizio è nella parola standard, il mondo sarebbe molto più agevole per il codice in se ogni organizzazione avessi deciso di scrivere loro.Chi pensa veramente di imparare un nuovo set di 'standard' ogni volta che si cambia team/progetti/ruoli è un buon uso di chiunque di tempo.La maggior parte si dovrebbe mai fare è di riassumere i punti critici, ma vorrei consigliare contro di fare anche perché ciò che è fondamentale varia da persona a persona.Altri due punti che vorrei fare su standard di codifica

  1. Vicino è sufficiente modificare il codice per seguire gli standard di codifica per la lettera è uno spreco di tempo, purché il codice è abbastanza vicino.
  2. Se si modifica il codice non scrivere seguire il "locale di codifica standard", vale a direrendere il vostro nuovo codice cerca circostante codice.

Questi due punti sono il realtà il mio desiderio che tutti avrebbero scrivere il codice che sembrava la stessa.

Ho trovato la seguente documentazione molto utile e conciso.Esso deriva dal idesign.net sito creato da Juval Lowy

C# Standard Di Codifica

NB:il link di cui sopra è ormai morto.Per ottenere il .il file zip è necessario dare loro il vostro indirizzo email (ma non la uso per il marketing...onestamente) Provare qui

Ho appena iniziato, in un luogo dove gli standard di codifica mandato l'utilizzo di m_ per le variabili membro, p_ per i parametri e i prefissi per i tipi come 'str' per le stringhe.Così, si potrebbe avere qualcosa di simile a questo nel corpo di un metodo:

m_strName = p_strName;

Orribile.Veramente orribile.

Vorrei aggiungere Il Codice Completo Di 2 per l'elenco (so che Jeff è una specie di fan qui)...Se sei uno sviluppatore junior, il libro è utile per impostare la tua mente in un modo che pone le basi per il miglior codice di pratiche di scrittura e costruzione di software ci sono.

Devo dire che mi è venuto un po ' tardi nella mia carriera, ma è un sacco di modi penso di codifica e sviluppo di un quadro nella mia vita professionale.

Vale la pena ;)

Microsoft proprie regole sono un ottimo punto di partenza.Si può applicare con FxCop.

Sarei tentato di imporre Microsoft StyleCop come standard.Può essere eseguita a tempo di compilazione.ma se si dispone di codice legacy, poi basta imporre l'utilizzo del StyleCop sul nuovo codice.

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

Alla fine si avrà un refactor opzione per il codice di pulitura.

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

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

Il difficile bit per la mia azienda stava prendendo tutte le diverse lingue in considerazione.E so che la mia azienda non è solo su questo.Utilizziamo C#, C, assembly (facciamo dispositivi), SQL, XAML, etc.Anche se ci saranno alcune somiglianze nelle norme, ciascuna delle quali è di solito gestita in modo diverso.

Inoltre, credo che il più alto livello di standard hanno un maggiore impatto sulla qualità del prodotto finale.Per esempio:come e quando utilizzare i commenti, quando le eccezioni sono obbligatorie (ad es.l'utente ha avviato eventi), se (o quando) per utilizzare le eccezioni vsi valori di ritorno, qual è il metodo oggettivo per determinare quello che dovrebbe essere il codice di controller vs codice di presentazione, etc.Non fraintendetemi, a basso livello gli standard necessari (la formattazione è importante per la leggibilità!) Ho solo un bias verso la struttura complessiva.

Un altro pezzo da tenere a mente è di buy-in e di esecuzione.Standard di codifica sono grandi.Ma se nessuno è d'accordo con loro e (forse più importante) nessuno impone loro, allora è tutto inutile.

Come ho scritto sia quello pubblicato per Philips Medical Systems, e quella http://csharpguidelines.codeplex.com Potrei essere un po ' prevenuto, ma ho più di 10 anni di scrittura, il mantenimento e la promozione di standard di codifica.Ho provato a scrivere una CodePlex con differenze di opinione nella mente e ha trascorso la maggior parte dell'introduzione sul come gestire la particolare organizzazione.Leggere e darmi un feedback.....

SW Regole

Esso comprende alcune C# standard + un sacco di cose in più....focalizzata principalmente a sviluppatori di Microsoft

È più probabile essere impostato fino a fallire.Benvenuto al settore.

Io non sono d'accordo, a patto che egli crea il documento, il peggio che può succedere è che viene dimenticato da tutti.

Se altre persone hanno problemi con il contenuto, allora si può chiedere loro di aggiornare, per mostrare ciò che si preferisce.In questo modo è spegnere il vostro piatto, e gli altri hanno la responsabilità di giustificare le loro modifiche.

Di recente ho trovato Encodo C# Manuale, che comprende le idee da molte altre fonti (IDesign, Philips, MSDN).

Un'altra fonte può essere Professional C#/VB .NET Linee guida di Codifica.

Io sono un grande fan di Francesco Balena libro "Pratiche, Linee guida e Best Practice per VB e C# Sviluppatori".

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

Tutto il nostro standard di codifica legge circa", Utilizzare StyleCop."

Devo suggerire l' dotnetspider.com documento.
Si tratta di un grande e dettagliato documento che è utile ovunque.

Ho usato Juval prima e che se non eccessivo, ma io sono pigro, e per ora mi sono conformi alla volontà di Resharper.

È possibile verificare questo,Top 7 di Codifica Standard & Documenti Guida Per C#/.Sviluppatori NET http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html spero che questo aiuta

Penso di eco gli altri commenti qui che la MS le linee guida già collegati, sono un ottimo punto di partenza.Ho il modello del codice in gran parte su quelli.

Il che è interessante perché il mio manager mi ha detto in passato che non è troppo forte su di loro :D

Si divertirsi un compito da portare avanti per il mio amico.In bocca al lupo, e si prega di chiedere se avete bisogno di qualcosa di più :)

Standard da Philips Medical Systems è ben scritto, e per lo più segue le linee guida di Microsoft:www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

Il mio standard sono basati su questo, con poche modifiche, e alcuni aggiornamenti .NET 2.0 (Philips standard è scritto .NET 1.x così è un po ' datato).

Nel codice scrivo io di solito seguire .NET Framework Linee guida per la Progettazione per esposto pubblicamente le Api e Mono Linee Guida Di Codifica per membro privato di rivestimento e di rientro.Mono è una implementazione open source di .NET, e io penso che questi ragazzi sanno il loro business.

Odio il modo in cui Microsoft codice sprechi di spazio:

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

Quello che si potrebbe trovare strano in Mono linee guida, è che usano 8-spazio di schede.Tuttavia, dopo un po ' di pratica, ho scoperto che è in realtà mi aiuta a scrivere meno intricata codice applicando una sorta di rientro limite.

Mi piace anche come hanno messo uno spazio prima della parentesi di apertura.

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 di simile se i tuoi colleghi non piace (a meno che non siete disposti a contribuire a Mono ;-)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top