Free Press

Benvenuti nel meraviglioso mondo dello sviluppo del software. Preparatevi per un viaggio eccitante ed emozionante pieno di codice, regole e ancora codice. E ho già detto che ci sono delle regole? Se siete qualcuno che ha familiarità con la codifica, allora il concetto di standard di codifica non è nuovo per voi. Puoi essere un forte sostenitore di queste linee guida o un combattente per la libertà che crede che il codice sia una forma di espressione. Qualunque sia il caso, non fa male guardare alcune delle migliori pratiche quando si tratta di scrivere un buon pezzo di codice.
Vale la pena ricordare che mentre gli standard di codifica esistono – esistono in molte varianti e spesso sono solo linee guida che non devono essere seguite. A meno che non vogliate scrivere del buon codice, allora probabilmente dovreste attenervi a qualche forma di standard.

Scrivere commenti e documentazione

Forse una delle prime cose che imparate come sviluppatori è commentare il vostro codice. All’inizio può sembrare una perdita di tempo, seguendo la mentalità del ‘Se anche loro sono sviluppatori – possono capirlo’. Mentre è vero alcune volte, commentare il vostro codice e fornire una documentazione adeguata guiderà gli altri sviluppatori attraverso l’algoritmo e la logica che avete implementato. Ma non lasciatevi trasportare e commentate ogni linea di codice! Il codice ovvio dovrebbe essere lasciato così com’è.

Scrivere codice leggibile ma efficiente

I codici leggibili sono facili da seguire, ma utilizzano spazio e tempo ottimali. Quando si scrive del codice si può spesso desiderare di scriverlo nel minor numero di righe possibile. Forse si può scrivere un intero metodo o funzione in una riga, ma questo rende solo più difficile la lettura e la comprensione.

Utilizzare metodi helper

È buona pratica mantenere il codice conciso e succinto. Un metodo dovrebbe implementare solo ciò che deve fare. Se una parte della tua implementazione fa qualcos’altro, mettila in un metodo separato e chiamalo all’interno del tuo metodo.

Se evitabile, NON hard-code!

Le uniche cose che dovrebbero essere hard-coded sono le costanti. Tutto qui.

Scrivete i casi di test. Non dimenticare i casi limite: 0s, stringhe/liste vuote, nulls, ecc.

In questo modo sapete cosa fa il vostro metodo, cosa prende e cosa dovrebbe restituire. Saprete quando deve funzionare o quando deve fallire. Una funzione dovrebbe sempre essere basata su casi di test; non test su funzioni.

Scrivi codice leggibile ma efficiente.Conformati agli standard di codifica del tuo progetto corrente

“DISCIPLINED PERSONAL PRACTICES CAN REDUCE DEFECT INTRODUCTION RATES BY UP TO 75 PERCENT”

Ogni progetto/azienda ha i propri standard di codifica. Alcuni potrebbero preferire uno stile all’altro quando si tratta di cose come le convenzioni di denominazione, la struttura dei file e la spaziatura.
Ci sono IDE in cui è possibile impostare lo stile preferito, che si auto-correggerà quando si salva. È più facile da leggere e, quindi, da capire, quando tutti i file dei progetti usano lo stesso stile, convenzione di denominazione, spaziatura, ecc.

Utilizza il menu a discesa del tuo IDE

Non tanto uno standard, ma una buona pratica, questi sono molto utili e ti aiuteranno a fare meno errori di codifica.

Per esempio:
Se volete rinominare una variabile o un metodo, basta usare l’opzione “refactor” del vostro IDE e cambierà tutte le chiamate a quel nome di metodo/variabile. Non dovete cambiarle una per una, il che renderà il vostro codice soggetto a errori/fallimenti.
Se volete creare metodi getter/setter di tutte le vostre variabili private, basta usare “create getter/setter” e l’IDE creerà automaticamente i metodi per voi.

Le API sono comode

“I PROGETTI SOFTWARE ATTUALI SPENDONO CIRCA IL 40-50 PERCENTUALE DEL LORO SFORZO IN RILIEVI EVITABILI”

Prima di implementare un metodo, assicuratevi che non sia disponibile per voi. Non dovete codificare se potete semplicemente importare la funzionalità. Rende la vita di uno sviluppatore super facile.
Il famoso detto è “Non reinventare la ruota” ed è vero in molti casi. Tuttavia, dovresti sempre considerare le implicazioni dell’importazione di una libreria, specialmente se è di terze parti. A parte i possibili problemi di licenza, potreste semplicemente gonfiare il vostro codice. Se tutto ciò di cui hai bisogno è un metodo che converte le temperature, non devi importare una libreria che fa quello e un centinaio di altre cose.

Pair programming/code review

“PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Questi sono molto utili quando si tratta di rifattorizzare il tuo codice. Altri potrebbero vedere una migliore implementazione per ottimizzare il vostro codice o semplicemente rendere il vostro codice più elegante. Assicura anche che gli sviluppatori aderiscano agli standard e che il lavoro sia controllato due volte. Oltre a tutto questo, è un modo meraviglioso per gli sviluppatori di imparare l’uno dall’altro.

BACKUP E SALVATE IL VOSTRO LAVORO DIVERSAMENTE

Basta dire. Batteria scarica, blackout, malfunzionamento del software, incendio, disastro nucleare – tutti questi possono causare la perdita di dati. Assicurarsi di salvare spesso e fare il backup del codice su qualche tipo di sistema di controllo della versione è un modo semplice per assicurarsi che il codice rimanga al sicuro.

Gli standard di codifica e le migliori pratiche sono un argomento enorme – uno che può andare avanti per molte pagine. Infatti, se volete leggere gli standard di codifica Java, Oracle ha proprio questo. L’applicazione di questi standard e pratiche varia anche in base all’applicazione – se state lavorando ad un enorme progetto aziendale o aiutando il vostro fratellino con i compiti. In base a molti fattori, alla fine sta a voi assicurarvi che il codice che sviluppate sia un buon codice.

Disclaimer: Qualsiasi punto di vista o opinione presentata in questo post del blog sono esclusivamente quelli dell’autore e non rappresentano necessariamente quelli di Aversan Inc.