Newsgroup: it.comp.lang.c
Titolo: buone regole di scrittura codice

me ne sapreste consigliare?

 me ne sapreste consigliare?
Comincerei con "funzionante" <g>

 me ne sapreste consigliare?
La classica KISS:
Keep
It
Simple
Stupid
oppure la versione apocrifa:
Keep It Simple and Small
In altre parole non arzigogolare per creare del codice "fico", cerca di
scrivere del codice pulito e chiaro.
E aggiungo una citazione:
"Debugging is twice as hard as writing the code in the first place.
 Therefore, if you write the code as cleverly as possible, you are, by
 definition, not smart enough to debug it." -  Brian W. Kernighan
Luca
PS: Buon 2005 a tutti. Scusate gli auguri anticipati ma fra poco
parto... torno fra un po' di giorni ;)
-- 
Home: 
http://kronoz.cjb.net
Un apostolo vedendo Gesu` camminare sulle acque:
- Cazzo se e` buono 'sto fumo!!!

 me ne sapreste consigliare?
in che senso?? 
<c_mode>
if (buono == funzionante) {
 vedi_altri_post();
} else if (buono == bello) {
 usa_indent();
}
/* in ogni caso e come ti e' gia stato detto */
keep_it_simple();
</c_mode>
biez,
  nelson
-- 
Se oggi e' il primo giorno del resto della tua vita, che cavolo era ieri?

 me ne sapreste consigliare?
Non indentare mai. Non andare a capo. 
I Perlisti si credono fichi perche` possono fare gli one-liner:
li puoi fare anche in C.
| #include <stdio.h> 
| int main() { puts("Hello World\n") ; return 0; }
E` certamente molto piu` figo del tradizionale.
Se proprio devi indentare, fallo in modo creativo. Gli if nestati sono un
capolavoro da questo punto di vista.
while(b()){
	if (a()){
	c(); d();
	e();
if (h())
	hello();
}
else{
	d();
	e();
}
E` certamente piu` figo (se poi sei veramente in vena, puoi provare a
disegnare figure in ascii art con il codice, le migliori sono le donnine
nude - i tuoi colleghi maschi saranno molto eccitati. -).
Oppure indenta al contrario:
		int main(){
	if (a()){
b();
	}
	return 0;
		}
Ogni volta che hai un'istruzione semplice (che farebbe pensare agli altri
programmatori che sei una persona banale) complicala.
| printf("%ce%s%c%c%c%c%s%c%s\n", "Hu"[0], "ll", 111, "C'era una volta un
| programmatore odiato da tutti, perche` era troppo il migliore"[" r"[0]],
| 'W',"ora o mai piu`"[0], "r", "Ecco, la mia ora e` giunta"['g'-'a'],
| "d!") ; 
(chiaramente tutta su una riga) e` molto meglio. 
Definisci variabili con nomi sensati che non usi (se non in modo inutile e
creativo). Alle variabili importanti invece dai nomi poco significativi.
Per esempio a1, a2, a3. 
Usa la notazione ungherese, ma in modo che non corrisponda. Per esempio
indica come puntatori cose che puntatori non sono, e viceversa.
Sfrutta le somiglianze tipografiche fra 1 e l
pensa come e` bello
l111
l1l1
l11l
lll1
llll
Meglio ancora se le usi di 8 caratteri. Hai piu` combinazioni.
Sfrutta ogni idiosincrasia del tuo compilatore, se sui compilatori dei tuoi
conoscenti non funziona, potrai dire loro che hanno un compilatore che fa
schifo. E` molto divertente.
Usa quante piu` variabili globali e` in tuo potere.
Usa le macro in modo creativo, senza proteggere i termini. Ovviamente ogni
macro deve avere un nome che non centra nulla con quello che fa.
Il classico e`
#define SIX 5 + 1
#define NINE 1 + 8
Aggiungi side effect casuali alle funzioni, possibilmente tramite
un'innocua macro...
| #define CLEAN_FREE_MEMORY c = c-c;
| 
| int somma(int a, int b){
| 	int c = a+b;
| 	CLEAN_FREE_MEMORY
| 	return c;
| }
Ogni volta che puoi, usa puntatori e memoria allocata dinamicamente. Non
liberarla mai, potrebbe servirti in futuro.
Ogni tanto vai a cabiare qualche locazione di memoria a caso (rand() e`
fatta apposta per facilitarti la vita). Un programma che si comporta in
modo prevedibile e` banale.
Se lavori in team, viola sistematicamente tutte le norme e le convenzioni
che ti hanno detto. Lo fanno per limitare la creativita`. Sono tuoi nemici.
Diciamo che puoi invertire quanto detto...
Sempre su questo stile (ma molto piu` divertente, estinsivo e completo):
http://www.soft-land.org/cgi-bin/doc.pl?doc=documenti/pessimo
-- 
[ RiK0                                ]
[ non credo negli schemi non vincenti ]
[ two is an odd prime number          ]

Se per "regole di scrittura codice" intendi lo stile Google ti puņ aiutare
(C+style+guide):
ad esempio:
http://www.psgd.org/paul/docs/cstyle/cstyle.htm
Se invece intendi dire come si fa a scrivere del codice efficiente e
corretto beh quello lo si ottiene con esperienza, applicazione e buon senso.
Bye
John

 Metterci tanti commenti.
Dissento decisamente.
Se il codice è scritto bene, di commenti ne servono pochi o nessuno.
--
Cingar
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
Finche`  non deve metterci le mani un'altra persona.  Anch'io pensavo 
che non servissero ma poi ho dovuto modificare del codice scritto da altri.


 altri.
Ovviamente, tutto dipende da come è scritto il codice e da come (e perché)
sono scritti i commenti.
Più del 50% del mio lavoro è modificare codice scritto da altri (incluso
me stesso di 10 o 15 anni più giovane: un ragazzino ormai quasi
sconosciuto) e devo dire che i commenti li trovo nella gran parte dei casi
inutili e ingombranti.
Spessissimo, anzi, li trovo addirittura fuorvianti: chi decide di usare
tanto commenti dovrebbe tenere ben presente che anche questi vanno curati
e *mantenuti* nel tempo come tutto il resto del codice. Commentare con
negligenza, dimenticandosi poi di modificare i commenti man mano che si
modifica il codice, è molto peggio che non commentare del tutto.
Fosse per me, metterei un solo commento all'inizio di ogni modulo (file .C
o .H) per spiegare *brevemente* (massimo una o due righe) a cosa serve
quel modulo più altre informazioni spicciole (chi l'ha scritto, in quale
data; una cronaca delle principali modifiche).
Poi vanno messi commenti in tutti quei punti in cui si fanno delle
"porcherie" che non si dovrebbero fare. La presenza stessa del commento è
da intendersi come un "cartello di pericolo" per i propri colleghi ma
anche come una ammissione di colpa e una implicita promessa a cercare,
prima o poi, di eliminare la "porcheria" e, quindi, la necessità del
commento.
Se c'è bisogno di spiegazioni più complesse di quelle poche righe, o il
codice è strutturato male o ha bisogno di un manuale a parte.
IMHO, naturalmente.


 
Ora che ho presa la buona abitudine mi trovo bene anche se scrivo 
programmini sul mio PC di casa (o se faccio piccoli script di shell).
Ma e` solo una mia opinione.
