Re: [Python] Agile programming Robert Martin

2014-10-01 Per discussione Michele Gatti
Il giorno 01 ottobre 2014 17:20, Massimo Capanni 
ha scritto:

> Il giorno 01 ottobre 2014 16:49, enrico franchi 
> ha scritto:
>
>>
>>
>> Esatto... e la provocazione (quello e', inutile girarci intorno) di Uncle
>> Bob e' invece di commentare codice non di immediata comprensione, scrivi
>> codice di immediata comprensione. E' ovviamente un punto di vista forte,
>> quasi ideale se vogliamo.
>>
>> Sicuramente ci sara' un qualche pezzo di codice che non puo' essere
>> semplificato al punto di non necessare commenti. O forse semplicemente non
>> e' ancora nata una persona sufficientemente intelligente da semplificarlo
>> (o non ha lavorato su quel progetto). ;)
>>
>> --
>> .
>> ..: -enrico-
>>
>>
> ​non credo che arriverò a scrivere un codice sorgente che superi il
> migliaio di righe, sostanzialmente scrivo brevi script, però visto che
> quando si presenta l'occasione di rimettere mano a vecchi sorgenti scritti
> molto tempo addietro passo un sacco di tempo per capire la logica usata al
> tempo, forse tutto ciò potrebbe essermi utile. In altre parole credo che
> fare bene le piccole cose sia propedeutico a fare bene le cose un po' più
> grandi.
>
> :-)
>
> ​grazie a tutti
> ​
>
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
Io il libro l'ho letto, grazie a Enrico, devo dire che lo applico il più
possibile per piccoli script e qualsiasi cosa per un domani non capire più
cosa scrivo.
Poi è molto difficile iniziare ma preso il volano è tutto molto più facile

-- 

Michele Gatti
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Agile programming Robert Martin

2014-10-01 Per discussione Massimo Capanni
Il giorno 01 ottobre 2014 16:49, enrico franchi 
ha scritto:

>
>
> Esatto... e la provocazione (quello e', inutile girarci intorno) di Uncle
> Bob e' invece di commentare codice non di immediata comprensione, scrivi
> codice di immediata comprensione. E' ovviamente un punto di vista forte,
> quasi ideale se vogliamo.
>
> Sicuramente ci sara' un qualche pezzo di codice che non puo' essere
> semplificato al punto di non necessare commenti. O forse semplicemente non
> e' ancora nata una persona sufficientemente intelligente da semplificarlo
> (o non ha lavorato su quel progetto). ;)
>
> --
> .
> ..: -enrico-
>
>
​non credo che arriverò a scrivere un codice sorgente che superi il
migliaio di righe, sostanzialmente scrivo brevi script, però visto che
quando si presenta l'occasione di rimettere mano a vecchi sorgenti scritti
molto tempo addietro passo un sacco di tempo per capire la logica usata al
tempo, forse tutto ciò potrebbe essermi utile. In altre parole credo che
fare bene le piccole cose sia propedeutico a fare bene le cose un po' più
grandi.

:-)

​grazie a tutti
​
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Agile programming Robert Martin

2014-10-01 Per discussione enrico franchi
2014-09-30 10:38 GMT+01:00 Manlio Perillo :

> tramite un amico programmatore ho visto alcuni video tutorial di Robert C.
>> Martin e mi hanno partcolarmente incuriosito (venti minuti dedicati solo
>> all'inutilità dei commenti nel codice sorgente mi ha abbastanza spiazzato).
>>
>
> Senza passare tra due estremi opposti, i commenti servono se fanno il loro
> dovere, ossia commentare del codice che altrimenti potrebbe non essere di
> immediata comprensione.  Per fare questo devono essere scritti bene e
> tenuti aggiornati.
>

Esatto... e la provocazione (quello e', inutile girarci intorno) di Uncle
Bob e' invece di commentare codice non di immediata comprensione, scrivi
codice di immediata comprensione. E' ovviamente un punto di vista forte,
quasi ideale se vogliamo.

Sicuramente ci sara' un qualche pezzo di codice che non puo' essere
semplificato al punto di non necessare commenti. O forse semplicemente non
e' ancora nata una persona sufficientemente intelligente da semplificarlo
(o non ha lavorato su quel progetto). ;)

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


Re: [Python] Agile programming Robert Martin

2014-10-01 Per discussione Marco Buttu

On 30/09/2014 12:06, Carlos Catucci wrote:
2014-09-30 11:38 GMT+02:00 Manlio Perillo >:


Senza passare tra due estremi opposti, i commenti servono se fanno
il loro dovere, ossia commentare del codice che altrimenti
potrebbe non essere di immediata comprensione.  Per fare questo
devono essere scritti bene e tenuti aggiornati.


Il commento tra tripli apici subito dopo la dichiarazione di classe o 
metodo in python che poi diviene l'output del comando help() e' 
secondo il mio modesto parere una delle cose piu' intelligenti che 
esistano. Certo vanno scritti bene, e aggiornati.


In realta' il "commento tra tripli apici" non è un commento, ma una 
stringa che viene utilizzata per creare della documentazione. Mentre i 
commenti, come dice Manlio, servono per commentare il codice che 
altrimenti potrebbe non essere di immediata comprensione (per lo 
sviluppatore che deve mettere mano a quel codice), le docstring servono 
per documentare le API, per cui sono utili all'utente finale per capire 
come utilizzare un modulo, una funzione, una classe, ecc.


Per essere concreti, ecco un esempio che ritengo significativo, dove 
risulta evidente quanto siano utili sia i commenti sia le docstring, se 
scritti avendo chiaro in mente il loro scopo:


https://hg.python.org/cpython/file/3.4/Lib/statistics.py

Se vogliamo sapere cosa fa statistics e come utilizzare le sue funzioni, 
non ci occorre consultare della documentazione offline o peggio andare a 
tentativi:


>>> import statistics # A partire da Python 3.4
>>> help(statistics)
>>> help(statistics.mean)

Per quanto riguarda l'aggiornamento della documentazione, anche su 
questo punto statistics e' scritto in modo impeccabile, perche' riporta 
degli eloquenti esempi interattivi. Come disse Tim Peters a suo tempo:


* gli esempi non hanno prezzo
* gli esempi che non funzionano sono peggio di quelli inutili
* gli esempi che funzionano alla fine diventano esempi che non funzionano...

Il modulo doctest consente di evitare che "gli esempi che funzionano" 
diventino "esempi che non funzionano":


$ python -m doctest /usr/lib/python3.4/statistics.py -v
Trying:
mean([-1.0, 2.5, 3.25, 5.75])
Expecting:
2.625
ok
   ...
52 tests in 18 items.
52 passed and 0 failed.
Test passed.

Visto che ci siamo, riporto un'altra perla, che e' la PEP relativa a 
questo modulo:


http://legacy.python.org/dev/peps/pep-0450/

--
Marco Buttu

INAF-Osservatorio Astronomico di Cagliari
Via della Scienza n. 5, 09047 Selargius (CA)
Phone: 070 711 80 217
Email: mbu...@oa-cagliari.inaf.it

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python