Pourquoi pylint s’oppose-t-il aux noms de variables à un seul caractère?

Je suis toujours habitué aux conventions python et à l’utilisation de pylint pour rendre mon code plus pythonique, mais je suis insortinggué par le fait que pylint n’aime pas les noms de variables à un seul caractère. J’ai quelques boucles comme celle-ci:

 for x in x_values: my_list.append(x) 

et quand pylint , pylint Invalid name "x" for type variable (should match [a-z_][a-z0-9_]{2,30} – cela suggère qu’un nom de variable valide doit être entre 3 et 31 caractères de long, mais j’ai regardé à travers les conventions de nommage du PEP8 et je ne vois rien d’explicite concernant les lettres minuscules simples, et je vois beaucoup d’exemples qui les utilisent.

Y a-t-il quelque chose qui me manque dans PEP8 ou s’agit-il d’une norme propre à pylint?

PyLint vérifie non seulement les recommandations du PEP8. Il a également ses propres recommandations, l’une d’entre elles étant que le nom d’une variable doit être descriptif et pas trop court.

Vous pouvez l’utiliser pour éviter de tels noms courts:

 my_list.extend(x_values) 

Ou modifier la configuration de PyLint pour dire à PyLint quel nom de variable est bon.

Un peu plus de détails sur ce que gurney alex a noté: vous pouvez dire à PyLint de faire des exceptions pour les noms de variables qui (vous jure) sont parfaitement clairs même si vous avez moins de trois caractères. Recherchez ou ajoutez à votre fichier pylintrc , sous l’en-tête [FORMAT] :

 # Good variable names which should always be accepted, separated by a comma good-names=i,j,k,ex,Run,_,pk,x,y 

Ici, pk (pour la clé primaire), x et y sont des noms de variables que j’ai ajoutés.

Dans les langages fortement typés, les variables de nom à 1 lettre peuvent être correctes car vous obtenez généralement le type à côté du nom dans la déclaration de la variable ou dans le prototype de fonction / méthode:

 bool check_modality(ssortingng a, Mode b, OptionList c) { ModalityChecker v = build_checker(a, b); return v.check_option(c); } 

En Python, vous n’obtenez pas cette information, donc si vous écrivez:

 def check_modality(a, b, c): v = build_checker(a, b) return v.check_option(c) 

vous ne laissez absolument aucun indice à l’équipe de maintenance quant à ce que la fonction pourrait faire, comment elle est appelée et à quoi elle retourne. Donc, en Python, vous avez tendance à utiliser des noms descriptifs:

 def check_modality(name, mode, option_list): checker = build_checker(name, mode) return checker.check_option(option_list) 

et vous ajoutez même un docssortingng expliquant ce que font les choses et quels types sont attendus.

La raison la plus profonde est que vous pouvez vous rappeler ce que vous entendez a , b , c , x , y et z lorsque vous avez écrit votre code, mais lorsque les autres le lisent ou même lorsque vous revenez à votre code, le code devient beaucoup plus lisible quand vous lui donnez un nom sémantique. Nous n’écrivons pas des trucs une fois sur un tableau noir, puis nous les effaçons. Nous écrivons du code qui pourrait durer une décennie ou plus et être lu plusieurs fois.

Utilisez des noms sémantiques. Les noms sémantiques que j’ai utilisés ont été comme le ratio , le denominator , obj_generator , le path , etc. Cela peut prendre une ou deux secondes supplémentaires pour les écrire, mais le temps que vous économisez essaye de trouver ce que vous avez écrit en vaut la peine.

De nos jours, il existe également une option pour remplacer regexp. C’est-à-dire si vous voulez autoriser des caractères uniques comme variables:

 pylint --variable-rgx="[a-z0-9_]{1,30}$"  

Ainsi, pylint correspondra à PEP8 et n’entraînera aucune violation supplémentaire. Aussi, vous pouvez l’append à .pylintrc .