[Programmazione Object Oriented] Buone norme..

[jappilas]

Originariamente inviato da trias

awwww mi viene il mal di pancia

dalle risate?
ok che non avrò la capacità di spiegare di francesco, a volte dico qualcosa di inesatto,
ma non mi sembrava di scrivere cose così esilaranti...

[fek]

Originariamente inviato da trias

ok mi hai convinto in parte, se ci sono meccanismi automatici che permettono di estrarre la conoscenza necessaria dal codice stesso ben vengano...

Per Java esistono dei tool che creano i diagrammi di classe a partire dal codice. Vicius ha trovato un plugin per Eclipse.

Per C++/C# c'e' il Visual Studio 2005 che crea un class diagram in automatico.

I diagrammi UML creati automaticamente sono utilissimi come ulteriore punto di vista sul codice.

Originariamente inviato da fek

Per Java esistono dei tool che creano i diagrammi di classe a partire dal codice. Vicius ha trovato un plugin per Eclipse.

Per C++/C# c'e' il Visual Studio 2005 che crea un class diagram in automatico.

I diagrammi UML creati automaticamente sono utilissimi come ulteriore punto di vista sul codice.

uml e diagrammi di classe!? se avessimo parlato in questi termini ci saremo risprmiato parecchi post... io quelle cose le intendevo per sottinteso

cmq bella discussione.. ciao!

Originariamente inviato da jappilas

dalle risate?
ok che non avrò la capacità di spiegare di francesco, a volte dico qualcosa di inesatto,
ma non mi sembrava di scrivere cose così esilaranti...

perdonami... no è ulcera... mi viene un attacco automatico di ulcera ogniqualvolta leggo qualcosa di difficile, che non riesco a capire subito! oppure quando compilo e c'è un errore stupido... è peggio ancora quando c'è il segnale acustico di errore... quello e proprio la fine. prendo il calendario e inizio a bestemmiare

[jappilas]

Originariamente inviato da trias

perdonami... no è ulcera... mi viene un attacco automatico di ulcera ogniqualvolta leggo qualcosa di difficile, che non riesco a capire subito!

perdonami tu ho pensato fosse un post sarcastico
forse sono più chiaro in questi termini: alle volte si vuole implementare una funzione passando "per vie traverse", cioè adoperando accorgimenti e algoritmi che alla fine fanno sembrare il codice (c/c++) poco simile al risultato finale che ottiene
(ad esempio, se tu vedessi un codice che effettua quache shift qua, qualche somma là, non te la daresti che sta calcolando il seno di un angolo con l' algoritmo CORDIC - il quale a sua volta ha alle spalle il fatto che andando a considerare il campo dei numeri complessi e relativi fase/argomento permette di calcolare le trigonometriche in modo veloce)
in questo caso il codice dubito possa essere autoesplicativo e andrà MOLTO ben documentato (personalmente farei un riassunto della teoria matematica di riferimento)
però siamo in presenza di un' ottimizzazione a livello di implementazione, e magari stiamo leggendo codice che altri hanno fatto... non una funzione nell' ambito di un progetto SW più vasto e su cui abbiamo controllo...

[shang84]

Originariamente inviato da fek

Ci sono i test automatici per quello

Esistono test automatici anche per farmi capire il bakground su cui sto lavorando? O se i dati che il programma produce hanno senso rispetto al problema originale?

Esempio:

lavori in un team di ricerca sul DNA con biologi, i biologi con cui lavori ti spiegano il problema. Esso implica conoscenze che un informatico o bioinformatico che sia non può avere complete ( o comunque al medesimo livello di un ricercatore biologo che ha speso una vita per "raccimolarle"..) ecco ora arriva il bello.. il biologo ti spiega un'idea rivoluzionaria che deve essere implementata tramite un sofisticato algoritmo per realizzare un programma utilizzato poi nel mondo della ricerca.

A questo punto tu fek decidi di scrivere il tuo bel codice senza alcun commento. Un giorno ti licenzi e cambi lavoro. Ai tuoi colleghi rimangono i test automatici. Ma seppur capendo benissimo le relazioni tra le diverse classi e l'ordine di chiamata dei metodi non capiscono il perchè di tutto ciò. Per loro il programma produce semplicemente dei numeri e non crasha.

Quindi ora, per capire se il codice che dovranno modificare (per aggiungere ad esempio una variante ottimizzata dell'algoritmo) sta producendo risultati con senso devono avere un'idea di come funziona l'algoritmo a livello biologico, cosa che va al di là del codice autoesplicativo. Cosa per cui ci sono due soluzioni:

- o chiedere più volte ai colleghi biologi la spiegazione dell'algoritmo

- o guardare e cercare di capire il codice sorgente del collega e capire cosi in modo autonomo lo scopo dell'algoritmo.

Quindi sentire parlare di codice totalmente senza commenti mi fa pensare a un contesto di applicazione semplice (intesa come conoscenze extra informatiche necessarie: un gioco, un programma di contabilità ...), ma è ben distante da un contesto scientifico in cui il programma deve servire alla scienza per progredire.

Come può un programmatore capire l'intuizione geniale del suo collega biologo semplicemente guardando il codice privo di commenti del suo collega informatico?

Come può capire che tipo di risultato si aspetta il biologo? E come può capire se il risultato è corretto se nel codice non c'è un minimo di commento a spiegarglielo?

E infine: perchè nei linguaggi di programmazionie più diffusi si implementano i commenti?

Per quanto riguarda Java che stai usando nel progetto Diamonds, se ti è capitato di usare JBuilder o NetBeans, avrai notato che se cerchi sulla reference trovi i javadoc che spiegano l'utilizzo delle classi (API), e avrai anche notato che sono molto ma molto comodi per capirne al volo l'utilizzo. Il java doc è un tipico esempio di documentazione del codice. Ti sfido a capire l'uso di un ActionListener guardando solamente il codice sorgente e senza avere conoscenze di programmazione ad eventi.

Quanto comodo è poter usare il java doc? e quanto tempo e denaro fa risparmiare al programmatore e alla software house? Molto!

Pensati te se i programmatori che hanno scritto le API java non avessero fatto alcun commento javadoc....

Spero di essere stato chiaro, ma è una questione di principio. Senza rancore.

[The3DProgrammer]

Mi trovo esattamente in questa situazione...sto lavorando ad un engine raytracing, e per migliorarne le performance sto implementando tecniche di spatial subdivision basate su OCTree....sta venendo su bene, a parte un PICCOLO dettaglio....verificare se una bbox e un triangolo overlappano è un casino, e sto utilizzando una funzione trovata sul web che implementa un tale algoritmo...sfortunatamente nel codice nn esiste nemmeno una riga di commento...se da un lato sono grato agli autori per questa soluzione (nn credo ci sarei mai riuscito da solo) dall'altro qualke bestemmiuccia se la sono presa, xkè ovviamente dal codice nn ci capisco una mazza

ciauz

[shang84]

Originariamente inviato da The3DProgrammer

Mi trovo esattamente in questa esitazione...sto lavorando ad un engine raytracing, e per migliorarne le performance sto implementando tecniche di spatial subdivision basate su OCTree....sta venendo su bene, a parte un PICCOLO dettaglio....verificare se una bbox e un triangolo overlappano è un casino, e sto utilizzando una funzione trovata sul web che implementa un tale algoritmo...sfortunatamente nel codice nn esiste nemmeno una riga di commento...se da un lato sono grato agli autori per questa soluzione (nn credo ci sarei mai riuscito da solo) dall'altro qualke bestemmiuccia se la sono presa, xkè ovviamente dal codice nn ci capisco una mazza

ciauz

Mal comune mezzo gaudio! Anche se in un contesto diverso.
Ho, anzi abbiamo, bestemmiato per giorni per capire gli script di un nostro collega. Alla fine (per quanto autoesplicativi fossero i nomi delle variabili e delle funzioni) mi sono dovuto far rispiegare il problema dai biologi-chimici con cui lavoro e ho iniziato l'implementazione del programma da 0! Senza la contestualizzazione ci avrei sbattuto la testa per giorni senza capircene fuori tanto..

Non aggiungo nessun altro commento perchè è autoesplicativo il mio post precedente

Notte!

[The3DProgrammer]

Originariamente inviato da shang84

Mal comune mezzo gaudio!

Hehe io xò sono stato + fortunato

Xkè sono riuscito a capire come integrarlo nel sw, x cui mi accontento di utilizzare senza capire

ciauz

[cionci]

Dipende anche da quanto è buono il codice...
Non sono solo le variabili e le funzioni che devono essere autoesplicative...ma anche il codice deve essere buono... Per buono intendo "scritto bene"...e rispettando delle metriche molto ristrette...
Se ad esempio un metodo è composto da 100 righe (o anche da 50) e nella classe ci sono 50 metodi...è chiaro che diventa complicatissimo, anche se i nomi sono autoesplicativi...
L'esempio di codice fatto di da fek calza a pennello...

[fek]

Originariamente inviato da shang84

Esistono test automatici anche per farmi capire il bakground su cui sto lavorando? O se i dati che il programma produce hanno senso rispetto al problema originale?

Certo, li scrivi

Come può un programmatore capire l'intuizione geniale del suo collega biologo semplicemente guardando il codice privo di commenti del suo collega informatico?

Se il codice si auto commenta, e' scritto come se fosse inglese, quindi l'intuizione geniale e' li', chiara, e leggibile, nel codice. Non ha bisogno di alcun commento.

Come può capire che tipo di risultato si aspetta il biologo? E come può capire se il risultato è corretto se nel codice non c'è un minimo di commento a spiegarglielo?

Leggendo il codice ben scritto (se e' ben scritto). Sara' piu' chiaro e formale di qualunque commento in un linguaggio informale come quello naturale.
Ti sei mai domandato perche' i teoremi anche i piu' complessi sono espressi in linguaggi formali e non in linguaggi naturali? Perche' sono piu' semplici da comprendere per chi conosce il linguaggio.

E infine: perchè nei linguaggi di programmazionie più diffusi si implementano i commenti?

Per commentare le assunzioni che non possono essere espresse in codice.

Per quanto riguarda Java che stai usando nel progetto Diamonds, se ti è capitato di usare JBuilder o NetBeans, avrai notato che se cerchi sulla reference trovi i javadoc che spiegano l'utilizzo delle classi (API), e avrai anche notato che sono molto ma molto comodi per capirne al volo l'utilizzo. Il java doc è un tipico esempio di documentazione del codice. Ti sfido a capire l'uso di un ActionListener guardando solamente il codice sorgente e senza avere conoscenze di programmazione ad eventi.

Ora stiamo parlando di documentazione, che e' un concetto totalmente differente da un commento dentro il codice. Non credo che i commenti siano un trattato di programmazione ad eventi.

Spero di essere stato chiaro, ma è una questione di principio. Senza rancore.

Non e' una questione di principio, e' una questione di praticita' e di produttivita'.

Se pensi che i commenti possano migliorare la situazione se il codice e' mal scritto, sbagli. Se pensi che non serva mai commentare, sbagli, serve commentare solo cio' che non puo' essere espresso in codice (come il contratto di un API in un Javadoc).

Esistono linguaggi come Eiffel che documentano anche i contratti in codice, e non hanno bisogno neppure di quei commenti.

Infine: se pensi che davanti a codice mal scritto la soluzione sia commentarlo, sbagli, la soluzione e' riscriverlo.

[fek]

Originariamente inviato da The3DProgrammer

Mi trovo esattamente in questa situazione...sto lavorando ad un engine raytracing, e per migliorarne le performance sto implementando tecniche di spatial subdivision basate su OCTree....sta venendo su bene, a parte un PICCOLO dettaglio....verificare se una bbox e un triangolo overlappano è un casino, e sto utilizzando una funzione trovata sul web che implementa un tale algoritmo...sfortunatamente nel codice nn esiste nemmeno una riga di commento...se da un lato sono grato agli autori per questa soluzione (nn credo ci sarei mai riuscito da solo) dall'altro qualke bestemmiuccia se la sono presa, xkè ovviamente dal codice nn ci capisco una mazza

ciauz

Quel codice era evidentemente mal scritto. Commentarlo non sarebbe stata la soluzione, scriverlo in maniera chiara sarebbe stato molto meglio.

Originariamente inviato da shang84

Mal comune mezzo gaudio! Anche se in un contesto diverso.
Ho, anzi abbiamo, bestemmiato per giorni per capire gli script di un nostro collega. Alla fine (per quanto autoesplicativi fossero i nomi delle variabili e delle funzioni) mi sono dovuto far rispiegare il problema dai biologi-chimici con cui lavoro e ho iniziato l'implementazione del programma da 0! Senza la contestualizzazione ci avrei sbattuto la testa per giorni senza capircene fuori tanto..

Non aggiungo nessun altro commento perchè è autoesplicativo il mio post precedente

Notte!

Stai confondendo la documentazione e la definizione delle specifiche e del dominio del problema con i commenti. Sono cose diverse.

Non credo che dentro il codice del tuo collega ci fosse spazio per un trattato di biologia per farti comprendere il dominio del problema. Il dominio del problema e' descritto in un documento a parte, come i requisiti. Il dominio della soluzione e' descritto invece nel codice.

In Diamonds i requisiti sono descritti nelle Storie e nei task. Il dominio del problema e' invece descritto nel documento di design.
La soluzione e' descritta nel codice e non ha bisogno di commenti perche' il codice e' ben scritto.

Originariamente inviato da jappilas

perdonami tu ho pensato fosse un post sarcastico
forse sono più chiaro in questi termini: alle volte si vuole implementare una funzione passando "per vie traverse", cioè adoperando accorgimenti e algoritmi che alla fine fanno sembrare il codice (c/c++) poco simile al risultato finale che ottiene
(ad esempio, se tu vedessi un codice che effettua quache shift qua, qualche somma là, non te la daresti che sta calcolando il seno di un angolo con l' algoritmo CORDIC - il quale a sua volta ha alle spalle il fatto che andando a considerare il campo dei numeri complessi e relativi fase/argomento permette di calcolare le trigonometriche in modo veloce)
in questo caso il codice dubito possa essere autoesplicativo e andrà MOLTO ben documentato (personalmente farei un riassunto della teoria matematica di riferimento)
però siamo in presenza di un' ottimizzazione a livello di implementazione, e magari stiamo leggendo codice che altri hanno fatto... non una funzione nell' ambito di un progetto SW più vasto e su cui abbiamo controllo...

mmmh in quel caso basterebbe dare alla funzione, che racchiude quel codice, un nome abbastanza significativo, non pensi?
ci sono altri casi in cui purtroppo come dici tu e shang84 il "nome simbolico" potrebbe essere più lungo dello stesso metodo. in quel caso non è tanto problema del codice ma limitazione del programmatore che non sa la teoria matematica/scientifica che sta alla base dell'alg. e per quello c'è un efficace soluzione: te la studi

[fek]

Originariamente inviato da jappilas

in questo caso il codice dubito possa essere autoesplicativo e andrà MOLTO ben documentato (personalmente farei un riassunto della teoria matematica di riferimento)

float ComputeFastSinWithCORDIC(float )
{
   // do your mad stuff here 
}

float sin(float x)
{
#ifdef USE_FAST_SIN
  return  ComputeFastSinWithCORDIC(x);
#else
  // use slow sin() here
#endif
}

E anche questa volta non c'e' bisogno di commenti
E nel codice c'e' anche il nome dell'algoritmo che e' ben documentato online.

[fek]

Originariamente inviato da trias

mmmh in quel caso basterebbe dare alla funzione, che racchiude quel codice, un nome abbastanza significativo, non pensi?
ci sono altri casi in cui purtroppo come dici tu e shang84 il "nome simbolico" potrebbe essere più lungo dello stesso metodo. in quel caso non è tanto problema del codice ma limitazione del programmatore che non sa la teoria matematica/scientifica che sta alla base dell'alg. e per quello c'è un efficace soluzione: te la studi

Quando un nome e' troppo lungo spesso quel metodo sta cercando di fare troppe cose assieme. E' il sintomo di un problema a monte, il metodo va spezzato in parti piu' coese e semplici da nominare.
Imparare a nominare i metodi diventa anche un tool di verifica del proprio design.

[jappilas]

Originariamente inviato da fek

float ComputeFastSinWithCORDIC(float )
{
   // do your mad stuff here 
}

float sin(float x)
{
#ifdef USE_FAST_SIN
  return  ComputeFastSinWithCORDIC(x);
#else
  // use slow sin() here
#endif
}

E anche questa volta non c'e' bisogno di commenti
E nel codice c'e' anche il nome dell'algoritmo che e' ben documentato online.

alla capacita' di sintesi del fek
in effetti personalmente, quando posso mantenere il controllo sul codice, cerco di seguire proprio questo tipo di approccio (per poi essere rimproverato di "ridondanza" da colleghi di qui )
il problema e' quando tocca mettere le mai in codice scritto da altri, e si constatano, a parte nomi di variabili e funzioni non autesplicativi, che accorgimenti di livello "ottimizzativo" si mescolano ai dettagli algoritmici in quello che si puo' definire "spaghetti code" di difficile gestibilita'...

PS: (un po' ot): ti interessa come approssimare un seno con le tangenti iperboliche?

[fek]

Originariamente inviato da jappilas

PS: (un po' ot): ti interessa come approssimare un seno con le tangenti iperboliche?

Hmmm... boh