View Full Version : [Commentare codice di un programma]
soundsgood
08-11-2010, 16:41
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?
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
09-11-2010, 11:07
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.
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
09-11-2010, 12:11
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
09-11-2010, 14:19
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.
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.
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" :read:
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 :D
Per cui la documentazione serve eccome, io tra assert, tests, disegnini e commenti ne produco parecchia anche per progetti dove lavoro solo io.
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/2009/06/04/10-commandments-for-creating-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
09-11-2010, 23:28
E qui 10 consigli che se seguiti permottono di evitare di scrivere commenti
http://www.makinggoodsoftware.com/2009/06/04/10-commandments-for-creating-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?
Ritieni anche te che la documentazione qualcosa di completamente inutile?
Io non dico "mai" parole come "sempre, mai, completamente, etc." :asd:
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.
Mah, a me sembra che l'agile abbia parecchi meriti, ma le sue belle cantonate se le prende, così come ogni corrente estrema :D
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" :asd:
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...
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].
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
10-11-2010, 07:46
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
10-11-2010, 07:54
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" ?
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.
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
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.
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.
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 :asd:
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.
Questo si, in effetti nemmeno io commento mai il codice all'interno delle funzioni.
Poi c'è il caso nei giochi delle funzioni di gameplay, che per loro definizione fanno roba arbitraria e sono spesso lunghissime...
lì ovviamente è necessario mettere commenti che spiegano che cosa ti aspetti che facciano.
Ovviamente altri tipi di programmi non hanno questa necessità.
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.
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.
a parte che il codice non può essere sempre autoesplificativo (classico esempio, accesso diretto ad una cella di memoria: come può un indirizzo hex essere autoesplificativo dei parametri che si vanno a modificare)?
comunque sulla prima parte sono d'accordo con te, la verità sta nel mezzo non avere nessun tipo di commento è odioso come è odioso avere ogni singola riga commentata
sottovento
10-11-2010, 11:47
"Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice" (Einstein)
Non sempre il codice puo' essere reso autoesplicativo. Pensa al modello matematico che controlla la produzione in un impianto industriale, che deve tenere sotto in considerazione pressioni, coppie dei motori, forze applicati, analisi chimiche, correnti assorbite, impatto ambientale e cosi' via.
E' probabile che un team di tecnologi scriva una serie di algoritmi, poi implementati da un team di sviluppatori. Chi e' esperto del problema non e' esperto di programmazione. Un codice del genere non ha grandi probabilita' di essere "autoesplicativo". Autoesplicativo per chi?
Si ma state tirando fuori tanti bei esempi, nessuno qui ha detto che non si devono MAI usare i commenti, negli esempi che state facendo i commenti ci vogliono, le chiacchere stan in poco posto.
Ma se facciamo una statistica di quanti lavorano in questo settore, il codice che normalmente si scrive, ha davvero bisogno di commenti?
banryu79
10-11-2010, 12:25
Si ma state tirando fuori tanti bei esempi, nessuno qui ha detto che non si devono MAI usare i commenti, negli esempi che state facendo i commenti ci vogliono, le chiacchere stan in poco posto.
Ma se facciamo una statistica di quanti lavorano in questo settore, il codice che normalmente si scrive, ha davvero bisogno di commenti?
Io dico che appunto (come testimoniato un po' da tutti) come sempre dipende.
Dal contesto tecnologico, dal livello di astrazione del dominio del problema, dal layer software specifico che si sta implementando, ecc...
Sulla generica tendenza a "semplificare" e a ridurre i commenti a favore di "codice autoesplicativo" sono pienamente a favore e nel mio piccolo mi sforzo sempre in tal senso perchè ne ho riscontrato benefici personali in termini produttivi e "di design".
Si ma state tirando fuori tanti bei esempi, nessuno qui ha detto che non si devono MAI usare i commenti, negli esempi che state facendo i commenti ci vogliono, le chiacchere stan in poco posto.
Ma se facciamo una statistica di quanti lavorano in questo settore, il codice che normalmente si scrive, ha davvero bisogno di commenti?
comunque sono parecchie persone, all'incirca tutti quelli che sviluppano applicazioni non x86:D
sottovento
10-11-2010, 13:15
comunque sono parecchie persone, all'incirca tutti quelli che sviluppano applicazioni non x86:D
Aggiungerei anche quelli: diciamo che spesso lo sviluppatore non e' l'esperto del problema, ma l'esperto dello strumento che si vuole usare per risolvere il problema. Posso non sapere nulla di chimica ma risolvere un problema di chimica, una volta che un esperto del settore mi prepara le formule/procedura da seguire.
In tal caso, il codice potrebbe non essere cosi' autoesplicativo, per lui o per me.
tomminno
10-11-2010, 13:46
comunque sono parecchie persone, all'incirca tutti quelli che sviluppano applicazioni non x86:D
Ma anche per x86.
Prova ad entrare in un'azienda che utilizza centinaia di software, che ne appalta spesso la realizzazione/modifica a ditte esterne, che per esigenze di mercato deve rivedere spesso in ottica ottimizzazione/espansione il flusso informativo.
In tutto questo sistema, del codice autoesplicativo non basta, perchè quando devi rivedere un flusso che riguarda almeno 10 software differenti non puoi permetterti di spulciare il loro meraviglioso codice tutte le volte che serve. Devi avere qualcosa che ti dica cosa fanno, quali sono i punti cruciali senza perderti nell'inseguimento di Patterns e/o business logic molto spesso "illogic".
killercode
10-11-2010, 18:11
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 :asd:
Mah, direi invece che il c++ sia uno di quei linguaggi così basilari che non ha bisogno di spiegare cosa fà, i commenti fanno comodo per lavori più di alto livello.......sfido chiunque a capire al volo un'espressione regolare minimamente complessa
cdimauro
11-11-2010, 05:39
Mah, a me sembra che l'agile abbia parecchi meriti, ma le sue belle cantonate se le prende, così come ogni corrente estrema :D
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.
Sarà, ma il mio codice è praticamente privo di commenti, e chi lo legge non incontra tutte le difficoltà di cui hai parlato.
Di recente ho lavorato a un progetto che è poi passato di mano a un nuovo collega. E' un progetto che avevo, a mia volta, "ereditato" da un altro collega, che aveva già aggiunto qualche unit test su mio suggerimento, e che io ho provveduto a rifattorizzare pesantemente aggiungendo diversi altri test per completare (a mio avviso) la batteria in dotazione.
Pur essendoci le classiche scadenze da fiato sul collo, il mio collega non ha avuto difficoltà ad aggiungere un'altra parte sostanziosa al progetto, con relative nuove unit test, sfruttando quelle precedenti per capire come funzionava il tutto e, soprattutto, per pararsi il posteriore in caso di errori.
E anche lui non ha inserito nessuna riga di commento. Il codice è già autoesplicativo e non serve altro.
Comunque è pure una persona in gamba che conosceva già l'extreme programming, sia chiaro, ma diciamo che gli ho fatto capire che avrei gradito l'uso di unit test per coprire l'intero progetto. Purtroppo quando ci sono scadenze la tendenza rimane quella di scrivere intanto il codice, rimandando la scrittura delle unit (per chi lo fa, visto che, almeno da me, è praticamente sconosciuta come metodologia). Io m'impongo di scrivere sempre unit test.
Mi trovo, quindi, sostanzialmente d'accordo con gugo.
cdimauro
11-11-2010, 05:43
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.
Forse perché l'ha scritto male? :stordita:
@gugoxx il mondo ideale è bello ma spesso i principi della buon programmazione vanno accantonati in favore dell'efficienza
Questa non l'ho capita onestamente.
cdimauro
11-11-2010, 05:59
comunque sono parecchie persone, all'incirca tutti quelli che sviluppano applicazioni non x86:D
Quando programmavo in assembly c'era un commento ogni riga di codice.
In certi contesti i commenti sono praticamente indispensabili.
Anche perché gli assemblatori sono strumenti di livello troppo basso. E' difficile trovare qualcuno che utilizzi roba come high level assembler.
@gugoxx il mondo ideale è bello ma spesso i principi della buon programmazione vanno accantonati in favore dell'efficienza
Questa non l'ho capita onestamente.
Ma non l'ho scritta io. :fagiano:
Se per efficienza in questo caso si intende la leggibilita' del codice allora sono d'accordo.
Talvolta per questioni di tempistiche, si e' costretti a tirare giu' un pezzo di codice velocemente, che difficilmente potra' avere tutte le caratteristiche richieste dagli standard di programmazione condivisi.
Ma i test certificano che il pezzo di codice, anche se non ben scritto, fa quello che deve fare.
E all'iterazione successiva sara' cura riscrivere (rifattorizzare) il brutto codice per farlo diventare un bel cigno.
La rifattorizzazione e' un punto cruciale e si deve sempre essere disposti a mettere in gioco parti di codice, anche se magari ci si sono spese sopra parecchie ore, per migliorarle.
Anzi, sempre piu' mi accorgo che sono piu' contento quando zappo via 1000 righe di codice oramai inutile piuttosto di quando scrivo 1000 righe di buon codice.
Se invece per efficienza si intende il numero di cicli di CPU allora non sono piu' d'accordo.
Parecchi anni fa mi arrovellavo su come scrivere il codice piu' efficiente possibile, sacrificando spesso la leggibilita'. Oggi non piu'. La qualita' piu' importante sono leggibilita' e manutenibilita', e sono disposto a sacrificare i cicli di CPU (anzi non li guardo proprio) per ottenere il risultato. Che peraltro, molte volte, magari non coincidera' ma si avvicina molto.
banryu79
12-11-2010, 09:09
Ma non l'ho scritta io. :fagiano:
Infatti: cdimauro quotava una frase di !fazz che quest'ultimo aveva rivolto a te :D
cdimauro
12-11-2010, 21:59
Esatto. :D
Comunque concordo nuovamente, in toto, con gugoXX su quanto scritto nell'ultimo messaggio. :cool:
tomminno
12-11-2010, 23:20
Esatto. :D
Comunque concordo nuovamente, in toto, con gugoXX su quanto scritto nell'ultimo messaggio. :cool:
Oggi ho avuto l'ennesima riprova che non avere commenti è una pessima condizione di partenza.
Caso: Dovevo rianalizzare il flusso dati con tutte le possibili diramazioni all'interno di un software, come mi capita di frequente.
Se il software l'aveste scritto voi avrei dovuto perdere un'intera giornata (e forse anche di più) ad analizzare classi su classi, a cercare di ricostruire tutti gli step intermedi, tutti i casi particolari. Ebbene si il mio caso il codice era comunque chiarissimo in quanto l'avevo scritto io inizialmente 2 anni orsono :sofico: , anche se poi ci hanno messo mano anche altri successivamente.
Beh ho fatto qualcosa di meglio: ho consultato la documentazione generata automaticamente dal build server a partire dai commenti, con tanto di diagrammi, e nel giro di 3 ore avevo già chiaro cosa deve essere fatto a questo punto spulciare il codice per conferma è stato molto più rapido, sapevo dove andare a cercare!
Analizzando direttamente il codice avrei avuto la mente ottenebrata da dettagli di basso livello, oltre che persa a navigare in decine e decine di classi.
cdimauro
13-11-2010, 07:29
Ma non è che devi andare a spulciarti le righe di codice. Le funzioni / metodi avranno un nome autoesplicativo, immagino. Idem per le classi.
Se il progetto è complesso magari ti sarebbe bastato un software che genera il diagramma delle classi e delle sequenze, in modo da avere il quadro della situazione.
Poi non so effettivamente cosa dovevi fare, per cui mi fermo qui.
tomminno
13-11-2010, 12:57
Ma non è che devi andare a spulciarti le righe di codice.
E per cercare metodi e funzioni che fai? Apri l'IDE di turno e? Ovviamente dovrai partire dal Main, oppure scegli una classe a caso e parti da lì?
Le funzioni / metodi avranno un nome autoesplicativo, immagino. Idem per le classi.
Il nome è autoesplicativo, pensa un pò ad una classe UserPermissionSetFactory è auto esplicativo che sia un Factory (che posso supporre istanzierà oggetti di tipo IUserPermissionSet), ma quali sono tutte le logiche in base a cui istanzia un oggetto AdminPermissionSet piuttosto che uno StandardUserPermissionSet? E soprattutto come faccio a sapere quali sono tutti i possibili tipi che istanzia? O magari a sua volta la creazione viene delegata a WebUserPermissionFactory, o forse no?
Se non guardi il codice non lo sai, ma ad occhio sai sicuramente che è un factory.
Se il progetto è complesso magari ti sarebbe bastato un software che genera il diagramma delle classi e delle sequenze, in modo da avere il quadro della situazione.
Eh si peccato che sui diagrammi delle classi non sia possibile farci le ricerche sopra, del tipo dato un diagramma con 100 classi, mi tiri fuori tutti quelli che contengono la parola Factory o Create? Oppure perchè no tutti quelli che espongono eventi!
Avevo già tutto nella documentazione autogenerata, mi è bastato aprire il browser.
Poi non so effettivamente cosa dovevi fare, per cui mi fermo qui.
Smantellare un sistema legacy, ma per farlo bisogna consocere per filo e per segno cosa fanno tutte le entità coinvolte, per convogliarle sul sistema nuovo, che ovviamente dovrà fornire almeno le stesse funzionalità di quello vecchio.
Hai presente la Spaghetti Integration?
cdimauro
13-11-2010, 19:57
Non ne avevo sentito parlare, e dal nome capisco anche il perché. :D
Abbiamo qualche problema simile anche in azienda, ma da tempo abbiamo deciso di introdurre tecnologie completamente nuove da utilizzare per i nuovi servizi, lasciando quelli legacy a girare sulla vecchia piattaforma. Pensare di cambiarla sostituendola interamente interamente con una nuova è un suicidio (soprattutto economico).
Comunque hai un'esigenza molto particolare. Non è che si lavora così normalmente.
Uppo perchè sono capitato su un commento intelligente :read:
Comments are only a repetition if what you put in them is the “what”. The “what” is, indeed, already there in the form of the code. However, the “why” is often pretty much impossible to put directly into the code itself.
Say you’re faced with some credit card processing code that sends all credit card numbers through validation for the CVV2 (that little number on the signature panel), but there’s this extra bit that sends American Express cards around that particular validation.
The kind of code comment you are talking about being repetitive would say something like:
//Bypassing CVV2 validation for American Express cards.
That comment clearly is redundant because code like this already makes that pretty clear:
if(creditCard.CardType == CardTypes.AmericanExpress)
{
} else
{
isValidCVV2 = creditCard.ValidateCVV2();
}
However, when you’re looking at that code, the question you have in your mind is this:
Q: Why is the code not checking the CVV2 number for American Express cards but *is* checking for the rest?
A: Because American Express wants to come on site and do audits if you check that and the product owner would rather pay the higher rate to process the cards than deal with the audit
That answer is what good comments should contain. That can mean that there are large blocks of code without comments (because the “why” is not necessary), but whenever there ARE comments, they should be explaining the “why”, not the “what”. Then, they aren’t repeating yourself.
“What” comments aren’t necessary. “Why” comments are the lifeblood of a maintainable codebase. They let you go to the people who oversee the credit card processing agreement and see if that “why” still holds true when you’re asked to dig into the credit card validation for other reasons and see if it should be left the way it is.
In sostanza, i commenti servono per spiegare il perchè del codice fa qualcosa, non come lo fa, e sono quindi fondamentali quando il motivo di una qualche scelta si trova al di fuori del programma stesso.
E' così ovvio detto così :asd:
Forse perché l'ha scritto male? :stordita:
Questa non l'ho capita onestamente.
spe che spiego,
io spesso sviluppo firmware quindi niente OO, spesso niente ide o un ide ridotto ai minimi termini ecc ecc e spesso mi è capitato di mandare a quel paese tutti i principi della buona programmazione utilizzando ad esempio accesso e scrittura diretta in memoria, assembly, shift e operazioni strane o per necessità intrinseche del sistema oppure perchè troppo cpu limited e dovevamo ridurre al minimo le operazioni da fare visto lo sputo di potenza e di ram con cui operiamo e in questi casi i commenti sono obbligatori altrimenti ti trovi a passare pagine e pagine di codice per capire cosa faccia un pezzo di codice come questo
PON_RST_DIR |= PON_RST_PIN;
SPI_SSN2_DIR |= SPI_SSN2_PIN;
SPI_SSN1_DIR |= SPI_SSN1_PIN;
PON_RST_PORT |= PON_RST_PIN;
SPI_SSN2_PORT |= SPI_SSN2_PIN;
SPI_SSN1_PORT |= SPI_SSN1_PIN;
Uppo perchè sono capitato su un commento intelligente :read:
In sostanza, i commenti servono per spiegare il perchè del codice fa qualcosa, non come lo fa, e sono quindi fondamentali quando il motivo di una qualche scelta si trova al di fuori del programma stesso.
E' così ovvio detto così :asd:
assolutamente d'accordo :)
if nome=gigi then ko else ok
con qualsiasi sintassi e codice si capisce che se c'è gigi nn va bene :D
ma se guardo il codice la prima cosa che mi viene in mente è...PERCHE' il povero gigi no??
commento inutile
se il nome è uguale a gigi non va bene
commento intelligente
gigi mi sta sulle balle e lo escludo!
DioBrando
24-11-2010, 14:14
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.
scusa ma il tempo speso per le righe di commento non sarebbe meglio spenderlo per i test, fare refactoring?:stordita:
poi secondo me si vuole attribuire un po' troppi significati/motivazioni al loro utilizzo...
il perché di una scelta di business risiede spesso nell'analisi dei requisiti. Che senso ha scrivere un commento nell'implementazione di x metodo?
Una funzionalità va esaudita in un certo modo?
Lo faccio. Il metodo avrà un nome autoesplicativo e morta lì.
Anche prima qualcuno ha citato una chiave esadecimale...vabbè facciamo finta che io crei un x oggetto. Ma questa avrà delle proprietà che siano leggibili (come se fosse plain text) o no?
Se poi mi si dice...vabbè devo sviluppare delle funzioni matematiche particolarmente complesse oppure accedere alla periferica con linguaggi a basso livello posso anche capire...ma sul totale del codice creato dagli sviluppatori, mettendolo in percentuale, quanto potrà essere?
scusa ma il tempo speso per le righe di commento non sarebbe meglio spenderlo per i test, fare refactoring?:stordita:
poi secondo me si vuole attribuire un po' troppi significati/motivazioni al loro utilizzo...
il perché di una scelta di business risiede spesso nell'analisi dei requisiti. Che senso ha scrivere un commento nell'implementazione di x metodo?
Una funzionalità va esaudita in un certo modo?
Lo faccio. Il metodo avrà un nome autoesplicativo e morta lì.
Anche prima qualcuno ha citato una chiave esadecimale...vabbè facciamo finta che io crei un x oggetto. Ma questa avrà delle proprietà che siano leggibili (come se fosse plain text) o no?
Se poi mi si dice...vabbè devo sviluppare delle funzioni matematiche particolarmente complesse oppure accedere alla periferica con linguaggi a basso livello posso anche capire...ma sul totale del codice creato dagli sviluppatori, mettendolo in percentuale, quanto potrà essere?
più di quanto immagini se pensi che ormai qualsiasi oggetto è dotato di un micro
DioBrando
24-11-2010, 15:02
più di quanto immagini se pensi che ormai qualsiasi oggetto è dotato di un micro
sarò annebbiato da Master Page e kebab ma cosa intendi per "micro"? :confused:
banryu79
24-11-2010, 15:05
più di quanto immagini se pensi che ormai qualsiasi oggetto è dotato di un micro
Eheh, potrei rigirare la questione: hai idea di quanto sia, in proprozione, il codice applicativo/di alto livello rispetto a quello di basso livello?
"Più di quanto immagini" non mi sembra una risposta, e la domanda di DioBrando mi era parsa retorica :)
sarò annebbiato da Master Page e kebab ma cosa intendi per "micro"? :confused:
miocrocontrollore
http://it.wikipedia.org/wiki/Microcontrollore
Eheh, potrei rigirare la questione: hai idea di quanto sia, in proprozione, il codice applicativo/di alto livello rispetto a quello di basso livello?
"Più di quanto immagini" non mi sembra una risposta, e la domanda di DioBrando mi era parsa retorica :)
non c'entra nulla alto e basso livello i micro di solito si programmano in ansi c (alto livello) spessissimo però si usano dispositivi mappati in memoria e altri artifici che richiedono per forza dei commenti altrimenti non si capisce più cosa fà il codice (ps guarda lo spezzone di codice che ho postato prima, secondo te è autoesplificativo? riesci a capire cosa fà?)
poi le percentuali non saranno calcolabili ma non commete l'errore di pensare che il 99.9999% del codice sia OO o comunque codice classico per pc
non so da te ma da me esistono sicuramente più lavatrici, lavastoviglie, radiosveglie, frigoriferi, cancelli automatici, sistemi domotici termostati, elettrovalvole, ecu, sistemi abs, esp, tcs, tester, psu, oscilloscopi, radio eccetera eccetera che pc
e se pensi che ognuno di questi sistemi ha del codice dentro (chiamiamolo a "basso livello" giusto per capirci)vedrai che la mole di codice ( e il numero di sviluppatori coinvolti) è parecchio più elevato di quanto di solito si immagina
DioBrando
24-11-2010, 16:20
miocrocontrollore
http://it.wikipedia.org/wiki/Microcontrollore
guarda che io per oggetto intendevo l'entità dal punto di vista dell'OOP :)
non c'entra nulla alto e basso livello i micro di solito si programmano in ansi c (alto livello) spessissimo però si usano dispositivi mappati in memoria e altri artifici che richiedono per forza dei commenti altrimenti non si capisce più cosa fà il codice (ps guarda lo spezzone di codice che ho postato prima, secondo te è autoesplificativo? riesci a capire cosa fà?)
poi le percentuali non saranno calcolabili ma non commete l'errore di pensare che il 99.9999% del codice sia OO o comunque codice classico per pc
non so da te ma da me esistono sicuramente più lavatrici, lavastoviglie, radiosveglie, frigoriferi, cancelli automatici, sistemi domotici termostati, elettrovalvole, ecu, sistemi abs, esp, tcs, tester, psu, oscilloscopi, radio eccetera eccetera che pc
e se pensi che ognuno di questi sistemi ha del codice dentro (chiamiamolo a "basso livello" giusto per capirci)vedrai che la mole di codice ( e il numero di sviluppatori coinvolti) è parecchio più elevato di quanto di solito si immagina
la % non è calcolabile ma basta farsi un giro su qualsiasi portale con le richieste di lavoro IT. Diciamo che l'offerta interessa più che largamente linguaggi ad alto livello
D'altra parte posso ribaltarti il concetto.
Non bisogna fare l'errore di pensare che un linguaggio ad alto livello non possa assolvere anche funzionalità embedded.
Tutte le piattaforme più utilizzate al momento danno la possibilità (penso al Compact Framework per dirne uno) di lavorare su dispositivi custom basati su differenti architetture.
Poi chiaramente dipende dai requisiti del problema...
Sui prodotti che ha una persona in casa...sì ok ma pensa a quanti servizi utilizzi ogni giorno che hanno a che fare con la Rete. Non parlo solo di siti web, in generale di applicazioni, webservices...
E sempre se vogliamo citare dei numeri, ormai in Ingegneria del Software, da anni, si va affermando che più del 50% di un'applicazione è dedicata all'interfaccia. Mettici la business logic, mettici la persistenza.
Quanto rimane al "basso livello"? Pochino.
Su queste basi, il codice selfexpressive diventa un'esigenza prima ancora che una pippa mentale da XP.
E d'altra parte se in pochi lo mettono in dubbio significa che bene o male è un'idea piuttosto radicata, entrata nel comune pensare.
Questo non significa prendere acriticamente per buoni tutti gli spunti derivanti dalle metodologie agili. Sennò saremmo delle scimmie.
banryu79
24-11-2010, 16:32
non c'entra nulla alto e basso livello i micro di solito si programmano in ansi c (alto livello) spessissimo però si usano dispositivi mappati in memoria e altri artifici che richiedono per forza dei commenti altrimenti non si capisce più cosa fà il codice (ps guarda lo spezzone di codice che ho postato prima, secondo te è autoesplificativo? riesci a capire cosa fà?)
Il contesto mi è chiaro (lavoro con macchine a controllo numerico, "programmo" in G-CODE che come contesto possiamo considerare di basso livello e come formato pure, per cui il codice risulta tutto fuori che "parlante" dato che si basa su mnemonici e scrivo utilità e piccole applicazioni desktop [Java] ad un livello di astrazione maggiore [CAD & CAM like] come interfaccia per l'utente finale che deve adoperare concretamente la macchina) e infatti sulla neccessità dei commenti in certi contesti sono d'accordo con te, l'avevo anche già detto in precedenza.
poi le percentuali non saranno calcolabili ma non commete l'errore di pensare che il 99.9999% del codice sia OO o comunque codice classico per pc
Non penso questo infatti.
Però non penso nemmeno che ci sia un rapporto fifty-fifty... ma questa è una mia personale sensazione.
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.
Io credo che la verità stia in mezzo. E' vero che nella maggior parte dei casi se il codice è scritto bene (ovvero ogni metodo fa una sola cosa) il commento è quasi inutile per il programmatore che deve modificare quel codice.
E' altrettanto vero che ci sono altri programmatori che dovranno utilizzare il tuo codice o direttamente includendolo o come libreria. Diventa a quel punto chiaro che:
- l'utilizzatore potrebbe non avere le competenze adatte alla comprensione del codice della libreria.
- l'utente NON DEVE perdere tempo ad aprire la libreria, scegliere la funzione che gli serve e comprenderne il suo funzionamento per intero
Ecco perché per l'utilizzatore il commento alla funzione implementata nel metodo può essere molto utile, magari raccolto da strumenti automatici (doxygen e simili) in sistemi di consultazione consistenti con la code base.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.