In questo capitolo diamo alcuni suggerimenti su come formattare il proprio codice per renderlo più leggibile, comprensibile e portabile. Ovviamente, siete liberi di seguire oppure ignorare questi suggerimenti; seguendoli, tuttavia, faciliterete la comprensione dei vostri programmi a tutte le persone che, avendo letto questo manuale, hanno acquisito familiarità con le regole di scrittura degli esempi.

Regole di formattazione:

• il corpo dei cicli WHILE, REPEAT e FOR deve essere rientrato di almeno due caratteri fino al LOOP, UNTIL o NEXT corrispondente, che va allineato con il rispettivo metodo:

WHILE test
  istruzione
  ..
LOOP

REPEAT
  istruzione
  ..
UNTIL test

FOR id = v1 TO v2
  istruzione
  ..
NEXT

• il corpo di IF va rientrato di almeno due caratteri fino al rispettivo ELSE (se presente) o FI; ELSE e FI vanno allineati con il rispettivo IF, mentre il corpo del ramo ELSE va rientrato come già indicato:

IF test
  istruzione
  ..
ELSE
  istruzione
  ..
FI

• le direttive !ifdef/!ifndef - !else - !endif vanno allineate come IF - ELSE - FI:

!ifdef MS_DOS
   !include "dosspec.prt"
!else
   !include "unxspec.prt"
!endif

• il corpo di SWITCH va rientrato di almeno due caratteri fino al rispettivo OFF; il corpo di ogni voce ON o OTHER va ulteriormente indentato di due caratteri:

SWITCH exp [func]
  ON v1[, v2..]
    istruzione
    ..
  ONC v3[, v4..]
    istruzione
    ..
  OTHER
    istruzione
    ..
OFF

• il corpo di ogni UDF va indentato di almeno due caratteri rispetto alla dichiarazione FUNCTION e deve essere separato da una linea bianca da essa; l'ultimo RETURN va allineato con FUNCTION:

FUNCTION NomeFunzione(par..)

  istruzione
  ..
RETURN exp

• se il valore ritornato da una funzione è sempre ignorato (cioè la funzione è una procedura), omettere l'espressione che segue RETURN; ad esempio, ciò vale generalmente per le funzioni predefinite ONSTART e ONEND;
• le parole riservate (metodi, funzioni di libreria, identificatori predefiniti), le costanti e le etichette vanno scritte tutte in MAIUSCOLO; i nomi degli identificatori locali vanno scritti tutti in minuscolo, come anche i nomi delle direttive; i nomi delle UDF e le variabili pubbliche vanno Capitalizzate; con queste convenzioni risulta semplice, ad esempio, individuare l'errore comune che consiste nell'accedere ad una variabile pubblica da una UDF fuori da PSET e PUB: se in una funzione utente una variabile con l'iniziale maiuscola non è identificatore sotteso da PSET oppure dentro la funzione PUB, il codice è sbagliato. Per rendere più intellegibili gli identificatori composti da più parole, se sono capitalizzati o in minuscolo rendere maiuscola l'iniziale di ogni parola interna all'identificatore, mentre se sono tutti maiuscoli separare le parole con una sottolineatura ('_'); ciò vale anche per i nomi di UDF; esempio:

!ifdef ITALIANO

  CONST DEF_DAYS = "Dom Lun Mar Mer Gio Ven Sab"
  CONST DEF_MONTHS = "Gen Feb Mar Apr Mag Giu Lug Ago Set Ott Nov Dic"
  CONST TODAY_IS = "Oggi è: "

!else

  CONST DEF_DAYS = "Sun Mon Tue Wed Thu Fri Sat"
  CONST DEF_MONTHS = "Jan Feb Mar Apr May Jun Jul Ago Sep Oct Nov Dec"
  CONST TODAY_IS = "Today is: "

!endif
FUNCTION GiornoMeseAnno(data)
RETURN CDOW(data) " " DAY(data) CMONTH(data) " " YEAR(data)

Oggi = DATE()

DAYS = DEF_DAYS
MONTHS = DEF_MONTHS
CONSOLELN TODAY_IS GiornoMeseAnno(Oggi)

• se una riga di codice eccede gli 80 caratteri, utilizzare il carattere '\' di fine riga spezzandola in due o più righe di lunghezza inferiore; in questo modo il codice può essere letto senza far scrollare orizzontalmente il testo;
• utilizzare !ifdef MS_DOS (o UNIX o WINDOWS) per isolare le parti di codice dipendenti dal sistema operativo;
• limitare allo stretto indispensabile l'impiego di FUNC, per ottenere un'esecuzione più veloce e soprattutto il controllo sul numero di parametri con cui una funzione è invocata;
• inserire il parametro -k (ad esempio attraverso la riga #!) qualora nel programma figurino dei percorsi relativi e si voglia utilizzare lo script sia sotto Unix™ che sotto Ms-Dos™; evitare, a tal fine, la specifica dei nomi di drive;
• utilizzare quanto più possibile le costanti, evitando di specificare più volte gli stessi valori (ciò facilita la manutenzione ed evita i cosiddetti errori di copiatura);
• limitare l'accesso e la modifica delle variabili pubbliche da parte delle UDF; passare come parametri le variabili a cui si desidera accedere ed utilizzare l'operatore di passaggio per riferimento esplicito (@) per indicare che la variabile può essere modificata dalla funzione;
• strutturare il codice in modo da mantenere brevi le UDF; utilizzare il divide-et-impera estensivamente, per evitare di ricopiare larghe porzioni di codice;
• si eviti l'introduzione di variabili per utilizzarle una sola volta; se possibile, ri-utilizzare le variabili (facendo attenzione a non mescolare i tipi, per evitare di disorientare chi esamina il codice) oppure nidificare le chiamate di funzione in modo da evitare del tutto istruzioni di SET superflue;
• inserire tutte le costanti utilizzate all'inizio del programma;
• commentare estensivamente il codice; utilizzare le direttive !bdoc/!edoc per inserire commenti multilinea;
• se il programma Proteus deve essere eseguito direttamente mediante la riga #!, utilizzare sempre il carattere '#' come inizio commento.

Il programma di esempio protform.prt può essere utilizzato per formattare con le regole di indentazione indicate un qualsiasi programma Proteus.

Convenzioni sui nomi

Laddove una certa tipizzazione sia auspicabile, per meglio indicare qual è l'utilizzo prevalente di una variabile o qual è il tipo di valore ritornato da una UDF si può far iniziare il suo nome con: