Re: [Python] Agile programming Robert Martin
2014-10-05 11:12 GMT+02:00 Simone Federici s.feder...@gmail.com: Ok vediamo un modulo più semplice 100 linee. Tu lo ritieni sbagliato scrivere il commento nell'eccezione in fondo al modulo? https://raw.githubusercontent.com/django/django/master/django/utils/tzinfo.py Eh, eh... chiaramente no, non solo non è sbagliato secondo me, ma è pure utile. Come sempre non esiste regola senza eccezioni (tranne questa stessa... ma allora è falsa... ma allora è vera... ecc.). Non direi certo che il commento del tuo esempio è una sconfitta del programmatore, ma venendo da un'epoca in cui il codice DOVEVA essere commentato, la definizione seguente mi ha abbastanza colpito: ogni commento non banale è un insuccesso del programmatore che non è riuscito a scrivere del codice auto-esplicativo. Comunque il libro, a mio parere, merita di essere letto. Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Simone Federici wrote: Ok vediamo un modulo più semplice 100 linee. Tu lo ritieni sbagliato scrivere il commento nell'eccezione in fondo al modulo? https://raw.githubusercontent.com/django/django/master/django/utils/tzinfo.py Marco Beri wrote: Eh, eh... chiaramente no, non solo non è sbagliato secondo me, ma è pure utile. Più che utile, lo ritengo indispensabile. Come sempre non esiste regola senza eccezioni Nel libro Clean Code l'autore non ha proposto una regola, ma una sua convinzione. Il suo giudizio sui commenti è complessivamente negativo, ma piuttosto articolato e con parti positive, vedi l'incipit del cap. 4 a p. 53: Nothing can be quite so helpful as a well-placed comment. e la sezione Good Comments a p.55. Non direi certo che il commento del tuo esempio è una sconfitta del programmatore, ma venendo da un'epoca in cui il codice DOVEVA essere commentato, Un'epoca? Il codice deve essere commentato e descritto anche oggi. la definizione seguente mi ha abbastanza colpito: ogni commento non banale è un insuccesso del programmatore che non è riuscito a scrivere del codice auto-esplicativo. Credo sia questa: Comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much—perhaps not at all. L'autore descrive in modo articolato pregi e difetti dei commenti; il suo giudizio complessivo che sia un male necessario mi sembra miope. Ci sono vari livelli di testo umano, non comprensibile dalle macchine (almeno non oggi, e speriamo mai), collegato ai programmi per computer. Si va dalle specifiche, alle descrizioni architetturali, alle specifiche delle API, alle docstring, ai commenti veri e propri. *Tutti* questi livelli sono *essenziali*. Per l'accennata insufficiente espressività dei linguaggi di programmazione, scrivere programmi è un'attività a perdita di conoscenza: il dettaglio delle operazioni comprensibili dalla macchina non conserva l'intenzione del programmatore. Ogni volta che si legge un programma privo di documentazione si effettua un'operazione costosa di reverse intentioning, non dissimile dal reverse engineering ma ad un livello superiore. Scrivere codice corretto è difficile, scrivere codice espressivo lo è ancora di più, scrivere contemporaneamente codice espressivo e il testo che completi quell'espressività, inevitabilmente insufficiente, è difficilissimo e non gode della verifica automatica, da cui la tipica insofferenza dei programmatori, pigri per definizione. La necessaria manutenzione del codice comporta la manutenzione della sua descrizione testuale: ma senza quella descrizione, la stessa manutenzione è molto più costosa e pericolosa. Siamo chiamati ad essere contemporaneamente meccanici, domatori, scrittori e poeti: non meraviglia che tendiamo ad alleggerire il fardello. Ahimè, non è una buona idea. -- Nicola 'tekNico' Larosa http://www.tekNico.net/ The insight that _doing too much, too fast causes serious problems_, is a core life truth that is gaining recognition in more and more fields from neurology to psychotherapy to bodybuilding to personal relationships to product design to engineering to project management to social systems to basic science and philosophy to art to sex. - Johann Gevers, May 2014 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
2014-10-06 10:52 GMT+02:00 Nicola Larosa n...@teknico.net: Marco Beri wrote: Non direi certo che il commento del tuo esempio è una sconfitta del programmatore, ma venendo da un'epoca in cui il codice DOVEVA essere commentato, Un'epoca? Il codice deve essere commentato e descritto anche oggi. Dai, hai capito cosa intendevo :-) Una volta si diceva che tutto il codice doveva per forza essere molto commentato. la definizione seguente mi ha abbastanza colpito: ogni commento non banale è un insuccesso del programmatore che non è riuscito a scrivere del codice auto-esplicativo. Credo sia questa: Comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much—perhaps not at all. L'autore descrive in modo articolato pregi e difetti dei commenti; il suo giudizio complessivo che sia un male necessario mi sembra miope. Io lo trovo invece sostanzialmente comprensibile e corretto. Il senso del male necessario sta nel fatto che un commento è in fondo un possibile punto di fallimento perché potrebbe disallinearsi, diventare obsoleto essendo comunque una cosa a sé stante rispetto al codice che commenta. Ci sono vari livelli di testo umano, non comprensibile dalle macchine (almeno non oggi, e speriamo mai), collegato ai programmi per computer. Si va dalle specifiche, alle descrizioni architetturali, alle specifiche delle API, alle docstring, ai commenti veri e propri. *Tutti* questi livelli sono *essenziali*. Per l'accennata insufficiente espressività dei linguaggi di programmazione, scrivere programmi è un'attività a perdita di conoscenza: il dettaglio delle operazioni comprensibili dalla macchina non conserva l'intenzione del programmatore. Ogni volta che si legge un programma privo di documentazione si effettua un'operazione costosa di reverse intentioning, non dissimile dal reverse engineering ma ad un livello superiore. Scrivere codice corretto è difficile, scrivere codice espressivo lo è ancora di più, scrivere contemporaneamente codice espressivo e il testo che completi quell'espressività, inevitabilmente insufficiente, è difficilissimo e non gode della verifica automatica, da cui la tipica insofferenza dei programmatori, pigri per definizione. La necessaria manutenzione del codice comporta la manutenzione della sua descrizione testuale: ma senza quella descrizione, la stessa manutenzione è molto più costosa e pericolosa. Concordo. Siamo chiamati ad essere contemporaneamente meccanici, domatori, scrittori e poeti: non meraviglia che tendiamo ad alleggerire il fardello. Ahimè, non è una buona idea. Qui meno :-) Diciamo che io l'ho letta in maniera diversa. Il commento spesso diventa un modo per non sforzarsi di tendere a del codice ben scritto ma per mettere una toppa (che schifo di roba ho scritto... potrei rifattorizzarla e sistemarla meglio, ma faccio prima a scrivere un bel commento per dire quello che dovrebbe fare questo guazzabuglio). Di fronte a un comportamento spesso come questo, diventa importante dare un segnale forte riguardo al commento che è spesso un male. Io almeno l'ho letta così. Ciao. Marco. -- http://beri.it/ - Un blog http://beri.it/i-miei-libri/ - Qualche libro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Il 04/ott/2014 23:43 Simone Federici s.feder...@gmail.com ha scritto: Marco Beri: Comunque bel messaggio, anche se non sono del tutto d'accordo. Meno male, mica sono il papa... Una frase del libro che mi ha colpito è (cito a memoria): ogni commento non banale è un insuccesso del programmatore che non è riuscito a scrivere del codice autoesplicativo. Forte, eh? Onestamente mi aveva convinto. Artisticamente apprezzo il pensiero. Siamo tutti alla ricerca del codice perfetto. Però non mi convince. Non perfetto: che si spiega il più possibile da solo. Facciamo un esempio, leggi questo codice senza commenti e dimmi che fa... se riesci obiettivamente a farti una idea del design in tempi record, può essere che mi butto dal ponte veramente. Puoi sempre dire che il design del codice che ti ho postato è scritto male e quindi il programmatore non merita di essere preso da esempio. Però a mio gusto è un gran pezzo di codice. https://raw.githubusercontent.com/django/django/b2aad7b836bfde012756cca69291c14d2fdbd334/django/db/models/sql/query.py Cacchio, un estratto più corto no? :-) Dai, prova a postare 20 righe che sono un bel codice e con commenti e ci provo. Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Marco Beri: https://raw.githubusercontent.com/django/django/b2aad7b836bfde012756cca69291c14d2fdbd334/django/db/models/sql/query.py Cacchio, un estratto più corto no? :-) Dai, prova a postare 20 righe che sono un bel codice e con commenti e ci provo. Se leggi il commento del modulo ti fai una idea del design. E' utile. Ok vediamo un modulo più semplice 100 linee. Tu lo ritieni sbagliato scrivere il commento nell'eccezione in fondo al modulo? https://raw.githubusercontent.com/django/django/master/django/utils/tzinfo.py ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Prima di tutto bella discussione e grazie a tutti coloro che l'hanno arricchita. Io credo che prima di decidere se un commento è giusto o sbagliato bisogna calarsi nel contesto. Le best practices possono essere lette e rilette e ma mai capite. A me capita spesso. Secondo me è uno degli arcani del mondo. Chiediamoci anche come nascono le best practices? Dall'esperienza dura sul campo? Da un principio di buon senso? Da una idea balzana del un nuovo arrivato? Se anche il papa mi dicesse di buttarmi dal ponte, prima di buttarmi cercherei dentro di me se fosse giusto oppure no. Cominciamo dal testo. Si può leggere la divina commedia senza leggere le note, facendosi portare dallo spirito poetico, oppure la si può leggere e studiare seguendo le note passo passo. E se le note sono interessanti ti danno parecchio in più. (in questo caso le note non sono state scritte dall'autore) Ma che centra la divina commedia con un programma? nulla e tutto. Entrambe sono costruite seguendo un linguaggio ed entrambe possono fare dei giri pindarici e machiavellici. Se potessimo leggere un programma scritto da un Dante Alighieri è probabile che si riuscirebbe difficile a seguirlo ma chissà che bello che sarebbe. Quindi chi scrive/programma conta. Non è che tutte le regole (o le best practices) valgono a priori. Tornando al contesto. La parola programma che ho usato poc'anzi, è del tutto generica. Non è che se scriviamo uno script, un videogioco, una web application, un sito web, un prodotto, un framework o una libreria vigono le stesse regole. A parte la finalità che è chiaramente diversa, è diverso il target. Se scrivo una libreria, significa che qualcuno o anche me stesso la riutilizzerà in futuro. Target programmatori. Come diceva Marco, vai di docstring e doctest soprattutto sulle API pubbliche. Se scrivo un framework la documentazione a forma di tutorial è la più importante. Almeno per la maggior parte del target. Vedi Django è parecchio utilizzato da programmatori e la sua forza è nei tutorial online, non certo nei commenti del suo codice. I commenti che sono importanti qui sono quelli che spiegano delle scelte, spesso facendo riferimenti ai ticket o bug segnalati. Su un framework come Django ad esempio non è che ti metti a commentare i componenti architetturali, perché la maggior parte di essi è già nota dalla documentazione online. Se volessi studiare il codice dell'orm ad esempio sarebbe più utile un documento architetturale che ti desse un immagine del design. Non so voi, ma spesso mi capita di andare a spulciare il codice open, e veramente poco spesso mi metto a leggere i commenti che non siano concisi. (e anche non banali come: creo la classe, calcolo il risultato etc...) Se scrivo un sito web, usando Django, certo non mi metto a commentare il codice, forse una o due classi dove faccio delle scelte, ma la maggior parte dei models, forms, admin, views, sono del tutto standard e non hanno bisogno di commenti. Il dominio, i modelli, sono del tutto inutili da commentare, meglio scrivere una breve introduzione o un glossario che spieghi il dominio piuttosto che spezzettare il discorso tra una classe e l'altra. Se scrivo un prodotto, vuol dire che sarà venduto e che dovrò gestire la sua evoluzione per diversi anni, andando dietro a decine o centinaia (magari migliaia) di clienti. Il che significa che la miglior documentazione tecnica sono i test. Inoltre se è un prodotto bisognerà anche scrivere il manuale di utilizzo utente. (ma è un altra storia) Solitamente se un prodotto o anche un progetto segue un particolare design la documentazione utile è fatta da howto per i novizi. Se un nuovo programmatore entra nel team deve essere in grado di lavorare nel progetto, quindi howto end-to-end che lo seguono passo passo su casi d'uso semplici che gli permettono di capire il complesso e vasto mondo. In conclusione, i commenti sono importanti, ma non sono l'unica fonte di documentazione. Sono essenziali se il target è un altro programmatore che deve usare la tua libreria. Ma non sono minimamente sufficienti per documentare il ciclo di vita di un prodotto. Vanno usati con parsimonia, meno commenti che codice almeno un rapporto 1 a 5. (imho) Inoltre lo so che è difficile, ma cerchiamo di scrivere codice come se fossimo scrittori che aspirano al successo. L'estetica non è importante per un calcolatore ma per un umano si. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Il 04/ott/2014 19:35 Simone Federici s.feder...@gmail.com ha scritto: TL;DR? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Simone Federici wrote: Se anche il papa mi dicesse di buttarmi dal ponte, prima di buttarmi cercherei dentro di me se fosse giusto oppure no. Il papa da solo no, ma... http://xkcd.com/1170/ -- Nicola 'tekNico' Larosa http://www.tekNico.net/ Impossible is just a big word thrown around by small men who find it easier to live in the world they've been given than to explore the power they have to change it. Impossible is not a fact. It's an opinion. Impossible is not a declaration. It's a dare. Impossible is potential. Impossible is temporary. Impossible is nothing. - Muhammad Ali ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
2014-10-04 19:55 GMT+02:00 Marco Beri marcob...@gmail.com: TL;DR? TS;DNU? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Nicola Larosa: Simone Federici wrote: Se anche il papa mi dicesse di buttarmi dal ponte, prima di buttarmi cercherei dentro di me se fosse giusto oppure no. Il papa da solo no, ma... http://xkcd.com/1170/ Bella! Anche se tutti i miei amici lo fanno, non vuol dire che lo devo fare pure io. Ad esempio, non so se è peggio buttarsi dal ponte o andare allo stadio... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Il 04/ott/2014 20:15 Nicola Larosa n...@teknico.net ha scritto: Simone Federici wrote: Se anche il papa mi dicesse di buttarmi dal ponte, prima di buttarmi cercherei dentro di me se fosse giusto oppure no. Il papa da solo no, ma... http://xkcd.com/1170/ Level of xkcd citation: master! Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Il 04/ott/2014 19:55 Marco Beri marcob...@gmail.com ha scritto: Il 04/ott/2014 19:35 Simone Federici s.feder...@gmail.com ha scritto: TL;DR? Comunque bel messaggio, anche se non sono del tutto d'accordo. Una frase del libro che mi ha colpito è (cito a memoria): ogni commento non banale è un insuccesso del programmatore che non è riuscito a scrivere del codice autoesplicativo. Forte, eh? Onestamente mi aveva convinto. Ciao. Marco. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Marco Beri: Comunque bel messaggio, anche se non sono del tutto d'accordo. Meno male, mica sono il papa... Una frase del libro che mi ha colpito è (cito a memoria): ogni commento non banale è un insuccesso del programmatore che non è riuscito a scrivere del codice autoesplicativo. Forte, eh? Onestamente mi aveva convinto. Artisticamente apprezzo il pensiero. Siamo tutti alla ricerca del codice perfetto. Però non mi convince. Facciamo un esempio, leggi questo codice senza commenti e dimmi che fa... se riesci obiettivamente a farti una idea del design in tempi record, può essere che mi butto dal ponte veramente. Puoi sempre dire che il design del codice che ti ho postato è scritto male e quindi il programmatore non merita di essere preso da esempio. Però a mio gusto è un gran pezzo di codice. https://raw.githubusercontent.com/django/django/b2aad7b836bfde012756cca69291c14d2fdbd334/django/db/models/sql/query.py ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
On 30/09/2014 12:06, Carlos Catucci wrote: 2014-09-30 11:38 GMT+02:00 Manlio Perillo manlio.peri...@gmail.com mailto:manlio.peri...@gmail.com: 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(nome) 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
Re: [Python] Agile programming Robert Martin
2014-09-30 10:38 GMT+01:00 Manlio Perillo manlio.peri...@gmail.com: 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
Il giorno 01 ottobre 2014 16:49, enrico franchi enrico.fran...@gmail.com 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
Il giorno 01 ottobre 2014 17:20, Massimo Capanni massimo.capa...@gmail.com ha scritto: Il giorno 01 ottobre 2014 16:49, enrico franchi enrico.fran...@gmail.com 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
Salve a tutti, Ciao Massimo [...] Ho visto che l'autore di questi video ha pubblicato questo libro: http://www.amazon.it/Clean-Code-Handbook-Software- Craftsmanship/dp/0132350882 E` uno dei tanti libri che un programmatore dovrebbe leggere nella vita, imho :-) e leggendo alcuni sample del libro mi chiedevo se: - a un modesto pythonista come il sottoscritto potesse servire a migliorare il suo codice Credo di si`. - se il manuale possa essere utilizzato anche in ambito Python Ti direi di si`. qualcuno di voi lo ha mai letto e, in caso affermativo, che impressioni e benefici ne ha ricavato? L'ho letto qualche tempo fa, ma l'ho in backlog per rileggerlo. Le impressioni sono buone, magari alcune parti sono un po' noiose, ma dipende dal lettore :-) Alla fine, un libro letto in piu` e` sempre cultura che ti porti a casa. un cordiale saluto a tutti Sani Strap ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
2014-09-29 18:25 GMT+02:00 Massimo Capanni massimo.capa...@gmail.com: Salve a tutti, 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. Alcuni progetti (come git) impongono anche dei messaggi di log in un DVCS che permettano di capire quali modifiche siano state fatte senza dover leggere in dettaglio la patch applicata [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
2014-09-30 11:38 GMT+02:00 Manlio Perillo manlio.peri...@gmail.com: 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(nome) e' secondo il mio modesto parere una delle cose piu' intelligenti che esistano. Certo vanno scritti bene, e aggiornati. Carlos -- EZLN ... Para Todos Todo ... ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Agile programming Robert Martin
Il giorno 30 settembre 2014 12:06, Carlos Catucci carlos.catu...@gmail.com ha scritto: 2014-09-30 11:38 GMT+02:00 Manlio Perillo manlio.peri...@gmail.com: 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(nome) e' secondo il mio modesto parere una delle cose piu' intelligenti che esistano. Certo vanno scritti bene, e aggiornati. Carlos -- EZLN ... Para Todos Todo ... sono d'accordo, infatti nel tutorial l'autore suggerisce proprio l'utilizzo dei commenti per la distribuzione delle librerie o segnalazioni particolari. Comunque, grazie dei pareri, gentilissimi come sempre :-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
