[Commentare codice di un programma]

[soundsgood]

ciao ragazzi vorrei chiedervi quale il miglior modo (in caso contrario ognuno puo suggerirmi il suo) per commentare il codice che si sta scrivendo (in questo caso in vb.net) che costituisce le classi ed i metodi. Quindi a prescindere da eventuali commenti particolari, ma quelli che descrivono una classe oppure un metodo. Quando intendo per modo intendo anche come è indentato il commento, anche esteticamente quindi..

supponiamo che si abbia:

Public Class nomeclasse

    Public Function nomefunzione(ByRef parola As String) As Integer

    ...

    end function

end class

Come lo commentate?

[gugoXX]

Se hai bisogno di commentare un codice significa che il codice non e' autoesplicativo e non e' stato scritto bene.
gli unici commenti indispensabili sono quelli che spiegano il motivo, il perche' e' stata fatta una scelta, e non che cosa e' stato scelto.
Tali commenti sono pero' piu' di business che di sviluppo, e sono da limitare quanto piu' possibile.

[tomminno]

Originariamente inviato da gugoXX

Se hai bisogno di commentare un codice significa che il codice non e' autoesplicativo e non e' stato scritto bene.

Quindi per sapere cosa fa il codice bisogna avere l'editor di turno e aprire la soluzione?
Io lavoro tutti i giorni con codice autoesplicativo di cui però non c'è traccia di documentazione, per capire cosa fa anche un piccolo un software con 200 classi devo spulciarmelo tutto ben bene. Quanto sarebbe più rapida la ricerca su una documentazione testuale?
Per sapere che un determinato metodo comporta internamente l'invio di una email o che chiama una precisa stored procedure, una documentazione testuale consultabile da chiunque, magari dal DBA, fa schifo?

gli unici commenti indispensabili sono quelli che spiegano il motivo, il perche' e' stata fatta una scelta, e non che cosa e' stato scelto.
Tali commenti sono pero' piu' di business che di sviluppo, e sono da limitare quanto piu' possibile.

Perchè sarebbero da limitare?
Cosa succede dopo anche un anno (per non dire di più) che il codice è stato scritto e ci deve mettere le mani qualcuno che non l'ha mai visto?
Magari a prima vista possono esserci delle scelte nel codice di dubbia utilità ma che rispettano un preciso requisito che nessuno ovviamente ricorda più a distanza di qualche tempo. Oppure grazie ai commenti ci si può accorgere di codice che ha completato la sua funzione e che quindi è possibile rimuovere, senza i commenti rimarrebbe li in eterno perchè nel dubbio è meglio lasciare le cose come stanno.

[gugoXX]

Originariamente inviato da tomminno

Quindi per sapere cosa fa il codice bisogna avere l'editor di turno e aprire la soluzione?
Io lavoro tutti i giorni con codice autoesplicativo di cui però non c'è traccia di documentazione, per capire cosa fa anche un piccolo un software con 200 classi devo spulciarmelo tutto ben bene. Quanto sarebbe più rapida la ricerca su una documentazione testuale?
Per sapere che un determinato metodo comporta internamente l'invio di una email o che chiama una precisa stored procedure, una documentazione testuale consultabile da chiunque, magari dal DBA, fa schifo?

Si, fa schifo.
Una funzione/metodo deve fare una cosa sola, e cosa fa deve potersi capire dal nome del metodo stesso.
Il tempo delle funzioni monolitiche e' finito da un pezzo.
Il tempo dei commenti pure, tanto piu' che i commenti subiscono una obsolescenza molto veloce, e nessuno li aggiorna mai. Rischiano di essere addirittura dannosi. Melgio spendere tempo per un codice che non ha bisogno di essere commentato.

Perchè sarebbero da limitare?
Cosa succede dopo anche un anno (per non dire di più) che il codice è stato scritto e ci deve mettere le mani qualcuno che non l'ha mai visto?
Magari a prima vista possono esserci delle scelte nel codice di dubbia utilità ma che rispettano un preciso requisito che nessuno ovviamente ricorda più a distanza di qualche tempo. Oppure grazie ai commenti ci si può accorgere di codice che ha completato la sua funzione e che quindi è possibile rimuovere, senza i commenti rimarrebbe li in eterno perchè nel dubbio è meglio lasciare le cose come stanno.

I requisiti sono gli unici commenti che vale la pena di inserire quando non chiari o dubbi.
Per il resto come lavori o di cosa hai bisogno tu frega poco. La community ha deciso.

[tomminno]

Originariamente inviato da gugoXX

Si, fa schifo.
Una funzione/metodo deve fare una cosa sola, e cosa fa deve potersi capire dal nome del metodo stesso.

Certamente, ma già al livello di business questo non è più vero, un metodo di una classe di business non fa una cosa sola, compone tante altre funzionalità esposte da altre classi.
Cosa fa il metodo di business? Se non apri il codice non lo sai e in realtà se non apri il codice non sai nemmeno che è quel particolare metodo quello che ti interessa, quindi molto probabilmente la ricerca comuincerà da un livello ancora superiore, la gui o la pagina web.

Il tempo delle funzioni monolitiche e' finito da un pezzo.

Infatti nessuno qui ha nominato funzioni da migliaia di righe di codice (o anche solo centinaia).

Il tempo dei commenti pure, tanto piu' che i commenti subiscono una obsolescenza molto veloce, e nessuno li aggiorna mai.

Non si tratta di scrivere dei trattati, bastano poche righe difficilmente si superano le 3 righe di commento. Non è una fatica immane, non aggiornare i documento è un pò come non riutilizzare il codice ma fare copia e incolla. Fai certamente prima a duplicare il codice.

Rischiano di essere addirittura dannosi. Melgio spendere tempo per un codice che non ha bisogno di essere commentato.

Se qualcuno ti chiedesse "ma questo programma in quale caso manda delle email?". Bene senza documentazione devi aprire l'editor, spulciare tutto il codice, invece di eseguire una comoda ricerca testuale tramite browser.
Oppure in un ambiente SOA con centinaia di servizi quale sarà mai il servizio più adatto da richiamare? Ah boh aspetta che me li guardo tutti, così tra un anno sono ancora qui che apro la millesima istanza di Netbeans o Visual Studio!

I requisiti sono gli unici commenti che vale la pena di inserire quando non chiari o dubbi.
Per il resto come lavori o di cosa hai bisogno tu frega poco. La community ha deciso.

Ma che discorso è questo?
Te continua pure a divertirti ad aprire l'editor per rispondere a delle banalissime domande sul funzionamento di un programma a cui può dare risposta anche una semplice documentazione.
A me se arriva del codice non documentato lo mando indietro e non faccio partire nemmeno il pagamento del lavoro.

[killercode]

Per la scrittura del codice queste sono buone norme che valgono almeno per tutti i linguaggi di derivazione C http://www.python.org/dev/peps/pep-0008/.

Per la documenzazione esterna inizia da qui http://programmazione.html.it/guide/leggi/41/guida-uml/

Io poi tendo ad essere sovrabbondante con i commenti, meglio un'ovvietà in più che tanto si può evitare di leggere se già si ha capito il funzionamento che una in meno che ti fa perdere tempo. Se poi sono programmi per l'università da consegnare ad un professore, abbonda pure.

[marco.r]

Originariamente inviato da gugoXX

Se hai bisogno di commentare un codice significa che il codice non e' autoesplicativo e non e' stato scritto bene.
gli unici commenti indispensabili sono quelli che spiegano il motivo, il perche' e' stata fatta una scelta, e non che cosa e' stato scelto.
Tali commenti sono pero' piu' di business che di sviluppo, e sono da limitare quanto piu' possibile.

Non sarei cosi' categorico. Non sempre e' possibile scrivere codice completamente autoesplicativo, a meno di cambiare radicalmente il codice anche in altre parti, e magari non e' economicamente sostenibile.
Direi che dipende molto dal tipo di programma che si deve scrivere.

[Tommo]

Originariamente inviato da marco.r

Non sarei cosi' categorico. Non sempre e' possibile scrivere codice completamente autoesplicativo, a meno di cambiare radicalmente il codice anche in altre parti, e magari non e' economicamente sostenibile.
Direi che dipende molto dal tipo di programma che si deve scrivere.

Ma infatti, mi sembra che questo intervento sia molto meno intelligente della media di gugoXX, onestamente.

Intanto definire "codice autoesplicativo" e indicare se esiste;
personalmente ci metto 1-2 minuti a ricordare il funzionamento di una MIA classe non commentata quando ci rimetto mano dopo molto tempo...
minuti nei quali rischio di fare cagate o rovinare il design della classe modificandola male.
Una sola linea di commento che indichi lo scopo a parole e i warning, permette di sorvolare completamente la lettura del codice.

Ovviamente la cosa è ancora più vantaggiosa nel caso di un altro tizio del team, che il tuo codice lo deve proprio capire daccapo per usarlo, anche se supponiamo che le funzioni siano chiarissime, one-liner e tutto il resto.

Ecco, il mio punto di vista è "il codice DEVE essere chiaro e autoesplicativo, ma deve avere ANCHE i commenti"

Poi ci sono tante cose che non emergono dal codice, tipo l'architettura di massima del sistema, il suo modo d'uso, use case specifici, tutte cose che sono particolarmente utili per indirizzare l'utente verso il "modo unico" di fare le cose che avevi pensato, in modo da distoglierlo da hacks assortiti o soluzioni possibili ma inefficienti o ineleganti, o semplicemente indirizzarlo verso la giusta classe e la relativa documentazione.
Questo lo so perchè lavorando con un progetto enorme tipo Ogre, spesso è difficile anche solo capire, dato un obiettivo che hai, quale sarebbe la classe che lo realizza. Spesso ci sono 2 o 3 modi.
Poi il nostro "pro programmer" senza documentazione nè descrizioni di massima che fa, si legge tutto il codice di tutte le classi che a occhio hanno una vaga assonanza con quello che pensa?
Direi che non ha molto senso, e lo so perchè con Ogre mi è toccato farlo qualche volta, perdendoci le ore

Per cui la documentazione serve eccome, io tra assert, tests, disegnini e commenti ne produco parecchia anche per progetti dove lavoro solo io.

[gugoXX]

Originariamente inviato da Tommo

Ma infatti, mi sembra che questo intervento sia molto meno intelligente della media di gugoXX, onestamente.

Ma guarda che non sono parole mie.
Sono anni che la tendenza e' questa, e l'Italia sara' un po' in ritardo come al solito.

Ecco 4 parti dello stesso codice preso dal source control in tempi diversi

channel++; //increment channel

The good thing about this line was that both the code and the comment agreed (experience shows this is quite often not the case). The bad thing about this code is that they are both wrong, the problem being that the original coder didn't understand the difference between channel and timeslot [2] and chose the wrong variable name. Fortunately, when he (or someone who came along later) realised the mistake he used a snazzy re-factoring tool that avoids the problems with global "find and replace" and understands the code enough to only change the relevant variable name and not other occurrences of the string or the same name in another scope. The code now reads:

timeslot++; //increment channel

You might ask why the re-factoring programmer didn't change the comment to match and it was because he wasn't looking at that particular line, but at this one:

uint32_t channel; // I think this is probably
// timeslot, not channel.

The first person to come along realised the poor choice of variable name and "fixed" it by adding a comment. The second decided it would be better to change the variable name. Obviously, the second programmer believes in saying it in the code and disregarding comments, because the changed line now reads:

uint32_t timeslot; // I think this is probably
// timeslot, not channel.

In this episode Keith and Woody sit down with friend and traveling developer Corey Haines. Here's a question, how many times have you written comments in your code? Probably a lot! In this show Corey gives some valid reasons why developers shouldn't have comments in their code (with a few exceptions). The guys also discuss pair programming, what it is, how it is done, and the benefits of doing it.

E qui la scaletta.

Code quality scale

I believe most of the developers will agree with the following scale.

*
The worst code is: Bad code without comments.
*
Bad code is: Bad code with comments.
*
The average code is: Average code with comments.
*
Good code is: Good code with a few comments…
*
…but… Great code doesn’t need comments!!!

E qui 10 consigli che se seguiti permottono di evitare di scrivere commenti
http://www.makinggoodsoftware.com/20...ing-good-code/

"Commenting is Evil" o "Comments are evil" e' una frase che oramai non si sente neppure piu' tanto e' entrata in giro.
E soprattutto il commentare il prototipo di un metodo, da cui questo Thread e' partito.

[tomminno]

Originariamente inviato da gugoXX

E qui 10 consigli che se seguiti permottono di evitare di scrivere commenti
http://www.makinggoodsoftware.com/20...ing-good-code/

Peccato che il punto di vista sia il programmatore che deve mettere le mani al codice e non è nemmeno lungimirante, ad esempio Visual Studio ti mostra i commenti con l'intellisense. Già un commento che ti dice se il ToString di una classe è l'override di quello standard può fare comodo durante lo sviluppo. Te mi dirai ma basta andare alla definizione del metodo! Certo ripeti questa operazione decine di volte, con un context switch mentale e una perdita di concentrazione sul contesto di quello che stavi facendo e poi ne riparliamo se la documentazione è il male...

Se qualcuno chiedesse al programmatore: "mi fai il resoconto di quello che fa questo programma?" (con lo scopo di razionalizzare un'architettura che va ben oltre il singolo applicativo) vedrai come bestemmia se il programma in questione è stato scritto a 20 mani, è vecchio di anni e non ha uno straccio di commenti.
Con la documentazione fatta a modo potrebbe risponderti: "questo è l'indirizzo della documentazione generata automaticamente dal build server, leggitela e non rompere le p@££e con queste domande idiote".

Ma il bello poi è che tutti si lamentano che i software open source sono per la maggior parte scarsamente documentati, mentre chi ci lavora apprezza ad esempio la documentazione fornita da Msdn, ma anche la documentazione Java completa ed esauriente.
Non si capisce perchè mai l'approccio mentale debba essere differente per quello che viene scritto in prima persona.

Solo per fatica? Allora se fa fatica forse è il caso di pensare di svolgere un altro mestiere, perchè non è un atteggiamento molto professionale.

"Commenting is Evil" o "Comments are evil" e' una frase che oramai non si sente neppure piu' tanto e' entrata in giro.
E soprattutto il commentare il prototipo di un metodo, da cui questo Thread e' partito.

Immagino quindi che per coerenza quelli che ritengono che i commenti siano il male non utilizzino nessun tipo di documentazione quando cercano informazioni su una libreria, ma si affidino solamente ai forum.
Niene Java doc, niente Msdn, niente Qt doc, niente di niente.

Ritieni anche te che la documentazione qualcosa di completamente inutile?

[gugoXX]

Originariamente inviato da tomminno

Ritieni anche te che la documentazione qualcosa di completamente inutile?

Io non dico "mai" parole come "sempre, mai, completamente, etc."
Diciamo che e' molto meno utile di quanto si pensi, che in passato e' stato largamente sopravvalutato e che nell'Agile non e' affatto ben vista.
Molto meglio un codice ben scritto che un codice mediocre e commetato per supplire a mancanza di struttura.

[Tommo]

Mah, a me sembra che l'agile abbia parecchi meriti, ma le sue belle cantonate se le prende, così come ogni corrente estrema

Come dice giustamente il mio quasi omonimo, è immediato notare che ogni programmatore è un'avido consumatore di documentazioni altrui, che siano MSDN, Java doc, Qt doc, apple.doc, doxygen assortiti e quant'altro.

Dover dipendere da un progetto di terze parti di cui hai solo il codice è la peggior cosa che possa capitare in termini di produttività, altro che agile.
Bello perdere 24356 ore per capire da che parte dovrei iniziare a leggere il codice, quando bastava un doc riassuntivo sulla wiki corredato di esempio di uso comune.

A proposito di apple dev, si vede quanto va a ruba Android tra gli sviluppatori, con la sua documentazione "agile" e "concisa"
La qualità media dello store parla chiaro, è zeppo di apps fatte a tentoni e la coerenza su interfacce e prestazioni è del tutto di là da venire.
E io non credo proprio che dipenda solo dalla mancanza di filtri da parte di Google...

[gugoXX]

Altro esempio

I'm constantly running across comments from developers who don't seem to understand that the code already tells us how it works; we need the comments to tell us why it works. Code comments are so widely misunderstood and abused that you might find yourself wondering if they're worth using at all. Be careful what you wish for. Here's some code with no comments whatsoever:

r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );

Any idea what that bit of code does? It's perfectly readable, but what the heck does it do?

Let's add a comment.

// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
  r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );

That must be what I was getting at, right? Some sort of pleasant, middle-of-the-road compromise between the two polar extremes of no comments whatsoever and carefully formatted epic poems every second line of code?

Not exactly. Rather than add a comment, I'd refactor to this:

private double SquareRootApproximation(n) {
  r = n / 2;
  while ( abs( r - (n/r) ) > t ) {
    r = 0.5 * ( r + (n/r) );
  }
  return r;
}
System.out.println( "r = " + SquareRootApproximation(r) );

I haven't added a single comment, and yet this mysterious bit of code is now perfectly understandable.

As Steve points out, this is one key difference between junior and senior developers:

In the old days, seeing too much code at once quite frankly exceeded my complexity threshold, and when I had to work with it I'd typically try to rewrite it or at least comment it heavily. Today, however, I just slog through it without complaining (much). When I have a specific goal in mind and a complicated piece of code to write, I spend my time making it happen rather than telling myself stories about it [in comments].

[MEMon]

Io condivido del tutto quello detto da gugoXX, personalmente posso dire che il codice scritto bene diventa praticamente leggibile come del testo e non necessita di alcun commento.

Giusto quelle rare volte che, vuoi per forzare qualche pseudo "ottimizzazione" vuoi per qualche altro motivo, ti accorgi che il codice non sarebbe molto leggebile da terzi, quindi scrivi una righetta di commento, tutto qui.


Anzi, molte volte mi trovo ad andare a guardare il source di qualche metodo di java(ad esempio della lib swing) per capire come funziona piuttosto che leggere la documentazione che spesso non è sufficiente.

[tomminno]

Originariamente inviato da gugoXX

Altro esempio

Si certamente altro esempio basato su un pezzo di codice comunque limitato.
Se quel codice in realtà fosse un programma da 10.000 righe di codice e 500 classi?
Te le devi leggere proprio tutte per quanto chiare esse possano essere.

[tomminno]

Originariamente inviato da MEMon

Io condivido del tutto quello detto da gugoXX, personalmente posso dire che il codice scritto bene diventa praticamente leggibile come del testo e non necessita di alcun commento.

Quindi quando scegli un libro non leggi le note iniziali e finali per capire se ti interessa, ma prima lo leggi tutto e poi lo acquisti?

Quando il codice scritto bene diventa di decine di migliaia (e oltre) di righe di codice, devi leggertele tutte!

Ma dove lavorate, se arriva uno nuovo gli dite "toh leggiti tutte le 10000 righe di codice di questo programma che tanto sono scritte talmente bene da essere autoesplicative, una volta lette saprai esattamente cosa fa e a cosa serve e comprenderai i segreti dell'universo" ?

[dojolab]

Originariamente inviato da MEMon

Io condivido del tutto quello detto da gugoXX, personalmente posso dire che il codice scritto bene diventa praticamente leggibile come del testo e non necessita di alcun commento.

Giusto quelle rare volte che, vuoi per forzare qualche pseudo "ottimizzazione" vuoi per qualche altro motivo, ti accorgi che il codice non sarebbe molto leggebile da terzi, quindi scrivi una righetta di commento, tutto qui.


Anzi, molte volte mi trovo ad andare a guardare il source di qualche metodo di java(ad esempio della lib swing) per capire come funziona piuttosto che leggere la documentazione che spesso non è sufficiente.

D'accordo, ma fino ad un certo punto.
Io per ogni classe che scrivo, per ogni metodo che implemento 4 righe di commento su cosa fa (o dovrebbe fare) e cosa ritorna in ogni caso le scrivo.

E riempo il codice di tutti i commenti possibili.

[!fazz]

Originariamente inviato da MEMon

Io condivido del tutto quello detto da gugoXX, personalmente posso dire che il codice scritto bene diventa praticamente leggibile come del testo e non necessita di alcun commento.

Giusto quelle rare volte che, vuoi per forzare qualche pseudo "ottimizzazione" vuoi per qualche altro motivo, ti accorgi che il codice non sarebbe molto leggebile da terzi, quindi scrivi una righetta di commento, tutto qui.


Anzi, molte volte mi trovo ad andare a guardare il source di qualche metodo di java(ad esempio della lib swing) per capire come funziona piuttosto che leggere la documentazione che spesso non è sufficiente.

quindi per unire il mio codice con quello del mio collega sono obbligato a leggermi qualche centinaio di migliaia di righe di "chiaro e semplice testo" sparse in qualche decina di file, e senza poter contare su intellisense e compagni durante lo sviluppo.

I commenti sono fondamentali quando si lavora in team, un codice ti dà una sequenza di istruzioni ma, visto che per ogni problema non esiste una sola soluzione, essere obbligati a leggere il listato e tentare di comprendere la logica che ci stà dietro è un suicidio. se il codice non è commentato spesso l'unica soluzione è attaccarsi al telefono e chiamare, sempre se è possibile, chi ha scritto quella parte di codice.

@gugoxx il mondo ideale è bello ma spesso i principi della buon programmazione vanno accantonati in favore dell'efficienza

[MEMon]

Originariamente inviato da tomminno

Quindi quando scegli un libro non leggi le note iniziali e finali per capire se ti interessa, ma prima lo leggi tutto e poi lo acquisti?

Quando il codice scritto bene diventa di decine di migliaia (e oltre) di righe di codice, devi leggertele tutte!

Ma dove lavorate, se arriva uno nuovo gli dite "toh leggiti tutte le 10000 righe di codice di questo programma che tanto sono scritte talmente bene da essere autoesplicative, una volta lette saprai esattamente cosa fa e a cosa serve e comprenderai i segreti dell'universo" ?

Ma quando mai ti devi leggere 10000 righe di codice per capire qualcosa?
Se stai leggendo del codice stai già capendo quello che fa se è scritto bene, quindi il commento non serve quasi mai, NON ho detto mai, ma QUASI mai.

Originariamente inviato da !fazz

quindi per unire il mio codice con quello del mio collega sono obbligato a leggermi qualche centinaio di migliaia di righe di "chiaro e semplice testo" sparse in qualche decina di file, e senza poter contare su intellisense e compagni durante lo sviluppo.

I commenti sono fondamentali quando si lavora in team, un codice ti dà una sequenza di istruzioni ma, visto che per ogni problema non esiste una sola soluzione, essere obbligati a leggere il listato e tentare di comprendere la logica che ci stà dietro è un suicidio. se il codice non è commentato spesso l'unica soluzione è attaccarsi al telefono e chiamare, sempre se è possibile, chi ha scritto quella parte di codice.

@gugoxx il mondo ideale è bello ma spesso i principi della buon programmazione vanno accantonati in favore dell'efficienza

I commenti sono fondamentali solo per chi programma ad cazzum, il codice deve essere autoesplicativo, quando si lavora in team se c'è il babbione che scrive roba illogica allora gli si impone di mettere il commento, altrimenti basta il nome del metodo unitamente al nome della classe in cui si trova per capire già cosa fa, e il codice dentro al metodo si deve poter leggere praticamente come un commento.

La verità sta nel mezzo, non dico di non scrivere mai niente, una righina a inizio metodo se volete ci sta, più che altro perchè molti ide te la fan vedere nel completamento automatico, quello che proprio non condivido è il commento in mezzo al codice, quello proprio non ci va se non in rarissimi casi per far capire una cosa che altrimenti non si capirebbe.


PS. se il codice che si sta scrivendo è un Framework, SDK o una libreria allora va commentato tutto per bene, perchè essendo spesso slegata dal contesto, è più difficile capire cosa fa, e comunque essendo il suo scopo principale il poter essere utilizzato nel modo più semplice possibile, è ragionevole pensare che la documentazione ci deve essere, anche solo per dire come e quando è necessario utilizzare quello anzichè quell'altro.
Ma se il codice è implementato dilungarsi sui commenti è utile solo se è scritto da cani.

[MEMon]

Originariamente inviato da dojolab

D'accordo, ma fino ad un certo punto.
Io per ogni classe che scrivo, per ogni metodo che implemento 4 righe di commento su cosa fa (o dovrebbe fare) e cosa ritorna in ogni caso le scrivo.

E riempo il codice di tutti i commenti possibili.

Scrivere cosa fa un metodo ci potrebbe pure stare, magari non 4 righe ma ci sta, ma il commento in mezzo al codice no dai, quello che stai facendo si deve capire da quello che stai scrivendo, altrimenti qualcosa non torna.

Poi forse dipende anche dal linguaggio che si usa? Magari in C e C++ posso capire che il commento potrebbe essere utile ovunque