Mercurial > pylearn
diff doc/v2_planning/coding_style.txt @ 1123:1a1c0c3adcca
coding_style: Added suggestion made by email by Francois about type checking
author | Olivier Delalleau <delallea@iro> |
---|---|
date | Wed, 15 Sep 2010 09:42:11 -0400 |
parents | 60ef81fe1825 |
children | 03b41a79bd60 |
line wrap: on
line diff
--- a/doc/v2_planning/coding_style.txt Tue Sep 14 23:24:59 2010 -0400 +++ b/doc/v2_planning/coding_style.txt Wed Sep 15 09:42:11 2010 -0400 @@ -350,4 +350,32 @@ OD: Check Django's guidelines (link above) * Standardize the merge commit text (what is the message from fetch?) +Type checking +------------- +(Suggested by Francois Savard) + +vu que vous êtes en train de vous occuper de l'aspect coding style, je +mentionne ceci, à faire ce que vous en voulez: j'aime bien éviter des +erreurs sur l'ordre de mes paramètres, sur les assumptions sur les +paramètres etc. en faisant des argument check. Ça remplace un peu le +static type checking des langages genre Java. + +En Python y'a une façon élégante de définir ses propres typecheckers, +value checkers etc. et ensuite les passer en paramètre à un décorateur de +fonction: + +http://code.activestate.com/recipes/454322-type-checking-decorator/ + +(Juste un exemple, vu que les checks peuvent être plus élaborés, inclure +des value checks (>0 etc.), être flexibles pour ne pas demander que ce +soit un type fixe mais plutôt que ça réponde à certaines contraintes (que +ça "ressemble" à un float, p. ex.). J'avais développé une lib pour faire +qqch du genre en Javascript). + +Je ne sais pas si vous comptiez parler de ça, et si ça vaut la peine, mais +personnellement je préfère du code à des commentaires qui peuvent être out +of sync avec le contenu d'une méthode. Si vous croyez que ça vaut la peine, +vous pourriez p-e définir des type/value-checkers standards pour éviter que +tout le monde redéfinissent les siens à sa façon. +