71 / 86
EMBEDDED
54 • NOVEMBRE • 2014
71
SOFTWARE
C++
e fa quindi distinzione fra un carattere maiuscolo e uno
minuscolo - gli identificatori sono combinazioni di caratte-
ri alfanumerici, in cui il primo carattere deve essere una
lettera dell’alfabeto (maiuscola o minuscola) o un caratte-
re di sottolineatura (underscore ‘_’), mentre i rimanenti
possono essere lettere, cifre o underscore. Negli identifi-
catori, per i nomi non è ammesso utilizzare parole chiave,
e nemmeno caratteri speciali. Alcuni esempi di identifica-
tori validi sono:
nome
(l’uso di lettere minuscole è consentito)
Cognome
(l’uso di lettere maiuscole e minuscole è con-
sentito)
_alpha
(l’uso del carattere di sottolineatura all’inizio
è permesso)
_SOMMA
( l’uso del carattere di sottolineatura all’inizio
è permesso anche con lettere maiuscole)
numero_1
(l’uso di underscore e numeri è permesso,
assieme alle lettere)
INT
(qui l’uso della parola chiave riservata ‘int’ di
C++ è consentito, cambiando però le lettere
in maiuscolo)
Esempi di identificatori invalidi, fonte di possibili errori in
fase di compilazione, possono invece essere:
int
(è una parola chiave riservata di C++)
numero 1
(l’uso degli spazi non è consentito)
8alpha
(il primo carattere non è una lettera)
In aggiunta, una nota riguarda la chiarezza dell’identi-
ficatore: se da un lato, quando il contesto logico risulta
chiaro, l’uso di identificatori brevi e concisi per funzioni
e variabili favorisce la sintesi, giovando alla leggibilità,
dall’altro, quando il contesto è imprecisato, è consigliabile
scrivere identificatori in grado di precisare lo scopo dell’e-
lemento identificato. Quindi adottare, quando il contesto
lo richiede, identificatori con un nome più lungo, descrit-
tivo e legato al significato logico ricoperto all’interno del
programma: cosa del resto facilitata dal fatto che C++ per-
mette di scrivere nomi anche con un notevole numero di
caratteri.
Un’altra indicazione generale che si può fornire è sceglie-
re un’unica lingua – ad esempio quella inglese – utilizzan-
dola nell’intero ciclo di sviluppo del programma. L’uso
della lingua italiana può essere consigliabile se il team di
progettazione non conosce l’inglese, ma poiché quest’ulti-
ma lingua è usata come riferimento nella creazione della
stragrande maggioranza delle librerie, l’adozione dell’ita-
liano potrebbe costituire una limitazione non trascurabi-
le per la diffusione, e il riuso del codice in un contesto
internazionale di programmazione. Nei vari programmi è
anche consigliabile evitare l’uso simultaneo di lingue dif-
ferenti. Inoltre, la definizione degli identificatori, quindi
dei nomi, per le classi e i tipi dovrebbe privilegiare nomi
descrittivi, che riflettano la tipologia dei dati. È preferibi-
le un nome che identifichi una rappresentazione astratta
della classe, rispetto a una sua implementazione specifica.
Nella definizione di funzioni e procedure, è consigliabile
che il nome indichi, con un corretto livello di astrazione,
ciò che la funzione calcola, o i vari task che la procedura
esegue.
Per le variabili, è bene scegliere fin dall’inizio gli identi-
ficatori in modo opportuno, tenendo presente che sarà
improbabile, in fase di debugging e manutenzione del
programma, che verranno cambiati. Qui, analogamente ai
discorsi fatti in precedenza, il principio è utilizzare indica-
tori con nomi brevi nel caso di variabili locali con un uso
chiaro nel relativo contesto, e nomi più lunghi e descrittivi
per le variabili con un campo di validità globale.
Codice per sistemi critici,
i passi falsi da evitare
Quando si utilizza il linguaggio C++ nello sviluppo di un
sistema safety-critical, ci sono alcuni specifici aspetti su
cui occorre porre particolare attenzione. Qui ne eviden-
ziamo alcuni.
Limitare l’uso del preprocessore.
Quando si tratta di
sistemi embedded critici per la safety, è bene rispettare
alcune limitazioni a cui è soggetto l’utilizzo del preproces-
sore, ossia il programma che riceve ed esegue le diretti-
ve (le righe che iniziano con il carattere #) , producendo
codice sorgente per il compilatore. In sostanza, l’uso del
preprocessore viene limitato soltanto per l’implementa-
zione delle direttive #include guard, evitando l’uso ma-
cro complesse e di inclusioni multiple. Come prescrive lo
standard di codifica HIC++, dovrebbero essere utilizzate
solo le seguenti forme di direttive #include:
Fonte PQRA
Ecco poi alcuni esempi di conformità, e non conformità,
del codice indicati nelle linee guida HIC++:
Fonte PQRA