Dovrei davvero usare tutte le maiuscole per le mie costanti?

Sono un programmatore Python principalmente che usa pylint per il codice sorgente di sfilacciamento. Sono in grado di eliminare tutti gli avvisi tranne uno: Nome non valido per una costante. Cambiare il nome in maiuscolo lo risolve, ma dovrei davvero farlo? Se lo faccio, trovo che il mio codice sembri brutto poiché la maggior parte delle variabili sono costanti (secondo il pilastro).

Probabilmente stai scrivendo codice in questo modo:

notes_director = argv[1]
chdir(notes_director)
files = glob('*.txt')
rand_file = choice(files)
with open(rand_file) as notes_file: 
    points = notes_file.readlines() 
    rand_point = choice(points)

È necessario spostare questo codice in una funzione:

def main():
    notes_director = argv[1]
    chdir(notes_director)
    files = glob('*.txt')
    rand_file = choice(files)
    with open(rand_file) as notes_file: 
        points = notes_file.readlines() 
        rand_point = choice(points)

# actually call the main function    
main()

Pylint presuppone che il codice che svolge effettivamente il lavoro si troverà all'interno di una funzione. Poiché hai questo codice al livello più alto del tuo codice anziché all'interno di una funzione, viene confuso.

In generale, è meglio lavorare all'interno di una funzione anziché al livello più alto. Ciò ti consente di organizzare meglio ciò che stai facendo e facilita il riutilizzo. Dovresti davvero avere codice che esegue un algoritmo al di fuori di una funzione in uno script veloce e sporco.

Sì. Secondo la norma PEP8 sulle costanti :

Le costanti sono generalmente definite a livello di modulo e scritte in lettere maiuscole con caratteri di sottolineatura che separano. Gli esempi includono MAX_OVERFLOWe TOTAL.

Versione lunga:

Nella comunità Python (come in molte altre comunità) esistono convenzioni su come scrivere codice. Questo è diverso dal codice di lavoro : anche se scrivi le tue costanti tutte in minuscolo, il tuo codice funziona ancora.

Ma c'è consenso della comunità (come documentato in PEP8) che viene "applicato" con strumenti come il pylint . Se programmi per la tua felicità, potresti trascurare i suggerimenti che la colonna sonora ti dà. Se vuoi uno scambio aperto con la community, noto anche come "qualcuno oltre a me stesso dovrebbe usare il mio codice", dovresti preparare il tuo codice secondo PEP8.

È necessario utilizzare la norma della comunità PEP8 e Python ALL_CAPS_CONSTANTS. È un indizio visivo comune, usato da decenni in C, Java, Perl, PHP, Python, bash e altri linguaggi di programmazione e ambienti shell. Ma nel moderno linguaggio online, TUTTE LE TAPPETTE SIGNIFICANO LA GRAZIA . E gridare è maleducato.

Python è, tuttavia, piuttosto incoerente ALL_CAPS_CONSTANTS. JavaScript potrebbe avere Math.PI, ma Python ha math.pi. Non esiste una costante più riconoscibile o duratura di π. Oppure considera sys.version_infola versione di Python su cui stai eseguendo. Costante al 100% per tutta la durata del tuo programma - molto più PORTo MAX_ITERATIONSo altre costanti che definiresti. O che ne dici sys.maxsize? Il valore intero nativo massimo della tua piattaforma è costante non solo su uno o due programmi, ma sulla durata del tuo hardware.

Se queste costanti - tra cui alcuni, come π ed e che sono costanti fondamentali dell'universo, e non variano nel tutta l'eternità - se essi possono essere minuscolo, così ... così can altre costanti. Puoi scegliere.

Ricorda, PEP8 è una guida di stile. Una linea guida, non una legge. Una linea guida spesso violata anche dalla libreria standard di Python. E citando un'altra linea guida Python di base, PEP20 (alias "The Zen of Python"):

• Bello è meglio che brutto
• La leggibilità conta
• La praticità batte la purezza.

Da un punto di vista pratico, quando un programma inizia YELLY_CONSTANTe SHOUTY_PARAMETERinizia a grattarsi, aiuta a ricordare che le costanti in maiuscolo generalmente non sopportano realmente gli ideali platonici , ma i parametri di un programma in esecuzione. Non c'è nulla di veramente costante su PORT, SITENAMEo NUMRUNS, e non devono essere gestiti come globali programma autonomo. Ad esempio, possono essere rilasciati in un dizionario come un bundle accessibile a livello globale di parametri del programma:

config = {
    'port': 80,
    'sitename': "Bubba's Blog",
    'numruns': 100,
}

Python ha anche una funzione di passaggio dei parametri di parole chiave che riduce la necessità di usare APPARENTLY_ANGRY_GLOBAL_VARIABLES:

def process_data(sitename, port=80, numruns=100):
    ...

process_data("Bubba's Blog")

In pratica, molti di questi valori verranno (o dovrebbero essere) letti da file di configurazione, variabili di ambiente del sistema operativo, argomenti della riga di comando o altre fonti per soddisfare l' inversione del principio / modello di controllo . Ma questa è una storia più grande per un altro giorno.

Sì, è abbastanza comune nella maggior parte dei linguaggi di programmazione (almeno quelli che uso).

Puoi fare riferimento a questo link di Google per condividere uno stile comune tra gli sviluppatori dello stesso team.

Si consiglia di utilizzare

Type                  |Public          |Internal
Global/Class Constants|CAPS_WITH_UNDER |_CAPS_WITH_UNDER