Normes / bonnes pratiques de codage Python [fermé]

En python, utilisez-vous généralement PEP 8 - Guide de style pour le code Python comme normes / directives de codage? Y a-t-il d'autres normes formalisées que vous préférez?

"En python, utilisez-vous généralement PEP 8 - Guide de style pour le code Python comme normes / directives de codage? Y a-t-il d'autres normes formalisées que vous préférez?"

Comme mentionné par vous, suivez PEP 8 pour le texte principal et PEP 257 pour les conventions docstring

Avec les guides de style Python, je vous suggère de vous référer à ce qui suit:

1. Code comme un Pythonista: Python idiomatique
2. Erreurs courantes et verrues
3. Comment ne pas écrire de code Python
4. Python gotcha

Je suis les directives Python Idioms and Efficiency , par Rob Knight. Je pense qu'ils sont exactement les mêmes que PEP 8, mais ils sont plus synthétiques et basés sur des exemples.

Si vous utilisez wxPython, vous pouvez également consulter le Guide de style pour le code wxPython , par Chris Barker.

Je m'en tiens très étroitement au PEP-8.

Il y a trois choses spécifiques que je ne peux pas prendre la peine de changer en PEP-8.

• Évitez les espaces superflus immédiatement entre parenthèses, crochets ou accolades.

  Suggéré: spam(ham[1], {eggs: 2})

  Je fais ça quand même: spam( ham[ 1 ], { eggs: 2 } )

  Pourquoi? Plus de 30 ans d'habitudes ancrées se blottissent contre les noms de fonctions ou les mots-clés des instructions (en C). À commencer par Fortran IV dans les années 70.

• Utilisez des espaces autour des opérateurs arithmétiques:

  Suggéré: x = x * 2 - 1

  Je fais ça quand même: x= x * 2 - 1

  Pourquoi? La science de la programmation de Gries a suggéré cela comme un moyen de souligner le lien entre l'affectation et la variable dont l'état est modifié.

  Cela ne fonctionne pas bien pour les affectations multiples ou les affectations augmentées, pour cela j'utilise beaucoup d'espaces.

• Pour les noms de fonctions, les noms de méthodes et les noms de variables d'instance

  Suggéré: minuscules, avec des mots séparés par des traits de soulignement si nécessaire pour améliorer la lisibilité.

  Je fais ça quand même: camelCase

  Pourquoi? Plus de 20 ans d'habitude enracinée de camelCase, à commencer par Pascal dans les années 80.

PEP 8 est bon, la seule chose sur laquelle j'aurais aimé que cela se déroule plus durement était la guerre sainte Tabs-vs-Spaces.

Fondamentalement, si vous démarrez un projet en python, vous devez choisir Tabs ou Spaces, puis tirer sur tous les contrevenants à vue.

Pour ajouter à la liste des guides idiomatiques de Bhadra :

Consultez la présentation d'Anthony Baxter sur la programmation efficace en Python (d'après OSON 2005).

Un extrait:

# dict's setdefault method turns this:
if key in dictobj:
    dictobj[key].append(val)
else:
    dictobj[key] = [val]
# into this:
dictobj.setdefault(key,[]).append(val)

Je la suis extrêmement rigoureuse. Le seul dieu avant PEP-8 est les bases de code existantes.

Oui, j'essaye de le suivre au plus près.

Je ne respecte aucune autre norme de codage.

Je suis le PEP8, c'est un excellent style de codage.