a4-dev team mailing list archive

[Andrea Corbellini <corbellini.andrea@xxxxxxxxx>]

On Thu, 2010-09-30 at 22:26 +0200, Andrea Gasparini wrote: 
> In data giovedì 02 settembre 2010 11:32:58, Andrea Corbellini ha scritto:
> > PyLint
> > ======
> > 
> > Si tratta di tool abbastanza lento e pignolo, ma il più completo in
> > circolazione. Spesso gli errori che trova non sono errori, ma è facile
> > zittirlo. È possibile sopprimere determinati messaggi in tre modi
> > (combinabili tra loro):
> > 
> > 1. Dalla riga di comando.
> > 2. Con un file di configurazione.
> > 3. Mettendo nei file .py dei commenti come questo:
> > 
> >   #pylint:disable-msg=123
> > 
> > Una volta addomesticato (i.e. una volta soppressi quei 5/6 warnings
> > inutili) è un tool davvero utile. Cerca sia errori nello stile (PEP8)
> > sia errori nel funzionamento del codice.
> [snip]
> > Suggerimenti e critiche sono ben accetti 
> 
> Mi sembra che tu propenda per questo, io francamente non ho preferenze, se non 
> che non siano troppo complessi da gestire. 
> Quindi per me va benone, hai un tuo file di configurazione già "scafato" ?

A dire il vero è il tool che odio di più. :-P
Comunque, io nei miei progetti uso sempre tutti i tool. In genere, creo
un piccolo script che fa andare automaticamente i tool, rende il loro
output uniforme e usa la corretta configurazione. Qui potete trovare il
mio script migliore:

  http://bazaar.launchpad.net/~beeseek-devs/beeseek/trunk/annotate/head%
3A/tools/lint

[ Notate soprattutto la tupla PyLint.args ]

Detto questo, recentemente mi sono accorto che esiste già un programma
che fa la stessa identica cosa dello script, solo che non mi ricordo il
nome. @Andrea Colangelo, te lo avevo mostrato qualche settimana fa, ti
ricordi il link?

> Giusto due osservazioni:
> * decidiamone uno e usiamone solo quello. (almeno per fare i check sui merge o 
> sui contributi altrui... poi ciascuno sul proprio codice puo' fare quel che 
> vuole)
> * cercherei di non essere troppo 'fussy' sui commit. Non siamo un gruppo di 
> sviluppatori pagati, e non siamo tanti (anzi, siamo proprio pochi, e in calo 
> :P ): va bene discutere sui merge, ma è mooooolto preferibile una patch :P
> Usando bzr e simili è abbastanza facile aggiungere codice al merge di qualcun 
> altro.

Come ho sottolineato altre volte, spesso il problema dei progetti
volontari è che i problemi cosmetici o ritenuti poco importanti vengono
dimenticati e non vengono mai risolti. Per cambiare un'indentazione ci
vuole davvero poco; vorrei evitare di rendere il codice illeggibile solo
per risparmiare due minuti (che sono anche tanti) per merge.

Vorrei anche ricordare che nulla obbliga chi propone il merge a pulire
il suo codice. In altri progetti, quando programmatori inesperti mi
presentano patch un po' messe male, mi occupo io stesso di pulire tutto,
lasciando una semplice nota sulla MP.

Quello che intendo dire è che se non vi va di usare un tool o simili,
posso occuparmene io, allo stesso modo di come mi occupo dei test e dei
refactoring occasionali (o meglio... di come dovrei occuparmi).

> Per il resto, visto che nel frattempo non ha risposto nessuno, se mi confermi 
> che pylint è secondo te il migliore, secondo me abbiamo deciso.
> ciaociao

-- 
Andrea Corbellini
Ubuntu Member  | http://www.ubuntu.com
BeeSeek Member | http://www.beeseek.org

Attachment: signature.asc
Description: This is a digitally signed message part