Standard / best practice di codifica Python [chiuso]

In python usi generalmente PEP 8 - Style Guide for Python Code come standard / linee guida di codifica? Ci sono altri standard formalizzati che preferisci?

"In python usi generalmente PEP 8 - Style Guide for Python Code come standard / linee guida di codifica? Ci sono altri standard formalizzati che preferisci?"

Come accennato, segui PEP 8 per il testo principale e PEP 257 per le convenzioni di docstring

Insieme alle guide allo stile di Python, ti suggerisco di fare riferimento a quanto segue:

1. Code Like a Pythonista: Idiomatic Python
2. Errori comuni e verruche
3. Come non scrivere codice Python
4. Python gotcha

Seguo le linee guida di Python Idioms and Efficiency , di Rob Knight. Penso che siano esattamente gli stessi di PEP 8, ma sono più sintetici e basati su esempi.

Se stai usando wxPython potresti anche voler controllare Style Guide per il codice wxPython , anche di Chris Barker.

Mi attengo molto a PEP-8.

Ci sono tre cose specifiche che non posso preoccuparmi di cambiare con PEP-8.

• Evita spazi bianchi estranei immediatamente tra parentesi, parentesi o parentesi graffe.

  consigliato: spam(ham[1], {eggs: 2})

  Lo faccio comunque: spam( ham[ 1 ], { eggs: 2 } )

  Perché? Più di 30 anni di abitudini radicate si scontrano con i nomi delle funzioni o le parole chiave delle istruzioni (in C). A partire da Fortran IV negli anni '70.

• Usa spazi intorno agli operatori aritmetici:

  consigliato: x = x * 2 - 1

  Lo faccio comunque: x= x * 2 - 1

  Perché? La scienza della programmazione di Gries ha suggerito questo come un modo per enfatizzare la connessione tra l'assegnazione e la variabile il cui stato viene modificato.

  Non funziona bene per assegnazioni multiple o assegnazioni aumentate, per questo utilizzo molti spazi.

• Per nomi di funzioni, nomi di metodi e nomi di variabili di istanza

  Consigliato: minuscolo, con parole separate da trattini bassi se necessario per migliorare la leggibilità.

  Lo faccio comunque: camelCase

  Perché? Oltre 20 anni di abitudine radicata di camelCase, a partire da Pascal negli anni '80.

PEP 8 è buono, l'unica cosa su cui vorrei fosse più difficile è stata la guerra santa Tabs-vs-Spaces.

Fondamentalmente se stai iniziando un progetto in Python, devi scegliere Tabs o Spaces e poi sparare a tutti i trasgressori a vista.

Per aggiungere alla lista di guide idiomatiche di bhadra :

Controlla la presentazione di Anthony Baxter sulla programmazione Python efficace (da OSON 2005).

Un estratto:

# 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)

Lo seguo in modo estremamente rigoroso. L'unico dio prima di PEP-8 sono le basi di codice esistenti.

Sì, cerco di seguirlo il più da vicino possibile.

Non seguo altri standard di codifica.

Seguo il PEP8, è un ottimo pezzo di stile di codifica.