Riepilogo delle raccomandazioni
|
|
C++ Manuale di Stile (Edizioni Infomedia) Riepilogo delle raccomandazioni |
Ho pensato di fare cosa utile rendendo disponibile
in formato HTML l'elenco delle raccomandazioni discusse all'interno
del libro. Questo sia per i potenziali lettori sia per chi, avendo
acquistato il libro, vuole avere la possibilita' di distribuire
delle copie dell'elenco, eventualmente modificate, all'interno
di un team di sviluppo.
Per chi non avesse letto il libro, e' importante osservare che tutte le
raccomandazioni non vengono "imposte" al lettore senza giustificazione,
ma derivate da una analisi delle alternative, valutando le ragioni di
ogni scelta nell'ottica della programmazione professionale.
E' ora disponibile on-line l'
errata corrige del libro.
Raccomandazione 1
Utilizzare identificatori piu' lunghi e descrittivi
per gli elementi privi di contesto; limitare la lunghezza degli
identificatori quando il contesto aiuta a comprenderne il significato
logico.
Raccomandazione 2
Scegliete gli identificatori nel dominio del problema,
non in quello della soluzione.
Raccomandazione 3
Sviluppate delle convenzioni locali per i prefissi
piu' comuni, come indici e numero di elementi; non lasciate pero'
che il prefisso prenda il sopravvento sul corpo dell'identificatore.
Raccomandazione 4
Evitare nomi che differiscono solo nel case o solo
per caratteri simili, come 1 ed l ("uno" ed "elle
minuscola") oppure 0 ed O ("zero" ed "o maiuscola").
In realta' sarebbe opportuno evitare totalmente l'uso dei numeri
negli identificatori.
Raccomandazione 5
Cercate di evitare l'uso contemporaneo di piu lingue:
sceglietene una (preferibilmente l'Inglese) e restate coerenti
con tale scelta durante l'intero sviluppo.
Raccomandazione 6
Scegliete i nomi delle classi dal dominio del problema;
il nome dovrebbe normalmente rappresentare il tipo di dato astratto,
non la specifica implementazione.
Raccomandazione 7
Funzioni "pure" devono avere un nome che
rappresenti adeguatamente il risultato restituito.
Raccomandazione 8
Funzioni con side-effects (procedure) devono avere
un nome che descriva ad un giusto livello di astrazione tutti
i compiti eseguiti. Usate un verbo seguito da un complemento oggetto
per le funzioni non membro, ed un verbo per le funzioni membro,
lasciando l'oggetto implicito.
Raccomandazione 9
Scegliete gli identificatori di variabile e costante
per rappresentarne l'uso, riferendovi al dominio del problema
e non all'implementazione; utilizzate identificatori corti se
il loro uso e' chiarito dal contesto locale, ed identificatori
lunghi per variabili globali o con lifetime estesa.
Raccomandazione 10
Sviluppate ed adottate una convenzione di codifica
che permetta una scelta di nomi consistente tra gli sviluppatori.
Raccomandazione 11
Ogni include file deve contenere un meccanismo che
eviti le definizioni multiple, e possibilmente anche le inclusioni
multiple.
Raccomandazione 12
Utilizzare nomi di file unici in un ampio contesto:
se il file contiene l'header o l'implementazione di una classe,
usare il nome della classe seguito da una estensione opportuna.
Raccomandazione 13
Se il vostro progetto deve essere portabile su altre
piattaforme, isolate le parti dipendenti dall'hardware e dal sistema
operativo e spostatele in files separati. Considerate comunque
l'opportunita' di definire delle classi intermedie per isolare
l'applicazione dal sistema.
Raccomandazione 14
Limitate l'uso di funzionalita' specifiche del compilatore;
spostate sempre le parti di codice dipendenti dal compilatore
in files separati.
Raccomandazione 15
Se l'accesso ad una classe all'interno di un header
file avviene solo tramite reference o puntatore, non includete
l'header di tale classe, ma dichiarate semplicemente l'identificatore
della classe nell'header stesso.
Raccomandazione 16
Se utilizzate gli header precompilati, includete
gli header di libreria per primi, poi gli header piu' stabili,
ed infine quelli piu' frequentemente modificati; usate il meccanismo
del vostro compilatore per fermare la precompilazione dopo gli
header di sistema o dopo quelli piu' stabili.
Raccomandazione 17
Racchiudete i nomi degli header di libreria tra <>
e degli header privati tra "".
Raccomandazione 18
Non specificate le directory nei file header inclusi:
utilizzate il supporto del compilatore per specificare le directory
da utilizzare.
Raccomandazione 19
Utilizzate una diversa directory per i moduli oggetto
di ogni progetto.
Raccomandazione 20
Utilizzate linee vuote per separare elementi logicamente
distinti, anche all'interno della singola funzione o blocco applicativo.
Cercate di limitare gli elementi decorativi nei commenti, che
deviano l'attenzione di chi legge.
Raccomandazione 21
Indentate gli statement subordinati sotto agli statement
da cui dipendono.
Raccomandazione 22
Definite uno standard di indentazione che sia rispettato
da ogni membro del team di sviluppo.
Raccomandazione 23
Definite uno standard interno sulla lunghezza e l'uso
del tab che sia rispettato da tutti i programmatori del team.
Raccomandazione 24
Definite uno standard per la sequenza delle dichiarazioni
in un file header, ed aderitevi strettamente ogni volta che sia
possibile.
Raccomandazione 25
Il file di implementazione deve definire ogni elemento
nell'esatto ordine di dichiarazione del file header associato.
Raccomandazione 26
Usare una spaziatura uniforme tra gli operatori e
gli operandi; vi sono sicuramente eccezioni, ma anche su queste
cercate di essere consistenti con un vostro standard di layout.
Raccomandazione 27
Utilizzate le parentesi solo quando sono necessarie
ai fini semantici, o per chiarire la priorita' e/o l'associativita'
degli operatori.
Raccomandazione 28
Spezzate le espressioni troppo complesse, in particolar
modo le espressioni booleane, assegnandone una sottoespressione
significativa ad una variabile locale.
Raccomandazione 29
Utilizzate sempre le parentesi per chiarire il significato
di espressioni che coinvolgono operatori bit-wise ed altri operatori.
Questo e' valido anche quando gli operatori bit-wise sono overloaded,
come nel caso degli operatori << e >> per l'I/O su
stream.
Raccomandazione 30
Specificare il nome dei parametri formali sia nel
file header che nel file di implementazione, ed utilizzare gli
stessi identificatori in entrambi i contesti.
Raccomandazione 31
Se un parametro formale non e' utilizzato, racchiudere
il suo nome in un commento nel file implementazione.
Raccomandazione 32
Evitare l'allineamento nelle dichiarazioni di variabili:
utilizzare semplicemente una spaziatura standard.
Raccomandazione 33
Dichiarare una sola variabile in ogni statement di
dichiarazione.
Raccomandazione 34
Variabili di tipo puntatore (o di tipo riferimento)
vanno dichiarate giustapponendo il simbolo * (o il simbolo &)
al tipo dell'oggetto puntato (o referenziato), ovvero come nell'esempio
che segue:
int* x ;
Raccomandazione 35
Se utilizzate tipi complessi, ad esempio puntatori
a funzione, dichiarate un tipo apposito con typedef.
Raccomandazione 36
Utilizzate sempre la struttura di controllo che meglio
esprime le azioni che intendete compiere ad un livello piu' astratto.
Raccomandazione 37
Preferire il break o un flag al return per uscire
dai loop.
Raccomandazione 38
Se il body di uno statement e' vuoto, posizionate
il ';' o un blocco vuoto su una riga separata, ed annotatelo con
un commento.
Raccomandazione 39
Nei cicli for, utilizzate un limite inferiore inclusivo
ed un limite superiore esclusivo.
Raccomandazione 40
Usare il nesting con discernimento: talvolta e' possibile
linearizzare la struttura del codice con un impatto trascurabile
sulle prestazioni.
Raccomandazione 41
Ogni clausola di uno statement switch va terminata
con break o con return, salvo i casi di fall-through intenzionale
che devono sempre essere commentati.
Raccomandazione 42
Introdurre sempre una clausola default negli statement
switch; se il controllo non deve mai raggiungere tale clausola,
inserire una asserzione falsa come corpo, in modo che ogni violazione
delle assunzioni fatte venga segnalata a run-time.
Raccomandazione 43
Strutturate la dichiarazione di una classe ordinando
le sezioni di accessibilita' come pubblica/protetta/privata, seguite
da classi, funzioni, operatori friend.
Raccomandazione 44
All'interno di ogni sezione, seguite un layout il
piu' vicino possibile a quello di un file header, con le dovute
differenze per i membri statici.
Raccomandazione 45
La definizione delle funzioni inline non va inserita
all'interno della dichiarazione della classe, ma al di fuori di
essa.
Raccomandazione 46
Nei commenti, cercate di spiegare le vostre intenzioni,
non come le state realizzando. Preferite i commenti introduttivi
a quelli esplicativi, che spesso si possono evitare scrivendo
codice piu' chiaro.
Raccomandazione 47
Indentare i commenti allo stesso livello del codice
a cui si riferiscono.
Raccomandazione 48
Evitare di inserire esplicitamente valori numerici
nel codice: definire invece delle opportune costanti.
Raccomandazione 49
Non utilizzare #define per definire le costanti,
ma const o enum.
Raccomandazione 50
Usare enum per raggruppare costanti omogenee; utilizzare
const per dichiarare costanti eterogenee.
Raccomandazione 51
Se una o piu' costanti sono utilizzate solo all'interno
di una classe, o come parametri per le funzioni membro di una
classe, le costanti vanno definite internamente alla classe, e
dotate del giusto grado di visibilita' (private, protected o public)
a seconda dell'impiego che possono avere.
Raccomandazione 52
Utilizzare sempre il tipo piu' opportuno per ogni
variabile; non abusare dei tipi int o float: talvolta unsigned
puo' essere piu' indicato.
Raccomandazione 53
Non utilizzare i tipi predefiniti esplicitamente
qualora sia possibile (e significativo) nascondere l'implementazione
definendo un opportuno tipo con typedef od enum.
Raccomandazione 54
Non dichiarate diverse variabili logicamente correlate
se definendo una opportuna classe e' possibile riunirle in un'unica
struttura.
Raccomandazione 55
Dichiarare le variabili in modo da avere vita e scope
minimi, ovvero all'ultimo istante possibile, e con il massimo
grado di annidamento possibile.
Raccomandazione 56
Inizializzare le variabili al momento della dichiarazione
ogni volta che e' possibile; altrimenti, considerare la possibilita'
di astrarre parte del codice in una funzione.
Raccomandazione 57
All'interno dei blocchi, non dichiarare variabili
aventi lo stesso identificatore di una variabile visibile nello
stesso scope.
Raccomandazione 58
Considerate sempre le variabili locali static come
candidati a divenire membri di una opportuna classe: se si trovano
all'interno di funzioni membro, possono divenire membri della
stessa classe; se si trovano in funzioni non-membro, dovra' essere
introdotta una nuova classe, se corrisponde ad una astrazione
significativa.
Raccomandazione 59
Non utilizzare una variabile dichiarata in uno statement
di selezione o di iterazione, al di fuori dello statement stesso:
il codice non rispettera' lo standard ISO C++.
Raccomandazione 60
Minimizzare l'uso delle variabili globali.
Raccomandazione 61
Se e' necessario introdurre un oggetto globale, costruire
una opportuna classe che gestisca l'elemento come una risorsa,
eventualmente con gli opportuni costrutti di locking.
Raccomandazione 62
Non dichiarare funzioni private come virtual.
Raccomandazione 63
Se si modifica la visibilita' di una funzione in
una classe derivata, motivare le ragioni della modifica con un
opportuno commento.
Raccomandazione 64
Non eccedere nel numero di costruttori: introducete
solo quelli realmente necessari. Attenzione ai costruttori con
un solo parametro, che sono a tutti gli effetti operatori di conversione.
Raccomandazione 65
Non chiamare funzioni virtuali all'interno del costruttore:
non verranno in ogni caso legate dinamicamente, ma sempre legate
staticamente. Se e' necessario chiamarle, introducete comunque
un commento esplicativo.
Raccomandazione 66
Parametri di tipo puntatore o reference nei costruttori
dovrebbero sempre essere const, in modo tale che il costruttore
non modifichi i suoi parametri.
Raccomandazione 67
Ogni classe avente funzioni virtuali, o utilizzata
come classe base in una gerarchia di derivazione, deve dichiarare
il distruttore come virtual. Negli altri casi, commentate opportunamente
l'header della classe, cosi' che l'introduzione di classi derivate
coincida con la modifica del distruttore in virtual.
Raccomandazione 68
Nei costruttori di oggetti composti da piu' parti,
inizializzate i sotto-oggetti con la tecnica <whole> :
<part>, non tramite assegnazione. L'assegnazione e' di norma
preferibile per i sottocomponenti di tipo base.
Raccomandazione 69
Una classe che abbia membri allocati dinamicamente
deve definire un opportuno costruttore di copia.
Raccomandazione 70
Una classe che abbia membri allocati dinamicamente
deve definire un opportuno distruttore.
Raccomandazione 71
Evitare, se possibile, l'uso di oggetti globali all'interno
dei costruttori. Se e' necessario, utilizzate la tecnica di Schwarz
per garantire il corretto ordine di inizializzazione.
Raccomandazione 72
I costruttori ed i distruttori non dovrebbero essere
inline, tranne per classi base molto semplici, dalle quali non
di derivera' in futuro, o nei casi in cui siano vuoti.
Raccomandazione 73
Non definire dati pubblici o protetti: tutti i dati
devono essere privati.
Raccomandazione 74
Non definire metodi di get/set pubblici, e limitarsi
il piu' possibile anche nel caso di metodi protected: cercate
di identificare piu' chiaramente le responsabilita' ed i compiti
della classe, anziche' esporne i dati. Se definite metodi di get/set
protected, usate astrazioni a livello logico.
Raccomandazione 75
Limitare l'uso di struct all'interfacciamento con
codice C; utilizzare le classi in tutti gli altri casi.
Raccomandazione 76
Funzioni od operatori pubblici che restituiscano
puntatori o reference a campi di una classe devono restituirli
come puntatori/reference const.
Raccomandazione 77
Funzioni o operatori pubblici non devono restituire
il valore di un membro di tipo puntatore o reference, se non sotto
forma di puntatore const o reference const.
Raccomandazione 78
Non definite operatori di conversione pubblici che
restituiscano puntatori/reference a membri o membri puntatore/reference:
utilizzate invece funzioni membro dal nome esplicativo, che ricordino
al programmatore la sua responsabilita' nell'utilizzo del puntatore/reference
ottenuto, che deve comunque essere const.
Raccomandazione 79
In ogni classe, limitate il numero di chiamate a
funzioni virtuali dichiarate nella classe stessa.
Raccomandazione 80
Per ogni funzione virtuale dichiarata in una classe
e richiamata nel codice della classe stessa, documentare adeguatamente
nel file header della classe ogni contesto di chiamata. Specificate
chiaramente quali vincoli sul contesto verranno rispettati in
future versioni della classe (e rispettateli!) e quali possono
essere variati senza preavviso.
Raccomandazione 81
Nelle gerarchie di derivazione con ereditarieta'
singola, l'uso di inherited :: per qualificare la classe genitore
puo' semplificare significativamente la manutenzione della gerarchia
stessa.
Raccomandazione 82
L'uso della qualificazione esplicita con :: dovrebbe
essere limitato all'interno delle classi base (per ottenere l'early
binding con il metodo della classe stessa) o nelle classi derivate
(per richiamare i metodi delle classi base). Non dovrebbe essere
usato al di fuori di esse, dove oggetti delle classi vengono usati.
Raccomandazione 83
Funzioni che non modificano lo stato dell'oggetto
vanno dichiarate const; cio' andrebbe fatto sin dalla fase di
definizione dell'interfaccia della classe.
Raccomandazione 84
Se possibile, non modificate oggetti globali o sotto-oggetti
accessibili tramite puntatori all'interno di funzioni membro const,
e non eseguite input-output all'interno di esse. Se dovete farlo,
commentate adeguatamente il codice, e magari anche la dichiarazione
della funzione.
Raccomandazione 85
Dovendo modificare membri dato all'interno di un
oggetto, ammesso che cio' sia concettualmente corretto, dichiarate
i dati come mutable; in alternativa, usate const_cast all'interno
della funzione membro che deve modificare i dati, od un cast esplicito
se const_cast non e' disponibile.
Raccomandazione 86
Se un operatore viene ridefinito, la sua semantica
dovrebbe risultare il piu' possibile naturale; gli operatori della
stessa famiglia logica dovrebbero essere a loro volta ridefiniti
in modo che vengano preservate le usuali equivalenze semantiche.
Raccomandazione 87
Non ridefinite gli operatori || ed && se
non e' veramente necessario; se dovete farlo, aggiungete sempre
una linea di commento nel file header, richiamando esplicitamente
la mancanza di short-circuit nella valutazione.
Raccomandazione 88
Una classe che abbia membri allocati dinamicamente
deve definire un opportuno operatore di assegnazione.
Raccomandazione 89
Un operatore di assegnazione che esegua operazioni
distruttive sul suo operando di sinistra, deve per prima cosa
verificare la non-identita' dei due operandi.
Raccomandazione 90
Il parametro di destra di un operatore di assegnazione
dovrebbe essere const; nei rari casi in cui cio' non e' possibile,
commentare adeguatamente l'header della classe.
Raccomandazione 91
Il risultato di un operatore di assegnazione dovrebbe
essere di tipo void oppure un reference const alla classe per
la quale l'operatore e' definito.
Raccomandazione 92
Le funzioni friend non devono accedere ai dati privati
della classe; se necessario, definire delle funzioni inline private
di Get/Set, per accedere ai dati membro.
Raccomandazione 93
Legge di Demeter (formulazione "per oggetti")
Un metodo M della classe C dovrebbe richiamare solo
metodi della classe C, metodi delle sottoparti immediate di C,
metodi degli argomenti di M, metodi degli oggetti creati internamente
ad M o metodi di oggetti globali.
Raccomandazione 94
Non usate i reference per creare degli alias; se
dovete creare alias, utilizzate i puntatori.
Raccomandazione 95
Per ottenere il passaggio per riferimento, utilizzate
sempre i tipi reference e non i puntatori. Se il fine del passaggio
per riferimento e' di evitare la copia di un oggetto di grosse
dimensioni, che non verra' comunque modificato, dichiarare il
parametro come un reference const.
Raccomandazione 96
Limitare l'uso dell'aritmetica sui puntatori: in
molte occasioni, l'uso diretto degli array generera' codice piu'
leggibile, sicuro, ed altrettanto efficiente.
Raccomandazione 97
Utilizzate una classe Array basata su template anziche'
gli array C-style.
Raccomandazione 98
Utilizzate sempre delete[] per distruggere array
di oggetti, e delete per distruggere i singoli oggetti.
Raccomandazione 99
Dopo la chiamata a delete o delete[], assegnate il
valore NULL alla variabile nel caso si tratti di un membro di
una classe o di una variabile globale. Lo stesso vale se si tratta
di una variabile locale il cui scope si estende per molte righe
dopo la sua distruzione.
Raccomandazione 100
Minimizzate l'uso di puntatori a puntatore.
Raccomandazione 101
Evitate l'uso di parametri booleani; definite invece
un apposito tipo enumerato per le diverse opzioni. Il tipo puo'
essere definito internamente ad una classe per evitare la saturazione
dello spazio degli enumerati
Raccomandazione 102
Non restituite puntatori ad elementi statici o globali
come risultato delle funzioni.
Raccomandazione 103
Non restituite, come risultati di funzione, puntatori
a memoria allocata all'interno della funzione, e che debba essere
deallocata dal chiamante.
Raccomandazione 104
Se una funzione deve restituire dati creati dinamicamente,
considerate l'opportunita' di creare una classe wrapper che gestisca
l'allocazione/deallocazione dei dati.
Raccomandazione 105
Non restituite valori eterogenei come risultato delle
vostre funzioni; se necessario, utilizzate un ulteriore parametro
per codici di errore, o generate una eccezione a run-time.
Raccomandazione 106
Inserite asserzioni nel codice per verificare precondizioni,
postcondizioni ed invarianti. Le asserzioni vanno utilizzate per
trovare errori di codifica, non per gestire errori run-time dovuti
all'interazione con l'ambiente.
Raccomandazione 107
Non inserite codice che genera side-effect all'interno
delle asserzioni: tale codice non verra' compilato come parte
della release finale.
Raccomandazione 108
Se la condizione verificata all'interno di una asserzione
non e' di immediata comprensione, commentatela adeguatamente.
Raccomandazione 109
Evitate di scrivere funzioni troppo lunghe; se vi
sono importanti ragioni per non suddividere una funzione lunga
in sottofunzioni, documentate le motivazioni con un opportuno
commento.
Raccomandazione 110
Utilizzare le funzioni inline anziche' definire macro-funzioni
con #define.
Raccomandazione 111
Utilizzate le funzioni inline solo se vi sono concreti
motivi: il fatto che una funzione sia breve non giustifica di
per se' l'espansione in linea.
Raccomandazione 112
Utilizzare le funzioni inline solo quando l'overhead
di chiamata e' significativo rispetto al tempo di esecuzione del
corpo della funzione stessa. Funzioni di forwarding o funzioni
protected di accesso ai membri dato sono normalmente buoni candidati
all'espansione in linea.
Raccomandazione 113
Tutte le versioni overloaded di una stessa funzione
dovrebbero avere la stessa semantica, perlomeno ad un alto ma
riconoscibile livello di astrazione.
Raccomandazione 114
Non utilizzare i parametri di default per simulare
l'overloading in una sola funzione: una funzione dovrebbe svolgere
un unico compito.
Raccomandazione 115
Parametri di default devono essere forniti solo quando
la maggior parte delle chiamate sfruttera' effettivamente tali
parametri.
Raccomandazione 116
Limitare il passaggio per valore di oggetti di grandi
dimensioni, e la restituzione per valore di oggetti di grandi
dimensioni.
Raccomandazione 117
Evitare codice che dipende dalla lifetime di oggetti
temporanei; se cio' e' necessario per ragioni di efficienza, commentare
la porzione di codice in modo adeguato.
Raccomandazione 118
Se lavorate con oggetti di grande dimensione, non
utilizzare operatori postfissi; se create una classe con oggetti
di grandi dimensione, non definite operatori postfissi.
Raccomandazione 119
Utilizzate la derivazione pubblica o protetta solo
se state effettivamente modellando una relazione del tipo e'-un.
Negli altri casi, utilizzate l'ereditarieta' privata o il contenimento.
Raccomandazione 120
Non restiruire mai un puntatore ad una classe base
attraverso una funzione pubblica o protetta di una classe derivata
con ereditarieta' privata.
Raccomandazione 121
Se una funzione di una classe derivata come private
chiama una funzione virtuale della classe base, e' necessario
legarla staticamente alla funzione della classe base, evitando
la risoluzione dinamica della chiamata.
Raccomandazione 122
Non ridefinire funzioni virtuali di una classe base
non accessibile.
Raccomandazione 123
La derivazione privata da una classe base che chiama
al suo interno funzioni virtuali dovrebbe essere sostituita dal
contenimento diretto.
Raccomandazione 124
Non ridefinite le funzioni non virtuali delle classi
basi in classi derivate public o protected (ereditarieta' di
interfaccia); nel caso occorra farlo, verificate che non sia comunque
piu' corretto derivare come private (ereditarieta' di implementazione)
Raccomandazione 125
Se utilizzate il binding statico per eliminare l'ambiguita'
dovuta all'ereditarieta' multipla, commentate adeguatamente il
codice per prevenire problemi di manutenzione; considerate comunque
l'alternativa di utilizzare i puntatori a funzioni membro.
Raccomandazione 126
L'ereditarieta' fork-join accessibile deve sempre
essere virtuale.
Raccomandazione 127
L'ereditarieta' fork-join non accessibile non deve
mai essere virtuale.
Raccomandazione 128
Quando e' possibile, utilizzate l'ereditarieta' virtuale
ogni volta che derivate in modo pubblico o protetto.
Raccomandazione 129
L'ereditarieta' privata dovrebbe sempre essere non-virtual.
Raccomandazione 130
Attenzione all'overloading di funzioni parametrizzate
e non parametrizzate nei template, che puo' impedire l'istanziazione
con alcuni parametri. Preferibilmente, spostate le funzioni non
parametriche in una classe base.
Raccomandazione 131
Dati e funzioni membro di un template che siano indipendenti
dai parametri del template possono essere spostate in una classe
base da cui il template e' derivato.
Raccomandazione 132
Non usare un cast, di nessun tipo, quando e' possible
utilizzare l'operatore di qualificazione esplicita ::
Raccomandazione 133
Se e' realmente necessario convertire un puntatore
a classe base ad un puntatore a classe derivata, o in generale
invertire una conversione implicita, utilizzate l'operatore static_cast
e non un cast C-style. Se vi e' la possibilita' che la conversione
fallisca, utilizzate dynamic_cast.
Raccomandazione 134
Nei rari casi in cui e' realmente necessario convertire
oggetti const in oggetti non-const, utilizzate l'operatore const_cast.
Raccomandazione 135
Nei rari casi in cui sia realmente necessario eseguire
un cast che puo' fallire a run-time, utilizzate l'operatore dynamic_cast,
non il cast C-style.
Raccomandazione 136
Se e' realmente necessario eseguire un cast tra tipi
scorrelati, utilizzate l'operatore reinterpret_cast, non il cast
C-style.
Raccomandazione 137
In caso di possibile ambiguita', utilizzare un cast
esplicito anziche' appoggiarsi al meccanismo di cast implicito
del linguaggio.
Raccomandazione 138
Non richiedere mai un cast implicito o esplicito
da un array di oggetti di classe derivata ad un array di oggetti
di classe base.
Raccomandazione 139
Utilizzare gli stream di I/O anziche' printf ovunque
sia possibile.
Raccomandazione 140
Non assumete che il vostro codice sia portabile ad
un altra piattaforma o semplicemente ad un altro compilatore solo
perche' funziona con il vostro sistema e compilatore.
Raccomandazione 141
Compilate sempre il vostro codice con il massimo
numero di warning abilitati; eliminate i warning rimuovendone
la causa, non zittendo il compilatore. Evitate l'uso dei #pragma.
Raccomandazione 142
Non fate assunzioni arbitrarie sulle grandezze dei
tipi, specialmente sulle grandezze relative di short, int, long,
e puntatori. Usate i tipi standard per contenere le differenze
tra puntatori. Se e' necessario fare riferimento alla dimensione
di un tipo base, definite un apposito tipo utilizzando la compilazione
condizionale.
Raccomandazione 143
Non assumete un particolare layout di memorizzazione
per i tipi base.
Raccomandazione 144
Se usate i bit-field, non trattate mai una sequenza
di campi come una singola unita'.
Raccomandazione 145
Non fate assunzioni sul layout in memoria degli oggetti.
Raccomandazione 146
Non comparate puntatori a tipi diversi. Gli operatori
<, <=, >, >= sono definiti solo per puntatori che
puntano all'interno dello stesso array, o al primo elemento dopo
la fine dell'array stesso.
Raccomandazione 147
Non assumete che la chiamata di funzione comporti
la valutazione degli argomenti in un ordine particolare.
Raccomandazione 148
Gli operandi di un operatore con side-effect non
devono avere altre occorrenze nella stessa espressione.
Raccomandazione 149
Non utilizzate l'ereditarieta' per modellare relazioni
del tipo tutto-parti, che vanno modellate con il contenimento.
Raccomandazione 150
Quando possibile, utilizzate la composizione diretta
per i sotto-oggetti, non la composizione tramite puntatori.
Raccomandazione 151
Non utilizzate schemi di type-checking dinamico per
ottenere genericita': preferite invece l'uso dei template.
Raccomandazione 152
Se i tempi di ricompilazione dopo la modifica di
parti private delle classi sono troppo lunghi, minimizzate l'accoppiamento
tra le implementazioni delle classi usando una tecnica di isolamento.