Comment casser cette ligne de code en Python pour rester dans la limite de 79 caractères de PEP 8 ?
config["network"]["connection"]["client_properties"]["service"] = config["network"]["connection"]["client_properties"]["service"].format(service=service)
5 Réponses :
En utilisant le noir , le formateur de code opiniâtre et reproductible:
config["network"]["connection"]["client_properties"][
"service"
] = config["network"]["connection"]["client_properties"][
"service"
].format(
service=service
)
Cela peut être avisé, mais les noirs ne liront pas le code après vous. Les gens le feraient. Et cela semble beaucoup plus déroutant que d'autres solutions.
hehe, c'est un vaste sujet @YevhenKuzmovych; Je suis d'accord, peut-être que ce n'est pas pour tout le monde, mais il est bon de savoir que cela existe et cela fonctionne très bien pour certains. Il y a une vidéo pycon qui présente le noir; Je ne peux pas y accéder pour le moment, mais peut-être pourriez-vous le trouver et le regarder si vous avez un intérêt.
@YevhenKuzmovych avoir un standard est plus important que de savoir si ce standard est le meilleur résultat pour chaque situation. De nombreux projets utilisent le noir, donc même si ce n'est pas nécessairement le plus lisible, cela ne posera pas trop de problèmes pour quelqu'un qui y est habitué.
@JaredSmith Le premier chapitre (après l'introduction) de PEP 8: A Foolish Consistency est le Hobgoblin of Little Minds . "La lisibilité compte"!
Exactement @JaredSmith, merci - j'ajouterais que préserver la cohérence malgré que de nombreuses personnes modifient le même morceau de code n'est pas stupide, c'est génial. YMMV.
Cela permet également à tout le monde de gagner beaucoup de temps sur la manière de décomposer de longues lignes comme l'exemple de l'OP, et de raccourcir les discussions sans fin sur la meilleure façon de formater le code. Tant de victoires!
@YevhenKuzmovych Je trouve cela lisible (pas très, mais lisible). Cependant j'aurais écrit la partie format(service=service) sur une seule ligne. Briser la ligne ici est inutile et nuit à la lisibilité.
Merci @ReblochonMasque d'avoir mentionné le black .
Je vous en prie; cet extrait de code particulier n'est en effet pas la meilleure heure du noir. Dans l'ensemble, il présente quelques avantages, dont certains que j'ai énumérés ci-dessus, et je pense qu'il vaut la peine de l'essayer pour voir si cela vous plaît ou non.
le noir n'est qu'une des préférences des gars codifiées dans un outil - et beaucoup de lemmings disent "doit avoir une norme aussi horrible soit-elle".
La limite de 79 caractères combinée aux formateurs de code donne un code vraiment laid, ce n'est qu'une mode en Python.
Utilisez un \ :
config["network"]["connection"]["client_properties"]["service"] = \
config["network"]["connection"]["client_properties"]["service"].format(
service=service
)
Vous pouvez également utiliser une variable pour une meilleure lecture:
client_service = config["network"]["connection"]["client_properties"]["service"] client_service = client_service.format(service=service) # If you are using the value later in your code keeping it in an variable may # increase readability ... # else you can put it back config["network"]["connection"]["client_properties"]["service"] = client_service
Vos première et dernière lignes comportent 81 caractères.
Oui, tu as raison. Que ma suggestion ne fonctionnera probablement pas ici car vous ne pouvez pas vraiment réduire cette taille sans couper le nom de la variable encore plus court, ce qui n'est pas conseillé ici.
Cela ne modifie pas la valeur de config["network"]["connection"]["client_properties"]["service"] .
@Maggyero ça devrait . Cette dernière ligne devrait réaffecter la valeur dans le dict imbriqué.
Les crochets permettent une continuation de ligne implicite. Par exemple,
d = config["network"]["connection"]["client_properties"] d["service"] = d["service"].format(service=service)
Cela dit, je ne pense pas qu'il y ait un consensus sur la ligne à suivre par chaque parenthèse. (Personnellement, je n'ai jamais trouvé de choix qui semble particulièrement "juste".)
Une meilleure solution serait probablement d'introduire une variable temporaire.
config["network" ]["connection" ]["client_properties" ]["service"] = config["network"]["connection"]["client_properties"]["service"].format( service=service)
Compte tenu du fait que Python fonctionne avec des références, vous pouvez effectuer les opérations suivantes:
properties = config["network"]["connection"]["client_properties"] properties["service"] = properties["service"].format(service=service)
@BearBrown Bien que les questions demandant des améliorations de code puissent y trouver de bonnes réponses, cette question demande de l'aide pour parvenir à un changement clair et objectif; ce n'est pas hors sujet.
@TylerH je pense que c'est une bonne question pour
codereview@BearBrown bien que je sois sur le sujet pour le codereview qui ne le rend pas hors sujet pour SO . La révision de code ne peut pas gérer un afflux massif de questions, vous devriez donc demander s'il s'agit vraiment d'une question de révision de code ou d'une question qui est sur le sujet pour SO (et si elle est sur le sujet, laissez-la tranquille) _. Je dirais que c'est tout autant sur le sujet qu'une question demandant comment accéder à un élément dans un dictionnaire (bien que ce soit un doublon).
@BearBrown va de pair avec Error - Commentaire de Syntactical Remorses: ce message n'aurait pas assez de contexte pour CR; Veuillez consulter Est - ce que le fait d'être sur le sujet sur un autre site Stack Exchange crée automatiquement une question hors sujet pour Stack Overflow? , Migration des questions de code de Stack Overflow vers Code Review et cette réponse à Un guide de révision de code pour les utilisateurs de Stack Overflow
La limite de PEP-8 concerne uniquement le code de bibliothèque standard. Cela ne pose aucun problème avec les équipes, par accord, utilisant une longueur plus longue pour leur propre code.
Ce n'est pas basé sur l'opinion, même s'il y a plus d'une solution.
que se passe-t-il si l'un des éléments du chemin n'existe pas?
Voter pour rouvrir: ce n'est pas basé sur l'opinion, la question n'était pas "comment dois-je le formater au mieux?" mais "comment PEP 8 dit-il que je devrais formater ceci?".