Oltre a "trattare gli avvertimenti come errori" e a fissare perdite di memoria, quali altre idee dovremmo implementare come parte dei nostri standard di codifica?

Question

Prima lasciatemi dire, non sono un programmatore ma aiuto a gestire un team di codifica. Nessuno nel team ha più di 5 anni di esperienza e la maggior parte di loro ha lavorato solo per questa compagnia. Quindi stiamo volando un po 'alla cieca, da qui la domanda.

Stiamo cercando di rendere il nostro software più stabile e stiamo cercando di implementare alcune "best practice" e standard di codifica. Recentemente abbiamo iniziato a prenderlo molto sul serio, in quanto abbiamo determinato che gran parte dell'instabilità nel nostro prodotto potrebbe essere ricondotta al fatto che abbiamo consentito a Warnings di passare attraverso senza doverli correggere durante la compilazione. Inoltre, non ci siamo mai presi la briga di prendere le perdite di memoria abbastanza sul serio.

Nella lettura di questo sito stiamo risolvendo rapidamente questo problema con il nostro team ma si pone la domanda, quali altre pratiche possiamo implementare a livello di team che ci aiuteranno?

Modifica: Facciamo abbastanza complesso software di grafica 2D/3D che è multipiattaforma Mac/Windows in C++.

Answer 1

In genere, il livello di precisione/precisione degli standard di codifica/processo è direttamente collegato al livello di sicurezza richiesto. Ad esempio, se lavori nel settore aerospaziale, controllerai molto praticamente tutto. Ma, dall'altra parte dello spettro, se stai lavorando su un sito di forum di giochi per computer ... se qualcosa si rompe, niente da fare. È possibile avere lo slop. Quindi YMMV, a seconda del tuo campo.

Il classico libro sulla codifica è Code Complete 2nd edition, di Steve McConnell. Chiedi a una squadra di copiare & di consigliare vivamente ai tuoi sviluppatori di acquistarlo (o chiedere alla compagnia di ottenerlo per loro). Ciò soddisferà probabilmente il 70% delle domande stilistiche. CC affronta la maggior parte dei casi di sviluppo.

edit:

software di grafica, C++, Mac/Windows.

Dal momento che si sta facendo il lavoro cross-platform, ho consiglierei visto un processo automatizzato "compilazione on-checkin" per il vostro Mac (10.4 (forse), 10.5, 10.6) e Windows (XP (forse), Vista, 7). Ciò garantisce che il tuo software compili al minimo e sai quando non lo fa.

Il controllo sorgente (che si è utilizzando, presumo), dovrebbe supportare la ramificazione, e la strategia di ramificazione può riflettere anche cross-platformy-ness. È inoltre vantaggioso avere filiali principali, filiali di sviluppo e filiali sperimentali. YMMV; probabilmente sarà necessario iterare su questo e consultarsi con persone che hanno familiarità con la gestione della configurazione.

Dato che è C++, probabilmente vorrai eseguire Valgrind o simili per sapere se c'è una perdita di memoria. Esistono alcuni analizzatori statici che è possibile ottenere: non so quanto siano efficaci nel linguaggio C++ moderno. Puoi anche investire nella scrittura di alcuni wrapper per aiutare a guardare le allocazioni di memoria.

Informazioni su C++ ...I libri Effective C++, More Effective C++ ed Effective STL (tutti di Scott Meyers) dovrebbero essere sullo scaffale di qualcuno, così come Modern C++ di Andrescu. Puoi anche trovare utile il libro di Lippman sul modello di oggetti C++, non lo so.

HTH.

Answer 2

Test-Driven Development. TDD aiuta a verificare gli errori logici nella fase di sviluppo.

Answer 3

Ci sono molti consulenti/aziende che hanno regole di codifica per venderti, non dovresti avere difficoltà a trovarne uno. Tuttavia, uno che non ti chiede prima il campo in cui ti trovi (non l'hai menzionato nella tua domanda) ti fornisce olio di serpente.

Answer 4

Questo post di blog descrive molte delle pratiche comuni di mediocre programming. Questi sono alcuni dei potenziali problemi che sta avendo la squadra. Include una rapida spiegazione della "migliore pratica" per ciascuno di essi.

Answer 5

Non parli di alcuna lingua e, sebbene sia vero che la maggior parte degli standard di codifica sono indipendenti dalla lingua, ti aiuterà anche nella ricerca. Sulla maggior parte delle aziende che ho lavorato, hanno standard di codifica diversi per i diversi linguaggi di programmazione. Quindi il mio consiglio sarà:

• Cambiare lingua
• Cerca nel web dal momento che ci sono un sacco di norme là fuori per la lingua
• raccogliere tutti gli standard che avete trovato
• dividere il gruppo in gruppi e dare loro alcuni dei documenti da analizzare. Dovrebbero venire con una lista di cose che ritengono degne di avere nei loro nuovi standard.
• Fare una riunione in modo che ogni gruppo presenti i risultati a tutti (ci sarà molta ridondanza tra i gruppi). Questa dovrebbe essere una discussione aperta e l'opinione di tutti dovrebbe essere presa in considerazione.
• Compila un elenco degli standard che sono stati selezionati dalla maggior parte dei codificatori e questo dovrebbe essere il tuo punto di partenza.
• Eseguire revisioni semestrali degli standard, per aggiungere o rimuovere elementi.

Ora, la logica alla base di questo è: La maggior parte dei problemi derivanti dal mettere da parte uno standard di codifica da zero è l'accettazione dello sviluppatore. Ognuno di noi ha un modo di fare le cose e fa schifo quando qualcuno dall'esterno crede che un modo di fare le cose sia migliore di un altro. Quindi, se gli sviluppatori comprendono la logica e lo scopo degli standard di codifica, allora hai metà del lavoro svolto. L'altra cosa è che gli standard dovrebbero essere progettati e creati appositamente per le esigenze della tua azienda. Ci saranno alcune cose che hanno senso, altre no. Con l'approccio sopra puoi discriminare tra quelli. L'altra cosa è che gli standard dovrebbero essere in grado di cambiare nel tempo per riflettere le esigenze dell'azienda, quindi uno standard di codifica dovrebbe essere un documento vivente.

Answer 6

Porta tutti a leggere e discutere vari standard e linee guida. Io (così come Stroustrup) suggerisco lo Joint Strike Fighter coding standards. Chiedete ai vostri sviluppatori di classificare le linee guida in esso tra

• già incontrato
• possano essere soddisfatte facilmente (pochi cambiamenti da condizione attuale)
• dovrebbero lavorare verso nel vecchio codice e seguire nel nuovo sviluppo
• Non vale la pena si

Avere le lunghe discussioni tecniche, e stabilirsi su un set per la squadra di adottare.

Answer 7

La prima cosa che devi considerare quando aggiungi gli standard di codifica/le migliori pratiche è l'effetto che avrà sul morale e sulla coesione della tua squadra. Gli sviluppatori di solito si risentono delle pratiche che vengono loro imposte anche se sono buone idee. I problemi della gente devono essere affrontati per un grande cambiamento per avere successo.

È necessario coinvolgere il gruppo nello sviluppo degli standard e cercare di raggiungere un consenso. Detto questo, non otterrete mai un accordo universale su nulla, quindi dovrete bilanciare il consenso e raggiungere gli standard. Ho visto grandi lotte su qualcosa di semplice come le schede rispetto agli spazi nella sorgente.

Il miglior libro che ho visto per le linee guida C/C++ in progetti complicati è Large Scale C++ Software Design. Quel libro insieme a Code Complete (che è un classico da leggere) sono buoni punti di partenza.

Answer 8

Una cosa su cui dovresti avere delle regole è una sorta di standard di denominazione. Rende solo la vita più facile per le persone pur non essendo davvero invasiva.

A parte questo, dovrei dire che dipende dal livello della tua squadra. Alcuni hanno bisogno di più regole di altri. Le persone migliori sono, meno "supporto" di cui hanno bisogno dalle regole.

Se si desidera un insieme completo di regole di codifica per controllare ogni piccolo dettaglio, si passerà molto tempo a discutere su regole ed eccezioni alle regole e su cosa si dovrebbero scrivere regole. Vorrei andare con qualcosa già scritto.

Se sei preoccupato per la qualità, una cosa che potresti fare non si tratta di regole, è: Costruzione e test automatici. Questo mi ha aiutato molto. Una volta trovato un problema, è davvero utile avere un ambiente in cui è possibile scrivere un test per verificare il problema. Risolvi il problema e aggiungi facilmente il tuo test a una suite di test automatica che assicura che quel tipo di problema non possa tornare senza essere individuato. Quindi assicurati che vengano eseguiti spesso. Preferibilmente ogni volta che qualcuno controlla qualcosa.

Answer 9

Se si decide di avere standard di codifica, si vuole essere molto attenti a ciò che si inserisce. Se il documento è troppo lungo o si concentra su dettagli stilistici arbitrari, verrà semplicemente ignorato e nessuno si prenderà la briga di leggerlo. Spesso molto di ciò che riguarda gli standard di codifica sono solo le preferenze della persona che ha scritto il documento (o alcuni standard che sono stati copiati dal web!). Se qualcosa è nello standard, deve essere molto chiaro al lettore come migliora la qualità e perché è importante.

Direi che gran parte di ciò che rende leggibile il codice ha a che fare con il design piuttosto che con il layout del codice. Ho visto un sacco di codice che rispetta gli standard, ma è ancora difficile da leggere (metodi molto lunghi, nomi errati ecc.) - non si può avere tutto come standard, ad un certo punto si tratta di quanto esperti e disciplinato i tuoi sviluppatori sono - fare ciò che puoi per aumentare le loro competenze.

Forse piuttosto che un documento di standard di codifica, provare a far conoscere al team il buon design (più facile a dirsi che a farsi, lo so). Rendili consapevoli di cose come i principi SOLID, come separare le preoccupazioni, come gestire correttamente le eccezioni. Se progettano bene, il codice sarà facile da leggere e non importa se ci sono abbastanza linee bianche o le parentesi graffe sono nel posto giusto.

Ottenere alcuni libri sui principi di progettazione (vedere un paio di raccomandazioni di seguito). Magari fai fare al gruppo dei workshop per discutere alcuni degli argomenti. Magari portarli a scrivere collettivamente un documento su quali principi potrebbero essere importanti per il loro progetto. Qualunque cosa tu faccia, assicurati che sia la squadra nel suo complesso che decide quali sono gli standard/principi.

http://www.amazon.co.uk/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Answer 10

Se il quadro impone alcune regole per funzionare bene, mettere quelli del tuo standard di codifica.

Answer 11

Queste basi sono buone per la maggior parte qualsiasi settore o dimensione di squadra:

1. metodologia Agile Usa (scrum è un buon esempio). http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/rup_bestpractices.pdf
2. sviluppo Utilizzare test-driven. http://www.agiledata.org/essays/tdd.html
3. Utilizzare standard di codifica coerenti. Ecco un documento di esempio: http://www.dotnetspider.com/tutorials/BestPractices.aspx
4. Ottieni familiarità con i buoni schemi di progettazione . http://www.dofactory.com/Patterns/Patterns.aspx

Non si può sbagliare con queste informazioni di base. Costruisci da lì con i nuovi membri del team che sono stati lì e lo hanno fatto. Suggerisco caldamente di programmare la coppia una volta che hai messo in squadra quei ragazzi. È il modo migliore per infettare le persone con le migliori pratiche.

Buona fortuna a te!

Answer 12

Non scrivere i propri standard da zero.

È probabile che ci sono molti là fuori che definisce ciò che si vuole già, e sono più completo di quanto si potrebbe trovare con soli. Detto questo, non preoccuparti troppo se non sei d'accordo al 100% con esso su questioni minori, puoi scambiare alcune parti di altri, o chiamare un'infrazione di esso piuttosto che un errore, a seconda delle tue esigenze . (per esempio, alcuni standard lanciano un avvertimento se la lunghezza di una linea è lunga più di 80 caratteri, io preferisco non più di 120 come limite rigido, ma assicurerei che ci fosse una buona ragione - ad esempio leggibilità & - se c'era> 80).

Inoltre, cercare di trovare metodi automatizzati di controllo il codice contro lo standard - compreso il suo piccole modifiche come richiesto.

Answer 13

Le revisioni del codice hanno dimostrato di fornire benefici significativi per la qualità del codice, ancor più che il test tradizionale. Suggerirei di prendere l'abitudine di eseguire routine di progettazione e revisione del codice; il numero di fasi in cui vengono eseguite le recensioni, la formalità e i dettagli delle recensioni e la percentuale di lavoro soggetto a revisione possono essere impostati in base alle esigenze aziendali. Gli standard di codifica possono essere utili quando vengono eseguiti correttamente (e se il codice di tutti sembra simile, è anche più facile da esaminare), ma dove si inseriscono le parentesi e in che misura i blocchi di rientro non incideranno sui tassi di difetto.

Inoltre, vale la pena di familiarizzare con i propri colleghi e il proprio pari con il concetto di debito tecnico e lavorare un po 'alla volta per ridisegnare e migliorare le parti del sistema quando si entra in contatto con loro. Tuttavia, a meno che non si disponga di test e/o processi unitari completi per garantire un'alta qualità del codice, ciò potrebbe non essere d'aiuto.

Answer 14

dato che questo è Stack Overflow, qualcuno deve fare riferimento The Joel Test. Mi piace automatizzare il più possibile, quindi usare Lint è anche un must.

Answer 15

Oltre ai libri già raccomandato, vorrei anche ricordare,

C++ norme di codifica: 101 regole, linee guida e best practice da Herb Sutter e Andrei Alexandrescu (Brossura - 4 NOV, 2004)

Answer 16

Se stai programmando su VB.NET, assicurarsi che l'opzione Explicit e Option Rigor sia impostata su ON. Questo ti farà risparmiare molto dolore rintracciando bug misteriosi. Questi possono essere impostato a livello di progetto in modo che non è necessario ricordarsi di impostare loro in file di codice

Answer 17

mi piace molto: MISRA C standard (è un po 'tho rigoroso' ma le idee premuto per C++) e Lo standard C++ di Hi-Integrity http://www.codingstandard.com/HICPPCM/index.html che prende in prestito pesantemente MISRA

LDRA (uno strumento di analisi statico) utilizza questi standard per classificare il lavoro (che non uso poiché è costoso) ma posso garantire l'esecuzione di cppcheck come un buon correttore di analisi statica 'free/libre'.