[Python] Agile programming Robert Martin

[Marco Beri]

2014-10-06 10:52 GMT+02:00 Nicola Larosa <nico a 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
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20141006/81635e93/attachment.html>