Contexte

Je suis sur le point de changer de travail et d'utiliser python sérieusement au travail, alors j'aimerais résumer le style de codage pythonique que j'ai examiné plus tôt en tant que critique.

UPDATE: Partie 2 a été mise à jour.

Contenu de cette page

L'adhésion à PEP 8 est la première base. Il existe déjà de nombreux articles, y compris la traduction japonaise existante, alors j'aimerais que vous accordiez la priorité à cela. Original Traduction japonaise

Autres articles Qiita: Conforme à la norme de codage Python PEP8 Résumé de la norme de codage Python PEP8 (1)

But de la création

Apprenez en traduisant + en résumant
Pratique de création de page Qiita
Je veux que le plus de gens possible connaissent la PEP 8

(D'une certaine manière, j'ai l'impression que ce genre de chose est proclamé par quelqu'un qui fouille régulièrement.)

La deuxième fois, je résumerai le contenu qui ne figure pas dans PEP 8. Si vous avez des suppléments ou des suggestions (je ne suis pas japonais, veuillez donc l'indiquer en japonais), veuillez me donner Masakari. Puis au sujet principal ~

supposition

La lisibilité est importante: le code est souvent lu plutôt qu'écrit
Le style change
La cohérence est importante: essayez d'unifier les styles dans la même fonction ou module autant que possible
Préférez le style local s'il entre en conflit avec le style de codage local du projet
S'il y a un conflit avec le style passé du projet, la priorité est donnée au style existant

Disposition du code

Retrait

4 espaces
Onglet souple
Méthode de rupture de code longue 1-Aligner le début de codes similaires

test = long_function(var1, var2,
                     var3, var4)

Méthode de rupture de code longue 2-code de distinction avec indentation supplémentaire

def long_function(
        var1, var2,var3,
        var4):
    print(val_one)

Méthode de saut de ligne de code long 3-Retrait suspendu

test = long_function(
    var1, var2, var3,
    va4)

Ajouter un commentaire ou une indentation supplémentaire lors de la rupture d'une longue instruction if. ʻSi (ʻest exactement un indent, donc le code peut être difficile à lire

if (hoge1_is_true and
    hoge2_is_true):
    #commentaire
    do_something()

#OR
if (hoge1_is_true
        and hoge2_is_true):
    do something

La parenthèse fermante de la structure () [] qui est cassée peut ou non être indentée.

my_list = [
    1, 2, 3,
    4, 5, 6
    ]

#OR
my_list = [
    1, 2, 3,
    4, 5, 6
]

Longueur de la ligne

Le code doit contenir au maximum 79 caractères
Maximum 72 caractères pour les données de chaîne et les commentaires avec moins de restrictions de format
Il est recommandé de mettre le code entre parenthèses au moment du saut de ligne
Peut être "" pour les éléments qui ont déjà des parenthèses, comme avec, assert

Utilisez des parenthèses:

if (hoge1 and hoge2
        hoge3 and hoge4):
    do_something

""utilisation:

with open(filepath1, "r") as file1, \
     open(filepath2, "r") as file2:
    do_something

Emplacement de la ligne de rupture

Ligne de rupture avant l'opérateur pour plus de lisibilité

revenue = gacha1_price * payers1
          + gacha2_price * payers2
          + gacha3_price * payers3

Ligne blanche

2 lignes vides entre les classes de niveau supérieur et les fonctions globales
1 ligne vierge entre les méthodes
Ajoutez des lignes vides à différents types de méthodes et de code
Ce n'est pas grave même s'il n'y a pas de ligne vierge entre les doublures similaires

Encodage du fichier source

Utilisez essentiellement UTF-8
Exception:
Cas de test spécial
Lorsque vous devez absolument écrire un nom contenant des caractères qui ne sont pas inclus dans UTF-8

importer

Directement ʻimport` doit être fait sur une ligne séparée

import pandas
import numpy

Dans le cas de "from ... import", il peut y en avoir plusieurs

from sklearn.linear_model import LinearRegression, LogisticRegression

L'emplacement d'importation doit être après la description du module et avant la définition de la variable globale.
L'importation est divisée dans les groupes suivants et une ligne vierge est insérée entre les groupes.
standard library
3rd party library
local library
Utilisez l'importation absolue. Évitez les importations relatives
N'utilisez pas from <module> import *! Si vous le faites sans espace de noms, vous ne saurez pas ce qui est importé

Emplacement de l'instruction Dunder au niveau du module

Après la description du module
Avant la déclaration d'importation
Après l'importation de __future__

"""This is the example module.

This module does stuff.
"""

from __future__ import barry_as_FLUFL

__all__ = ['a', 'b', 'c']
__version__ = '0.1'
__author__ = 'Cardinal Biggles'

import os
import sys

autre

Évitez les déclarations composées

#Yes
if foo == 'blah':
    do_blah_thing()
do_one()
do_two()
do_three()

#No:
if foo == 'blah': do_blah_thing()
do_one(); do_two(); do_three()

Citation

python ne fait pas la distinction entre «» «et» », donc ce n'est pas grave si vous l'unifiez dans votre code
Cependant, utilisez "" "" `pour les commentaires des trois quarts.

"""This is how you write 
documentatoin string.
"""

Espace dans le code

Évitez les espaces suivants

Proche entre parenthèses

#Yes
buger(bread[2], {cheese: 1})
#No
buger( bread[ 2 ], { cheese: 1 } )

Entre virgule et parenthèse fermante

#Yes
a_tuple = (0,)
#No
a_tuple = (0, )

Virgule, point-virgule, juste avant les deux points

#Yes
if a: print x, y; x, y = y, x
#No
if a : print x , y ; x , y = y , x

Lorsqu'il est tranché, le deux-points est traité comme un opérateur, donc, en gros, placez la même quantité d'espace des deux côtés (sauf lorsqu'il est omis).

#Yes
ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
#No
ham[1: 9], ham[1 :9], ham[1:9 :3]

Lors du découpage, insérez des espaces des deux côtés des deux points pour les formules et les appels de fonction.

#Yes
ham[lower+offset : upper+offset], ham[: upper_fn(x) : step_fn(x)]
#No
ham[lower + offset:upper + offset]

Immédiatement avant la liste des variables de l'appel de fonction

#Yes
func_call(params)
#No
func_call (params)

Immédiatement avant l'index de la liste ou du dictionnaire

#Yes
dct['key'] = lst[index]
#No
dct ['key'] = lst [index]

Lors du remplacement, assurez-vous qu'il n'y a qu'un seul espace à côté de =

#Yes
x = 1
y = 2
long_variable = 3

#No
x             = 1
y             = 2
long_variable = 3

Espace supplémentaire en fin de ligne
Affectation à une variable mot-clé lors de l'appel d'une fonction

#Yes
def complex(real, imag=0.0):
    return magic(r=real, i=imag)
#No
def complex(real, imag = 0.0):
    return magic(r = real, i = imag)

Mettons l'espace suivant

Généralement un espace de chaque côté des opérateurs suivants
Système de substitution =, + =, - =, etc.
Système de comparaison ==, <,> ,! =, <>, <=,> =, in, not in, is, is not
système booléen ʻet, ou, pas`
Lorsque des opérateurs avec des priorités différentes sont utilisés, des deux côtés de l'opérateur avec la priorité inférieure
Évitez plus d'un espace
Faire le même nombre d'espaces des deux côtés

#Yes
i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

#No
i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)

Au moment de l'annotation de la fonction
Un après le côlon
Les deux côtés de ->

#Yes
def munge(input: AnyStr): ...
def munge() -> AnyStr: ...

#No
def munge(input:AnyStr): ...
def munge()->PosInt: ...

Mettez à la fois l'annotation de variable et l'affectation normale dans = lorsqu'elles se produisent en même temps

#Yes
def munge(sep: AnyStr = None): ...
def munge(input: AnyStr, sep: AnyStr = None, limit=1000): ...

#No
def munge(input: AnyStr=None): ...
def munge(input: AnyStr, limit = 1000): ...

Fin virgule

Peut être joint
En gros, mettre entre parenthèses

#Yes
FILES = ('setup.cfg',)
#No
FILES = 'setup.cfg',

Affichage multiligne

#Yes
FILES = [
    'setup.cfg',
    'tox.ini',
    ]
initialize(FILES,
           error=True,
           )

#No
FILES = ['setup.cfg', 'tox.ini',]
initialize(FILES, error=True,)

commentaire

Général

Il est préférable de ne pas faire de commentaires incompatibles avec le code et de s'assurer que les commentaires sont toujours à jour.
Faites des commentaires aussi appropriés que possible
Vous pouvez omettre les signes de ponctuation pour les commentaires courts, mais en gros, ajoutons-les correctement.
Insérez deux espaces après la ponctuation dans le document
Rédigez autant que possible vos commentaires en anglais. Un jour, il peut être lu par quelqu'un qui ne connaît pas la langue de l'auteur du code

Bloquer le commentaire

Fondamentalement, ce que vous écrivez pour du code
Prenez le même retrait que le code cible
En gros, commencez chaque ligne par #
Séparez les paragraphes de document avec seulement des lignes `#

Commentaire en ligne

N'en utilisez pas trop
Laissez au moins 2 espaces avant le commentaire en ligne
Les commentaires en ligne commencent par «#»
Les commentaires en ligne trop évidents n'ont aucun sens, alors évitez-les

Description du document

Voir PEP257 pour savoir comment écrire
Il est utilisé pour expliquer les modules, les classes et les méthodes, alors mettez-le sous la ligne def.
S'il y a plusieurs lignes, la fin «" "" ʻoccupe une ligne, mais dans le cas d'une ligne, placez-les sur la même ligne.

À propos de la dénomination

De base

C'est un gâchis pour l'instant, donc ce ne sera jamais parfait, mais pour le moment, suivons cette règle autant que possible lors de l'écriture de nouvelles choses à l'avenir
La dénomination d'API publique visible par l'utilisateur doit essentiellement refléter la fonctionnalité, pas la mise en œuvre
Reconnaître quel style de dénomination est utilisé est tout aussi important que de reconnaître où il est utilisé. Fondamentalement, les modèles suivants existent

b  #Minuscule simple
B  #Capitale unique
lowercase  #Tout en minuscules
lower_case_with_underscores  # _Minuscule avec
UPPERCASE  #Tout le capital
UPPER_CASE_WITH_UNDERSCORES  # _Avec capital
CapitalizedWords  #Initiales majuscules
CapitalizeAbbreviationLikeHTTP  #Pour les initiales majuscules, toutes les abréviations appropriées doivent être en majuscules
mixedCase  #composite
Capitalized_Words_With_Underscores  #Initiales majuscules laides+ _

_single_leading_underscore  #Lors de l'utilisation uniquement à l'intérieur, comme privé
single_trailing_underscore_ #Pour éviter les conflits avec les mots-clés Python
__double_leading_underscore  #Modifications lors de la dénomination des variables de classe
__double_leading_and_trailing_underscore__  #Ne le définissez jamais vous-même

Utilisation du style de dénomination

join_lower est utilisé pour ** les noms de modules, les fonctions, les méthodes, les variables d'instance, les variables globales **
JOINED_UPPER est utilisé pour ** constante **
CapWords est utilisé pour ** les classes et les variables de type **
L'exception est une classe, donc la même ** règle CapWords **, mais toujours mettre ʻError` à la fin
N'utilisez jamais «l» (L inférieur), «O» (Oh), «I» (i supérieur) seuls. Difficile à distinguer

Autres règles de dénomination

La première variable de la méthode d'instance est self, la première variable de la méthode de classe est cls. Si une variable et un mot-clé entrent en collision, mettez un "_ "à la fin pour correspondre
Il n'y a pas de "_ "au début de la méthode publique
Pour les données publiques simples, il vaut mieux publier les paramètres directement que de préparer un accesseur.
Les variables de la classe qui seront héritées peuvent éviter les conflits de nom en mettant un double trait de soulignement au début du nom de la variable.
La rétrocompatibilité s'applique essentiellement uniquement à l'interface publique.
Pour faciliter la distinction entre les interfaces publiques et privées, définissez l'interface publique comme une liste dans __all__ lors de la définition du module.

Résumé sur le style pythonique (1): PEP8