[Soci SLIP] Da grande farò il programmatore

[Lucio Crusca]

In data Friday 22 March 2013 15:34:32, dipsie ha scritto:
> Aggiungo anch'io un paio di consigli:
> 
> 13. Scrivete codice sicuro, dove "sicuro" va inteso nel senso più ampio del
> termine: controllate i valori di ritorno delle funzioni, le eccezioni, i
> puntatori a null (e costrutti simili che utilizza il vostro linguaggio
> preferito).

Queste sono le regole per un codice "robusto", più che "sicuro". È vero che il 
codice robusto ha delle ricadute positive in termini di sicurezza, ma non è 
sufficiente scrivere codice robusto perché sia anche sicuro. Esempio:

if (sqlexec("SELECT * FROM users WHERE name='" + userInput + "'"))
{
 // ...
}
else
{
 // ...
}

rispetta le regole di robustezza che hai detto, ma non è necessariamente 
sicuro (notare che la funzione sqlexec me la sono inventata di sana pianta, 
tanto per restare indipendente dal linguaggio).

> 13.1 Corollario - Scrivete codice completo: se utilizzate un "if", inserite
> l'"else" relativo, anche se non fa niente. Tornerà utile a chiunque leggerà
> il codice un commento come:
> if(mUser != null)
> { .... }
> else //se mUser è null
>     ; //non faccio nulla

Questa me la sono dimenticata semplicemente perché non la rispetto mai... 
(oppure non la rispetto mai perché me la dimentico sempre). Mea culpa. 
Aggiungerei però che un commento scritto bene sulla condizione dell'if può 
rendere ridondante un ramo else vuoto, quindi metterli entrambi (i commenti) 
non è sempre così necessario.

> La stessa cosa vale per gli "switch", il default case dovrebbe essere
> sempre presente.

Assolutamente d'accordo, soprattutto per chi programma in stile procedurale.

Per chi invece si avvicina alla programmazione orientata agli oggetti (nota 
anche con l'acronimo OOP), il consiglio è quello di non usare l'istruzione 
switch. Se una parte di codice richiede un'istruzione switch (o l'equivalente 
sequenza di "if" in cascata) è una certezza che non state applicando i 
concetti dell'OOP, almeno non fino in fondo. A volte però è talmente comodo 
metterci uno switch su 17 valori piuttosto che creare 17 classi diverse, che 
non si sta a fare i talebani e si usa lo switch. Attenti solo a non abusarne, 
in OOP lo switch rischia di essere un'arma a doppio taglio e ritorcersi contro 
al primo refactoring.

> 14. Siate coerenti: scegliete una politica di nomenclatura delle variabili
> e seguitela in tutto il codice. Lo stesso vale per le unità di misura, per
> l'uso delle parentesi, per l'indentazione del codice, per lo "stile" di
> programmazione...
> Più di una volta sono impazzito a cercare di capire un codice dove, ad
> esempio, la variabile uscita indicava il valore dell'ingresso...

Parole sante.

> PS: per veri programmatori esperti (in C): http://www.ioccc.org/

Questa roba è peggio del perl! :o