<BLOCKQUOTE id=quote><!--<font size= face="" id=quote>-->quote:<hr height=1 noshade id=quote>
volevo mettere anche dei commentini (al prof piacciono)ad esempio
int Contatore, Nmax; /*definisco un tipo dato (Contatore e Nmax)di tipo intero*/
int Nmax = 10; /*assegno a Nmax una valore*/
Persona x[Nmax]; /*assegno a Persona un array di 10 elementi*/
printf ("Inserisci Nome\n");
scanf ("%s",&x[Contatore].Nome /*assegno a NOme, l'idirizzo di x[Contatore] e a x l'indirizzo di Contatore*/
sono giusti?
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote><!--</font id=quote><font face="" size= id=quote>-->
Sì. I commenti /**/ sono conformi allo standard ANSI e sono interpretati da tutti i compilatori C che aderiscono a questo standard.
I commenti /**/ hanno però un difetto: racchiudono un blocco, e i blocchi non possono essere nidificati. Quindi esiste un altro tipo di commento, che inizia con // ed è valido per ina sola riga. Usando questo per documentare il codice, si permette al programmatore di escludere parte del codice (funzioni intere) con /**/ in un secondo momento. Per il codice documentato interamente con /**/, questo non è possibile, e si deve poi usare #if 0 ... #endif per escludere le porzioni di prova/annotazione e questi rendono il codice difficile da leggere. Sono chiamate Pseudo-Istruzioni, che riguardano solo il compilatore (non produce codice eseguibile).
Commentare va bene, ma bisogna farlo con criterio. Il codice troppo documentato diventa un mattone chilometrico e non si capisce più nulla.
Invece si usano descrittori auto-documentati, come ad esempio:
typedef struct {...} Persone;
E così non è necessario annotare:
// Struttura persone
o
/* Struttura persone */
perché è sott'inteso che struct è una struttura, e il nome fa il resto.
E' ben diverso se hai, ad esempio, da fare con nomi criptici, e di questi ne vedrai un bel po' in C.
typedef struct {...} WAVE_HDR; // struttura testata audio
Ma, se ci guardi bene, nei file *.h queste documentazioni mancano. Perché? Perché quando ti servono, saprai già a cosa sono utili, e quindi è fiato sprecato.
Per documentare *bene*, bisogna avere tuttavia un minimo di esperienza, e quindi si cerca:
a) dare dei nomi implicitamente documentati
b) ragruppare la documentazione in blocchi logici
c) scrivere il codice in modo che non richiede documentazione
d) dividere le procedure lunghe in unità più piccole
Il punto c) è ovviamente più difficile da raggiungere, ma dopo una decina di anni direi che ce la farai
Giovanni
---
http://www.y2ksw.com/vbulletin