Débutant à des normes de codage? Pylint peut être votre guide pour révéler ce qui se passe vraiment dans les coulisses et vous aider à devenir un programmeur plus conscients.
Partage de code est une entreprise enrichissante. Mettre votre code «là-bas» peut être soit un acte de philanthropie, la venue de l'âge », ou une extension de base de la croyance en open source. Quelle que soit la motivation, vos bonnes intentions peuvent ne pas avoir le résultat souhaité si les gens trouvent votre code difficile à utiliser ou à comprendre. La communauté Python a officialisé certains styles de programmation recommandées pour aider chacun à écrire du code dans une commune, convenu style qui fait le plus de sens pour le code partagé. Ce style est capturé dans PEP-8 . Pylint peut être un moyen rapide et facile de voir si votre code a capturé l'essence de PEP-8 et est donc «amical» à d'autres utilisateurs potentiels.
Peut-être que vous n'êtes pas prêt à partager votre code, mais vous souhaitez en apprendre un peu plus sur l'écriture meilleur code et ne savent pas par où commencer. Pylint peut vous dire où vous pouvez avoir exécuter égarer et vous orienter dans le sens de comprendre ce que vous avez fait et comment faire mieux.
Ce tutoriel est tout au sujet de se rapprocher des normes de codage avec peu ou aucune connaissance de programmation en profondeur ou les normes du code eux-mêmes. Il est l'équivalent de sauter le manuel et de sauter à droite dans.
Mon invite de ligne de commande pour ces exemples est:
Mise en route
Courir pylint sans arguments invoquera le dialogue de l'aide et vous donner une idée des arguments disponibles pour vous. Faites-le maintenant, à savoir:
Un couple des options que nous allons nous concentrer sur les voici:
Faites également attention à la dernière sortie peu d'aide. Cela vous donne une idée de ce pylint va «prendre à ':
Lorsque pylint est première manche sur un nouveau morceau de code, une plainte commune est qu'il est trop «bruyant». La configuration par défaut actuel est fixé à respecter tous les avertissements possibles. Nous allons utiliser certaines des options mentionnées ci-dessus, je pour l'adapter à vos préférences un peu mieux (et de le rendre «crier uniquement lorsque le besoin» donc).
Votre Première Pylint'ing
Nous allons utiliser un script python base comme fourrage pour notre tutoriel. Je l'ai emprunté largement à partir du code ici:http://www.daniweb.com/code/snippet748.html Le code de départ, nous allons utiliser est appelé simplecaeser.py et est ici dans son intégralité:
Commençons.
Si nous courons ceci:
Wow. Cela fait beaucoup de choses. La première partie est la section 'messages' tandis que la deuxième partie est la section 'rapport'. Il ya deux points que je veux aborder ici.
Le premier point est que tous les tableaux de statistiques (à savoir le rapport) sont un peu écrasante, donc je tiens à les réduire au silence. Pour ce faire, je vais utiliser les "-Rapports = n" option.
Pointe
Beaucoup d'options de ligne de commande couramment utilisés de pylint ont raccourcis. par exemple, "-Rapports = n" peut être abrégé "rn".La page man de pylint répertorie tous ces raccourcis.
Deuxièmement, l'expérience précédente m'a appris que la sortie par défaut pour les messages avait besoin d'un peu plus d'infos. Nous pouvons voir la première ligne est:
Cela signifie essentiellement que la ligne 1 viole une convention «C». Il me dit que je devrais vraiment avoir un docstring. Je suis d'accord, mais que faire si je ne comprends pas bien ce que je règle violée. Sachant seulement que je violé une convention est pas beaucoup d'aide si je suis un débutant.Une autre information, il est le symbole de message entre parenthèses, manquant-docstring ici.
Si je veux lire un peu plus à ce sujet, je peux revenir à la ligne de commande et essayez ceci:
Ouais, ok. Celui-là était un peu une évidence, mais je suis de fonctionner dans les messages d'erreur qui m'a laissé sans la moindre idée de ce qui a mal, tout simplement parce que je ne connaissais pas le mécanisme sous-jacent de la théorie de code. Une erreur qui perplexe mon esprit était novice:
Je reçois maintenant grâce à pylint pointant vers moi. Si vous ne recevez pas de celui-là, versez une tasse de café et de regarder en elle - laissez votre esprit programmeur grandir!
La prochaine étape
Maintenant que nous avons eu un peu de configuration des trucs sur la façon, nous allons voir ce que nous pouvons faire avec les avertissements restants.
Si nous ajoutons un docstring pour décrire ce que le code est censé faire cela peut aider. Je vais aussi être un cow-boy de bits et d'ignorer le message-module obsolète parce que je tiens à prendre des risques dans la vie. Un avertissement de dépréciation signifie que les futures versions de Python peuvent ne pas supporter ce code si mon code peut rompre à l'avenir. Il ya 5 invalide noms messages que nous allons arriver à plus tard. Enfin, je violé la Convention de l'utilisation des espaces autour d'un opérateur tel que "=" donc je vais arranger ça aussi. Pour résumer, je vais ajouter un docstring à la ligne 2, mettre des espaces autour du signe = sur la ligne 16 et utiliser le module = obsolète -disable d'ignorer l'avertissement de dépréciation.
Voici le code mis à jour:
Et voici ce qui arrive quand nous courons avec notre option de -disable =-module obsolète:
Nice! Nous sommes à seulement les messages non valide nom.
Il ya assez conventions bien définies autour de nommer les choses comme variables d'instance, fonctions, classes, etc. Les conventions mettent l'accent sur l'utilisation de majuscules et minuscules ainsi que les caractères qui séparent plusieurs mots dans le nom. Ceci se prête bien à la vérification via une expression régulière, donc le «devrait correspondre (([A-Z _] [A-Z1-9 _] *) |. (* __ __)) $".
Dans ce cas pylint me dit que ces variables semblent être constantes et doivent être en majuscules. Cette règle est en fait une convention de nommage qui est spécifique aux gens de Logilab qui ont créé pylint. Telle est la façon dont ils ont choisi de nommer ces variables. Vous pouvez aussi créer vos propres conventions de nommage dans la maison, mais le but de ce tutoriel, nous voulons en tenir à la norme PEP-8. Dans ce cas, les variables I déclarés doivent respecter la convention des minuscules. La règle appropriée serait quelque chose comme: "doit correspondre à [a-z _] [a-z0-9 _] {2,30} $". Notez les lettres minuscules dans l'expression régulière (az contre AZ).
Si nous lançons cette règle en utilisant un rgx -const = '[a-z _] [a-z0-9 _] {2,30} $' option, il va maintenant être assez calme:
Les expressions régulières peuvent être tout à fait une bête afin de prendre ma parole sur cet exemple particulier, mais aller de l'avant et de lire jusqu'àsur eux si vous voulez.
Pointe
Ce serait vraiment une douleur dans le cul d'avoir à utiliser toutes ces options sur la ligne de commande tout le temps. Voilà ce que le fichier rc est pour. Nous pouvons configurer notre pylint pour stocker nos possibilités pour nous afin que nous ne disposons pas de les déclarer sur la ligne de commande. En utilisant le fichier rc est une belle façon de formaliser vos règles et rapidement les partager avec les autres. Invoquant pylint --generate-rcfile créera un échantillon rcfile avec toutes les options définies et expliquées dans les commentaires.
Voilà pour l'intro de base. Plus de tutoriels suivront.
Aucun commentaire:
Enregistrer un commentaire