Questa sezione è anche un prerequisito per la codifica, come sottolinea McConnell: “Stabilire convenzioni di programmazione prima di iniziare la programmazione. È quasi impossibile cambiare il codice per abbinarli in seguito.”

Come elencato vicino alla fine delle convenzioni di codifica, ci sono diverse convenzioni per diversi linguaggi di programmazione, quindi potrebbe essere controproducente applicare le stesse convenzioni tra lingue diverse. È importante notare che non esiste una particolare convenzione di codifica per qualsiasi linguaggio di programmazione. Ogni organizzazione ha uno standard di codifica personalizzato per ogni tipo di progetto software. È quindi imperativo che il programmatore scelga o costituisca un particolare insieme di linee guida di codifica prima che il progetto software inizi. Alcune convenzioni di codifica sono generiche che potrebbero non essere applicabili per ogni progetto software scritto con un particolare linguaggio di programmazione.

L’uso delle convenzioni di codifica è particolarmente importante quando un progetto coinvolge più di un programmatore (ci sono stati progetti con migliaia di programmatori). È molto più facile per un programmatore leggere il codice scritto da qualcun altro se tutto il codice segue le stesse convenzioni.

Per alcuni esempi di convenzioni di codifica errate, Roedy Green fornisce un lungo articolo (tongue-in-cheek) su come produrre codice non manutenibile.

CommentingEdit

A causa di restrizioni di tempo o programmatori entusiasti che vogliono risultati immediati per il loro codice, il commento del codice spesso passa in secondo piano. I programmatori che lavorano come una squadra hanno trovato meglio lasciare commenti alle spalle dal momento che la codifica di solito segue cicli, o più di una persona può lavorare su un particolare modulo. Tuttavia, alcuni commenti possono ridurre il costo del trasferimento di conoscenze tra sviluppatori che lavorano sullo stesso modulo.

Nei primi giorni dell’informatica, una pratica di commento era quella di lasciare una breve descrizione di quanto segue:

1. Nome del modulo
2. Scopo del Modulo
3. Descrizione del Modulo
4. Autore originale
5. Modifiche
6. Autori che hanno modificato il codice con una descrizione sul perché è stato modificato.

La “descrizione del modulo” dovrebbe essere il più breve possibile ma senza sacrificare la chiarezza e la completezza.

Tuttavia, gli ultimi due elementi sono stati in gran parte obsoleti dall’avvento dei sistemi di controllo delle revisioni. Le modifiche e la loro paternità possono essere tracciate in modo affidabile utilizzando tali strumenti piuttosto che utilizzando i commenti.

Inoltre, se viene utilizzata una logica complicata, è buona norma lasciare un commento “block” vicino a quella parte in modo che un altro programmatore possa capire cosa sta succedendo esattamente.

Unit testing può essere un altro modo per mostrare come il codice è destinato ad essere utilizzato.

Convenzioni di nomeedit

L’uso di convenzioni di denominazione appropriate è considerato una buona pratica. A volte i programmatori tendono ad usare X1, Y1, ecc. come variabili e dimenticare di sostituirli con quelli significativi, causando confusione.

Di solito è considerato una buona pratica usare nomi descrittivi.

Esempio: una variabile per prendere peso come parametro per un camion può essere denominata TrkWeight o TruckWeightKilograms, con TruckWeightKilograms che è preferibile, poiché è immediatamente riconoscibile. Vedere CamelCase denominazione delle variabili.

Mantieni il codice simpleEdit

Il codice che un programmatore scrive dovrebbe essere semplice. La logica complicata per ottenere una cosa semplice dovrebbe essere ridotta al minimo poiché il codice potrebbe essere modificato da un altro programmatore in futuro. La logica implementata da un programmatore potrebbe non avere perfettamente senso per un altro. Quindi, mantieni sempre il codice il più semplice possibile.

Per esempio, considerare equivalenti seguenti linee di codice C:

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

e

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

e

return hours < 24 && minutes < 60 && seconds < 60;

Il 1 ° approccio, che è molto più comunemente utilizzati, è notevolmente più grande rispetto al 3°. In particolare, consuma 5 volte più spazio verticale dello schermo (linee) e 97 caratteri contro 52 (anche se gli strumenti di modifica possono ridurre la differenza nella digitazione effettiva). È discutibile, tuttavia, che è “più semplice”. Il primo ha un if/then else esplicito, con un valore di ritorno esplicito ovviamente collegato a ciascuno; anche un programmatore alle prime armi non dovrebbe avere difficoltà a capirlo. Il 2 ° scarta semplicemente le parentesi graffe, tagliando a metà la dimensione “verticale” con pochi cambiamenti nella complessità concettuale. Nella maggior parte delle lingue le istruzioni “return” potrebbero anche essere aggiunte alle righe precedenti, portando la dimensione “verticale” a solo un’altra riga che la 3a forma.

La terza forma ovviamente riduce al minimo le dimensioni, ma può aumentare la complessità: Lascia impliciti i valori” true “e” false “e mescola le nozioni di” condition “e”return value”. È probabilmente ovvio per la maggior parte dei programmatori, ma un principiante potrebbe non capire immediatamente che il risultato della valutazione di una condizione è in realtà un valore (di tipo booleano, o il suo equivalente in qualsiasi lingua), e quindi può essere manipolato o restituito. In esempi più realistici, il 3 ° modulo potrebbe avere problemi a causa della precedenza dell’operatore, forse restituendo un tipo inaspettato, in cui i moduli precedenti in alcune lingue segnalerebbero un errore. Quindi, la “semplicità” non è solo una questione di lunghezza, ma di struttura logica e concettuale; rendere il codice più breve può renderlo meno o più complesso.

Per programmi di grandi dimensioni e di lunga durata, l’utilizzo di alternative dettagliate potrebbe contribuire a gonfiare.

La compattezza consente ai programmatori di visualizzare più codice per pagina, riducendo i gesti di scorrimento e le sequenze di tasti. Dato quante volte il codice potrebbe essere visualizzato nel processo di scrittura e manutenzione, potrebbe ammontare a un risparmio significativo nelle sequenze di tasti del programmatore nella vita del codice. Questo potrebbe non sembrare significativo per uno studente di prima imparare a programmare, ma, quando la produzione e la gestione di grandi programmi di riduzione del numero di righe di codice permette piu ‘ di codice per adattarsi sullo schermo, minori codice semplificazione può migliorare la produttività, e anche diminuire le dita, il polso e l’affaticamento degli occhi, che sono comuni problemi medici subiti dalla produzione programmatori e informazione dei lavoratori.

La codifica Terser velocizza leggermente la compilazione, poiché è necessario elaborare meno simboli. Inoltre, l’approccio 3rd può consentire di confrontare più facilmente righe di codice simili, in particolare quando molti di questi costrutti possono apparire su uno schermo contemporaneamente.

Infine, i layout molto terses possono utilizzare meglio i moderni display del computer wide-screen, a seconda del layout e della configurazione del monitor. In passato, gli schermi erano limitati a 40 o 80 caratteri (tali limiti hanno avuto origine molto prima: manoscritti, libri stampati e persino pergamene, hanno usato per millenni linee piuttosto brevi (vedi ad esempio la Bibbia di Gutenberg). Gli schermi moderni possono facilmente visualizzare 200 o più caratteri, consentendo linee estremamente lunghe. La maggior parte degli stili e degli standard di codifica moderni non occupa l’intera larghezza. Pertanto, se si utilizza una finestra larga quanto lo schermo, viene sprecata una grande quantità di spazio disponibile. D’altra parte, con più finestre o utilizzando un IDE o un altro strumento con varie informazioni nei riquadri laterali, la larghezza disponibile per il codice è nell’intervallo familiare dai sistemi precedenti.

Vale anche la pena notare che il sistema visivo umano è fortemente influenzato dalla lunghezza della linea; le linee molto lunghe aumentano leggermente la velocità di lettura, ma riducono la comprensione e aggiungono errori di tracciamento degli occhi. Alcuni studi suggeriscono che le linee più lunghe tariffa meglio online che in stampa, ma questo ancora va solo fino a circa 10 pollici, e soprattutto per la velocità grezzo di prosa di lettura.

PortabilityEdit

Il codice del programma non deve contenere valori “hard-coded” (letterali) che si riferiscono a parametri ambientali, come percorsi di file assoluti, nomi di file, nomi utente, nomi host, indirizzi IP, URL, porte UDP / TCP. In caso contrario, l’applicazione non verrà eseguita su un host con un design diverso da quello previsto. Un programmatore attento può parametrizzare tali variabili e configurarle per l’ambiente di hosting al di fuori dell’applicazione corretta (ad esempio nei file di proprietà, su un server di applicazioni o anche in un database). Confronta il mantra di un”singolo punto di definizione” (SPOD).

Come estensione, risorse come i file XML dovrebbero contenere anche variabili piuttosto che valori letterali, altrimenti l’applicazione non sarà portabile in un altro ambiente senza modificare i file XML. Ad esempio, con le applicazioni J2EE in esecuzione in un server di applicazioni, tali parametri ambientali possono essere definiti nell’ambito della JVM e l’applicazione dovrebbe ottenere i valori da lì.

ScalabilitàEdit

Codice di progettazione con la scalabilità come obiettivo di progettazione perché molto spesso nei progetti software, nuove funzionalità vengono sempre aggiunte a un progetto che diventa più grande. Pertanto, la possibilità di aggiungere nuove funzionalità a una base di codice software diventa un metodo inestimabile nella scrittura di software

Riutilizzabilitàedit

Il riutilizzo è un obiettivo di progettazione molto importante nello sviluppo del software. Il riutilizzo riduce i costi di sviluppo e riduce anche i tempi di sviluppo se i componenti o i moduli riutilizzati sono già testati. Molto spesso, i progetti software iniziano con una linea di base esistente che contiene il progetto nella sua versione precedente e, a seconda del progetto, molti dei moduli e dei componenti software esistenti vengono riutilizzati, riducendo i tempi di sviluppo e test aumentando quindi la probabilità di consegnare un progetto software nei tempi previsti.

Linee guida di costruzione in brevemodifica

Una panoramica generale di tutto quanto sopra: