[OT] Scrivere codice solido

[Gil Mour]

Ti faccio un esempio semplice.
Nell'azienda in cui lavoro abbiamo sviluppato un prodotto proprietario che fa una certa cosa.

Successivamente abbiamo avuto l'esigenza di integrarlo in un ambiente piu complesso e completo, con delle funzionalità aggiuntive: guarda caso la scelta è ricaduta su un progetto open source molto affermato.

L'integrazione via codice è stata (e per certi versi lo è tuttora) una operazione pesantissima che ha portato via numerose risorse all'azienda, in termini di tempo.

Una cosa che ci ha fatto risparmiare forse più della metà del tempo è stata il fatto che il codice era ben documentato, commentato, e scritto in maniera chiarissima e leggibile, il che ci ha permesso di capire dove intervenire in tempi ragionevolmente brevi.

D'altra parte, un qualunque progetto open source o sviluppato in team, avrebbe eventualmente vita brevissima perchè se qualcuno 'contribuisce' con del codice illegibile e difficilmente rielaborabile quel determinato modulo è destinato a non essere mai utilizzato.

Inoltre, la gestione di testing,debugging e ottimizzazione di un codice scritto male ( VVoVe: ) è una pratica devastante e poco fruttosa.

Poi è chiaro che se uno si deve scrivere un modulo stand alone che calcola l'area di un quadrato, che una volta compilato non verrà piu modificato, lo puoi scrivere pure tutto su una riga sola col blocco note e che dio te la mandi buona se vuoi riutilizzare una sola funzione per cacolare, che so, la diagonale di quello stesso quadrato

[byaur]

ma è naturale che l'esempio che ho postato e BELLISSIMO ma nel mondo lavorativo e impraticabile al 99% delle volte...



però non ditemi che quel codice non è bello a vedersi...

dai...

[Gil Mour]

Ma certo, quella è una cosa spettacolare, pero è tutto un altro discorso

[unomichisiada]

La virtù come al solito sta nel mezzo: il codice non dovrebbe essere eccessivamente compatto e "stiloso" perchè spesso risulta illeggibile ma neanche troppo prolisso. I commenti dovrebbero esserci ma solo quando servono, in altre parole non conta la quantità ma la qualità dei commenti. Per spiegarmi meglio, se c'è un algorimo complesso con vari casi da gestire è buona norma farne precedere la codfica da una speigazione dell'algoritmo e dei casi che gestisce, è una cosa negativa invece commentare ogni singola istruzione con roba tipo: //assegnamo NULL al padre del nodo o //sommiamo x a b, quste sono cose che devono capirsi dal codice se i nomi degli identificatori sono stati scelti bene. I commenti in linea generale vanno messi accanto ad istruzioni che influenzano il flusso di esecuzione e solo quando effettivamente forniscono un valore aggiunto di chiarezza. Anche il modo di commentare è importante. Ad esempio accanto ad un ciclo for che effettua la somma di n numeri si può scrivere //iteriamo da zero a n e sommiamo oppure //effettua la somma degli n numeri, con ovvia preferenza per il secondo.Infine l'indentazione é un must e la scelta degli identificatori dovrebbe essere ragionevole,comprensibili, non troppo brevi ma nenche chilometrici.

[a.manchinu]

Anzi tutto grazie a tutti coloro che hanno voluto intervenire.

Nei post precedenti si è fatto riferimento agli standard da seguire per produrre un buon codice, il che mi fa dedurre che comunque esiste un "DTD" (per dirla in linguaggio xml)cioè un insieme di regole scritte e certificate che descriva in generale (o in particolare)le direttive da seguire quando si sviluppa del codice. Questo per renderlo il più chiaro, robusto e portabile possibile.

Qualcuno saprebbe indicarmi dove poter trovare qualcosa del genere?

Grazie

[stai_tranquillo]

Originariamente inviato da FinalFantasy
secondo me, il codice lo puoi scrivere anche sotto sopra: alla fine basta che lo capisci tu e il compilatore...poi se vuoi seguire gli standard, buona fortuna:

devi usare un'indendazione di questo tipo:

int main()
  {
    //istruzione
  }

mettere i commenti ad ogni rigo (o quasi)

anteporre, nei nomi delle variabili, i se sn interi, f se sono float eccetera. Es.:

int i_risultato;

scrivere i nomi delle funzioni con la prima lettera maiuscola.

Francamente io non rispetto nessuna di queste regole , tranne l'indendazione che la faccio così

int main()
{
  //ciao
}

mammamia, ma lavori o programmi per sport?



è questo che rende dozzinale il lavoro dei programmatori al girno d'oggi: l'essere confusi con le masse che come te praticano nel disordine puro e nell'ignoranza deghli standard.



Comunque, la domanda era "codice sicuro e stabile"


e la risposta, è che per scrivere codice stabile, basta progettare bene prima il tutto, poi implementarlo seguendo le regole del buonsenso (controlli, nessuna eccezione a vuoto, ecc.ecc.)
insomma, scrivere progettando e inventando man mano è il nemico numero uno della stabilità.
Poi viene il disordine, l'approssimazione, l'ignoranza..

Per scrivere codice sicuro, ci sono miriadi di libri applicabili a tutti i linguaggi. Basta prenderne uno e fare un pò di esperienza