Hardware Upgrade Forum - View Single Post

Ikon O'Cluster · 30-06-2009, 01:18

Cmq vorrei far presente che al di là dell'uso da abolire delle variabili globali... cosa di per sè oscena ed inutile... Ci sono tanti accorgimenti di buona programmazione. Ad esempio riscrivo la funzione:

Codice:

#define RET_OK 0
#define RET_ERR 1

int scelte_utente(void) {
	switch(stato) {
		case 1: clr_disp(); if(premo >= 1 && premo <= 4) stato = premo+1;
		case 2: setta_risoluzione(); break;
   		case 3: setta_temperaturaOK(); break;
		case 4: setta_datario(); break;
		case 5: setta_password(); break;
		case 0; return RET_OK;
		default: fprintf(stderr, "ERROR: Unknown Command!"); return RET_ERR;
	}

	// Never reached...
	fprintf(stderr, "ERROR: Code execution!");
	return RET_ERR;
}

Vediamo cosa c'è di buono:

1) Ho definito delle costanti di errore/successo che mi permettono di definire dei valori di ritorno in modo che il chiamante sappia cosa è successo. Ad esempio al posto di RET_ERR posso definire più tipi di errori con vari valori in modo da permettere di capire al chiamante anche quale errore si è verificato. In realtà esistono modi standard per gestire queste situazioni, ma alla buona senza stare troppo ad applicarsi, questo lo definirei un metodo di buon senso.

2) Quando si scrivono troppi if incascata o si mette uno switch (per aumentare la legibilità del codice) oppure si trova un metodo alternativo. Ti faccio notare che la mia scelta valuta 1 sola condizione rispetto ai tuoi 5 confronti. E' una banalità, ma è altrettanto banale ridursi ad un solo if. Devi considerare che riducendo le righe di codice, statisticamente si riduce anche il numero assoluto di errori contenuti.

3) Nel case va previsto sempre un caso default. Non si sa mai, ma un utente può sbagliare l'input, o tu puoi sbagliare codice, magari era corretto, ma magari fai una modifica e non lo è più.

4) Come nella nota 3 c'è un punto del codice mai raggiunto... e se modifico il codice e x sbaglio ci arrivo? Quanto tempo dovrà passare prima di accorgermene???

5) Stampare sempre sul stderr (e non sullo stdout) i messaggi di errore e strutturarli in maniera tale che siano facilmente individuabili, in modo da poter risolvere.

Non vorrei entrare nel filosofico, primo perchè non è il topic e secondo perchè sono ingegnere e come tale disprezzo la filosofia, però la programmazione ha una certa percentuale di arte, scrivere codice non è una cosa facile. Io non lo so fare bene, ma se c'è una cosa che mi sforzo di fare e di scriverlo pensando poche sacrosante cose:

1) Chi legge lo capisce? O parafrasando Einstein lo capirebbe anche la nonna? Quindi giù con i commenti... non dico uno ogni riga, ma anche se fosse non farebbe male. Mi raccomando istruzioni che racchiudano una logica, che non siano fuorvianti. Definite una variabili in più se questo aiuta a scrivere istruzioni più leggibili, tanto è probabile che il compilatore ottimizzi cmq e la elimini...

2) Se da qualche parte posso fare un errore allora devo programmare in modo da poterlo rilevare facilmente. E se posso fare un errore allora la legge di Murphy insegna che sarà il peggiore possibile. E per il corollario alla legge di Murphy si verificherà anche nel momento meno opportuno!

3) (Non è questo il caso, ma in generale...) I nomi delle variabili devono sempre esprimere con precisione il loro significato... non facciamo brutti riciclaggi di variabili, pur di rispermiare 4 byte!

Già con queste 3 regole, la musica comincia a cambiare. Il fondamento di ciò sta nel fatto che programmare è soprattutto un lavoro e farlo bene aumenta la produttività.

Scusa lefermops per questo post che alla fine sembra una lezione di buona programmazione, ma non era rivolto a te personalmente, credo che possa risultare utile a tanti lettori... Vedo miei colleghi che malgrado prossimi alla laurea programmano molto ma molto male, questo è grave... programmare è anche una responsabilità. Il software è pervasivo: c'è la possibilità che un giorno se lo ritrovi in mano qualcuno e se non è fatto bene può produrre danni. Era una affermazione seria malgrado alcuni leggendo si saranno fatti un sorriso: se io scrivo un algoritmo semmai un algoritmo genetico e poi qualcuno lo usa in medicina e semmai qualcun'altro muore x un bug di chi è la colpa? O di chi è la colpa quando due treni si scontrano perchè c'è un bug nel software? Intanto la gente muore...

30-06-2009, 01:18	#15
Ikon O'Cluster Registered User Iscritto dal: May 2009 Messaggi: 300	Cmq vorrei far presente che al di là dell'uso da abolire delle variabili globali... cosa di per sè oscena ed inutile... Ci sono tanti accorgimenti di buona programmazione. Ad esempio riscrivo la funzione: Codice: #define RET_OK 0 #define RET_ERR 1 int scelte_utente(void) { switch(stato) { case 1: clr_disp(); if(premo >= 1 && premo <= 4) stato = premo+1; case 2: setta_risoluzione(); break; case 3: setta_temperaturaOK(); break; case 4: setta_datario(); break; case 5: setta_password(); break; case 0; return RET_OK; default: fprintf(stderr, "ERROR: Unknown Command!"); return RET_ERR; } // Never reached... fprintf(stderr, "ERROR: Code execution!"); return RET_ERR; } Vediamo cosa c'è di buono: 1) Ho definito delle costanti di errore/successo che mi permettono di definire dei valori di ritorno in modo che il chiamante sappia cosa è successo. Ad esempio al posto di RET_ERR posso definire più tipi di errori con vari valori in modo da permettere di capire al chiamante anche quale errore si è verificato. In realtà esistono modi standard per gestire queste situazioni, ma alla buona senza stare troppo ad applicarsi, questo lo definirei un metodo di buon senso. 2) Quando si scrivono troppi if incascata o si mette uno switch (per aumentare la legibilità del codice) oppure si trova un metodo alternativo. Ti faccio notare che la mia scelta valuta 1 sola condizione rispetto ai tuoi 5 confronti. E' una banalità, ma è altrettanto banale ridursi ad un solo if. Devi considerare che riducendo le righe di codice, statisticamente si riduce anche il numero assoluto di errori contenuti. 3) Nel case va previsto sempre un caso default. Non si sa mai, ma un utente può sbagliare l'input, o tu puoi sbagliare codice, magari era corretto, ma magari fai una modifica e non lo è più. 4) Come nella nota 3 c'è un punto del codice mai raggiunto... e se modifico il codice e x sbaglio ci arrivo? Quanto tempo dovrà passare prima di accorgermene??? 5) Stampare sempre sul stderr (e non sullo stdout) i messaggi di errore e strutturarli in maniera tale che siano facilmente individuabili, in modo da poter risolvere. Non vorrei entrare nel filosofico, primo perchè non è il topic e secondo perchè sono ingegnere e come tale disprezzo la filosofia, però la programmazione ha una certa percentuale di arte, scrivere codice non è una cosa facile. Io non lo so fare bene, ma se c'è una cosa che mi sforzo di fare e di scriverlo pensando poche sacrosante cose: 1) Chi legge lo capisce? O parafrasando Einstein lo capirebbe anche la nonna? Quindi giù con i commenti... non dico uno ogni riga, ma anche se fosse non farebbe male. Mi raccomando istruzioni che racchiudano una logica, che non siano fuorvianti. Definite una variabili in più se questo aiuta a scrivere istruzioni più leggibili, tanto è probabile che il compilatore ottimizzi cmq e la elimini... 2) Se da qualche parte posso fare un errore allora devo programmare in modo da poterlo rilevare facilmente. E se posso fare un errore allora la legge di Murphy insegna che sarà il peggiore possibile. E per il corollario alla legge di Murphy si verificherà anche nel momento meno opportuno! 3) (Non è questo il caso, ma in generale...) I nomi delle variabili devono sempre esprimere con precisione il loro significato... non facciamo brutti riciclaggi di variabili, pur di rispermiare 4 byte! Già con queste 3 regole, la musica comincia a cambiare. Il fondamento di ciò sta nel fatto che programmare è soprattutto un lavoro e farlo bene aumenta la produttività. Scusa lefermops per questo post che alla fine sembra una lezione di buona programmazione, ma non era rivolto a te personalmente, credo che possa risultare utile a tanti lettori... Vedo miei colleghi che malgrado prossimi alla laurea programmano molto ma molto male, questo è grave... programmare è anche una responsabilità. Il software è pervasivo: c'è la possibilità che un giorno se lo ritrovi in mano qualcuno e se non è fatto bene può produrre danni. Era una affermazione seria malgrado alcuni leggendo si saranno fatti un sorriso: se io scrivo un algoritmo semmai un algoritmo genetico e poi qualcuno lo usa in medicina e semmai qualcun'altro muore x un bug di chi è la colpa? O di chi è la colpa quando due treni si scontrano perchè c'è un bug nel software? Intanto la gente muore... Ultima modifica di Ikon O'Cluster : 30-06-2009 alle 01:24.