Lista per una buona programmazione

Source- Checklist for good programming

Author- Raphael Finkel

 

Questa lista dovrebbe aiutarti a scrivere un programma di alta qualità.
Raphael Finkel, 17/08/2005

  • Identificatori: Assicurati che tutti gli identificatori siano significativi.
    1. Gli identificatori di una lettera non sono quasi mai significativi.
    2. Nomi come flag o temp sono raramente significativi. Anziché flag, considera di nominare la condizione Booleana che controlla, come valueFound.
    3. Considera identificatori a più parola, come nameIndex. Gli identificatori lunghi (nei limiti del possibile) tendono ad essere ben leggibili.

 

  • Bare literals: Evita numeri oltre a 0 e 1 e stringhe oltre a “” nel tuo programma, eccetto quando definisci costanti.
    1. Non usare un integer literal come limite di array.
    2. Non usare un integer literal come parametro di esecuzione, come timeout o numero di porta.
    3. Non usare integer literal per selezionare opzioni di menu.
    4. Non usare integer literal per misurare la dimensione di una stringa o di dati; usa sizeof() e strlen() in C e C++ e .length() e .size in Java.
    5. Non usare stringhe literal per il nome di un file. Tuttavia, potresti creare stringhe literal.
    6. Non usare integer literal per indicizzare un array che contiene dati eterogenei.
    7. Non dichiarare un identificatore con un nome indicando un literal, come “trenta”.
  • Modularizzazione: Un programma è costituito da componenti che interagiscono.
    1. Non mettere tutto il tuo codice nella routine main().
    2. Infatti, non far svolgere troppo lavoro a nessuna routine.
    3. Se duplichi il codice varie volte, considera il fatto che un loop potrebbe funzionare meglio, oppure una subroutine.
    4. Se noti che l’indentazione è molto profonda, probabilmente non stai usando in maniera corretta le subroutine.
    5. Non reinventare le routine di libreria (a meno che il tuo lavoro non lo richieda). Controlla nei manuali per imparare qualcosa su sprintf() e atoi() per esempio.
    6. Usa i file header in C e C++ (file header hanno nomi che finiscono con .h) per definire tutte le costanti necessarie ai file multipli e dichiara tutte le subroutine esportate fra i file. Ma non mettere il corpo delle subroutine nei file header (con la rara eccezione delle subroutine in linea).
  • Formattare: il tuo programma dovrebbe essere facile da leggere.
    1. Guarda su http://geosoft.no/development/javastyle.html per dei chiarimenti sulla formattazione e altri problemi di presentazione. Questo riferimento è specifico per Java, ma è valido anche per altri linguaggi.
    2. Prova a restringere tutte le tue linee a 80 caratteri; molte persone vedono il codice in una finestra di 80 colonne per ragioni storiche.
    3. Non usare sia tabulazioni che spazi per l’indentazione, in quanto non tutti gli editor di testo trattano le tabulazioni come esattamente 8 spazi.
    4. Segui un percorso di indentazione consistente che rifletta la struttura di controllo del programma.
    5. Non mettere molti spazi vuoti nel tuo programma. Una linea vuota fra subroutine è abbastanza.
    6. Diversi sistemi operativi terminano le linee in modi diversi. Se ti sposti fra Win32 (che usa \r\n), Unix (che usa \n), e MacOS (che usa \r) riformatta il tuo file per usare un metodo di conclusione consistente.
    7. Non impostare la parte eseguibile (Unix) nel tuo file sorgente.
  • Codice: Il tuo codice deve essere chiaro, gestibile, ed efficiente, in quest’ordine. Alcune delle regole in questa sezione sono molto specifiche; altre sono più generali.
    1. Non usare una sequenza di condizioni if che non hanno else se solo una può corrispondere; usa else if.
    2. Quando vuoi categorizzare input di testo, non enumerare i primi caratteri possibili.
    3. Usa operatori di spostamento anziché moltiplicazione per costruire grandi sistemi.
    4. In una condizione switch, controlla sempre il caso di default. Allo stesso modo, in una sequenza di condizioni if-then-else, usa un else finale.
    5. Tutte le chiamate di sistema possono fallire. Controlla sempre il codice di ritorno, e usa perror() per segnalare il fallimento.
    6. I boolean dovrebbero sempre usare il tipo boolean in Java, bool in C++, e integer 0/1 in C. Non usare caratteri t e f, e non usare -1 e 1.
    7. Usa i loop per inizializzare strutture di dati se possibile.
    8. Usa ogni variabile e ogni campo di una struttura per esattamente uno scopo. Non caricare troppo a meno che non ci sia una ragione eccellente per farlo.
    9. Non usare lo stesso identificatore sia per un tipo, una variabile, e un nome di un file, anche se cambi la capitalizzazione. È molto confusionario.
    10. Se stai modificando dati con htonl() o una routine simile prima della trasmissione di rete, non modificare i dati presenti. Crea una seconda struttura di dati.
    11. Cerca di non usare variabili globali o non locali. Dichiara ogni variabile nella portata più piccola possibile. Ci sono usi legittimi di variabili non locali, ma assicurati di averne davvero bisogno.
    12. Programmi in Shell, Perl e Python dovrebbero avere la loro linea #! nella prima linea del file; altrimenti, la linea è solo un commento.
    13. Cerca di evitare la codifica di casi speciali. Puoi sempre usare pseudo dati o altri metodi di strutture di dati che ti permettono di trasformare casi speciali in casi regolari.
  • Compilatori: Lasciati aiutare da loro per trovare errori.
    1. Invoca sempre compilatori con tutti gli avvertimenti abilitati. Per C e C++, usa il -Wall Su Java, usa _Xlint:all –deprecation, e usa il programma pmd per ottenere consigli per uno stile migliore. Per Python, usa –t –W all.
    2. Tutti i programmi Perl dovrebbero essere eseguiti con il flag –w e dovrebbero avere use strict. Tutti gli script cgi-bin di Perl dovrebbero avere anche il flag –T.
  • L’utilità make: Usala, e usala bene.
    1. Un makefile dovrebbe sempre avere una formula “pulita” che dovrebbe rimuovere tutti i file che possono essere ricostruiti da altre formule nel makefile, fra cui gli oggetti e gli eseguibili.
    2. Se il tuo progetto ha più di un file sorgente, il makefile dovrebbe generare file object (.o) quando serve e collegarli assieme.
    3. Il makefile dovrebbe essere scritto in modo che se dovessi eseguire make due volte di fila, la seconda esecuzione non comporti la ricompilazione.
    4. Ogni formula dovrebbe creare un file specificato nel suo target.
    5. Ogni formula dovrebbe usare ogni file specificato nella sua lista di prerequisiti.
    6. Impara a usare le regole dei target come .c.o per evitare makefile ripetitivi.
    7. Se hai solo un codice sorgente C o C++, l’eseguibile dovrebbe avere lo stesso nome (senza l’estensione .c o .cpp).
    8. Assicurati di elencare tutti i file .h richiesti dove necessari. Considera l’utilizzo di makedepend per generare la lista di prerequisiti per te.
  • Documentazione: Non è solo per gli studenti. Ti aiuta anche a scrivere un programma!
    1. Aggiungi la documentazione mentre scrivi il programma. Puoi sempre modificare con il cambiamento del design.
    2. Includi documentazione esterna: Come fa una persona a compilare ed eseguire il programma, e cosa dovrebbe fare? La documentazione esterna potrebbe essere in un file separato; per piccoli progetti, potrebbe essere un commento nel file sorgente singolo.
    3. Includi documentazione interna: quali algoritmi e strutture di dati stai usando? Una panoramica può essere in un file separato, ma solitamente la documentazione interna è posta nelle routine specifiche, dichiarazioni, e passaggi che descrive.
    4. Controlla tutto il tuo programma e documentazione per errori di ortografia. Non è educato condividere lavori incorretti, e rispecchia una mancata attenzione ai dettagli.
    5. Controlla tutta la documentazione (e messaggi di output) per errori grammaticali.
    6. I programmi sono molto più leggibili se metti un piccolo commento nella parentesi di chiusura. Per esempio, le parentesi che chiudono una condizione possono avere un commento come “se il valore è buono”. Una parentesi che chiude un loop può avere un commento come “per ogni linea di input”. Una parentesi che chiude una procedura può avere un commento che nomina semplicemente la procedura. Una parentesi che chiude una classe può avere un commento che dice “classe” e poi il nome della classe.

Leave a Comment

Your email address will not be published. Required fields are marked *