Puisque Folco m'a implicitement appelé ici depuis un autre topic... (d'ailleurs j'imagine que c'est un design pattern qui porte un nom, mais je le connais pas )

Pour ceux qui n'ont pas de commentaires dans leur code, c'est juste que vous ne les avez pas postés, ou que vous n'en mettez pas ?

Zeph (./1) :
def __bool__ (self): return self.code == 0 def __nonzero__ (self): return self.code == 0

Ça doit être parce que je ne connais pas le Python, mais je ne comprends pas ce code. J'imagine que le premier bloc permet de gérer les casts objet->booléen, mais le second me laisse perplexe : d'après le nom, ça ne devrait pas être return self.code != 0 plutôt ?

Zeph (./13) :
j'aime bien "fail early" et mettre des return assez tôt quand il n'est pas utile d'exécuter le corps de la fonction (en cas d'erreur par exemple).

Copain (mais j'en connais un qui n'est pas du même avis ^^)

Pen^2 (./3) :
privilégier la clause la plus courte avant le else pour la lisibilité.

Tiens, c'est amusant que vous soyez plusieurs à mentionner cet argument, je ne l'ai jamais entendu et je ne suis pas particulièrement convaincu. Naturellement, j'aurais plutôt tendance à mettre le cas le plus probable en premier (par exemple, if (fonction()) { truc; } else { // gestion d'erreur }, ça me semble un critère plus important pour la lisibilité. Mais c'est entièrement subjectif.

Pen^2 (./9) :
Elles apportent qu'elle permettent de construire le raisonnement, de raccourcir les expressions (les lignes), et aussi de débugguer. Et ça favorise aussi la factorisation, je ne compte pas les fois où je lis 15 fois de suite le même
getTruc().getMachin().doThis() et getTruc().getMachin().doThat()

(même si j'ai tendance à ne pas le faire systématiquement quand ce sont des expression simples ou que j'ai la flemme ^^)
Il vaut mieux un code (raisonnablement) plus long si ça lui permet d'être plus lisible. Sinon, on pourrait aussi virer tous les commentaires et minifier, ça raccourcirait les sources
Et le fait que les variables intermédiaires soient parfois difficiles à nommer ne veut pas dire qu'elles sont superflues ; comme dit un proverbe connu, il y a trois choses difficiles en info : nommer les choses, gérer l'invalidation des caches, et éviter les erreurs de décalage de 1 c'est moche comme formulation, mais je ne connais pas d'équivalent français de "fencepost error". D'ailleurs, ça existe aussi en mathématiques dès qu'une démonstration devient un peu touffue (sauf que les matheux trichent, ils utilisent plein de variables et de fonctions dont le nom ne fait qu'un caractère, du coup c'est illisible )