La qualità senza nome è un bellissimo post di antirez che esprime una filosofia che ho sempre condiviso.
La filosofia per cui si cerca la semplicità e la bellezza, quella per cui si fanno le cose bene per una spinta interiore che punta a ricercare la qualità e non per fare soldi, quella per cui ciò che si produce è espressione di se stessi e della voglia di creare.
Leggendolo mi è venuto in mente un altro articolo di Baricco su Renzo Piano e la nuova Morgan Library a New York: Nel ventre di Manhattan la memoria dell’Occidente.

“E’ il tempo che tu hai perduto per la tua rosa che ha fatto la tua rosa così importante”
[da "IL PICCOLO PRINCIPE" di Antoine de Saint-Exupery]

Quando dovete partire con un nuovo progetto, se dovete correggerne uno vecchio, se mettete mani su codice scritto in linguaggi che non conoscete ancora bene, sarebbe bene fare una cosa semplicissima.
Documentatevi prima di tutto su:

• regole di stile;
• costrutti idiomatici;
• funzioni di libreria.

di quel particolare linguaggio.

Non è difficile, siamo nell’era di internet e dell’opensource.
Potete cercare su google se esiste una guida.
Potete leggere le indicazioni dei maggiori esponenti di quel linguaggio.
Potete scaricarvi alcuni progetti opensource e analizzarli per vedere quali sono gli standard.
Potete comprare un libro, o prenderlo in prestito.
Eviterete di reinventare la ruota, di far esaurire i programmatori che rimetteranno mano al vostro codice, e soprattutto eviterete di sembrare ignoranti o menefreghisti.
Non ultimo, il vostro karma ne trarrà enorme giovamento.

Si lo so che è vecchia ma mi piace molto!
Se al prompt interattivo di Python digitate

>import this

comparirà “The Zen of Python”.
Un pezzo di alta filosofia per programmatori, secondo me valida per tutti i linguaggi.

Eccolo in inglese

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

E in italiano, per chi non mastica molto l’inglese

Bello è meglio che brutto.
Esplicito è meglio che implicito.
Semplice è meglio che complesso.
Complesso è meglio che complicato.
Lineare è meglio che innestato.
Diradato è meglio che denso.
La leggibilità è importante.
I casi speciali non sono abbastanza speciali da rompere le regole.
Anche se la praticità batte la purezza.
Gli errori non dovrebbero mai passare in maniera silente.
A meno che non vengano esplicitamente resi silenti.
Di fronte ad una ambiguità, rifuggi dalla tentazione di tirare a indovinare.
Dovrebbe esserci un — e preferibilmente soltanto un — modo ovvio per fare qualcosa.
Anche se questo modo potrebbe non sembrare ovvio alla prima occhiata a meno che tu non sia olandese.
Adesso è meglio che mai.
Anche se mai è spesso meglio che *esattamente* adesso.
Se l’implementazione è difficile da spiegare, è una cattiva idea.
Se l’implementazione è facile da spiegare, potrebbe essere una buona idea.
I namespaces sono una fantastica idea — facciamone di più!
Andate anche a vedervi il modulo python\lib\this.py