Python lower_case_with_underscores convenzione di stile: underscore non è popolare? [chiuso]

Le PEP dovrebbero essere lette con un pizzico di sale. È ciò che gli sviluppatori di Python vorrebbero fare se potessero pulire la lavagna, anche se è stata scritta molto più tardi di gran parte del linguaggio attuale. Per ragioni di compatibilità con le versioni precedenti, non è stato applicato retroattivamente a tutto e molti moduli erediteranno lo stile di denominazione dalle loro dipendenze principali anziché seguire le linee guida (che sono effettivamente intese e parte delle linee guida).

Sembra che fossero in un altro campo prima, e da qualche parte sono passati per ragioni di leggibilità.

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

Apprezzo un linguaggio che osa seguire la minoranza di sottolineatura, ancor più, cambia la loro convenzione esistente per il meglio!

CamelCasing esiste principalmente per ragioni storiche .

• "Solo alla fine degli anni '60 l'adozione diffusa del set di caratteri ASCII rendeva universalmente disponibili sia la lettera minuscola che il carattere di sottolineatura" _ ".
• I compilatori precedenti hanno severamente limitato la lunghezza degli identificatori (ad es. a 8 o 14 lettere)
• Infine, le ridotte dimensioni dei display dei computer disponibili negli anni '70 hanno incoraggiato l'uso di identificatori brevi.

Su una nota scientifica , è dimostrato che camelCasing legge 13,5% più lento rispetto all'utilizzo di caratteri di sottolineatura.

Naturalmente, è ancora importante seguire le convenzioni come risulta anche da questi Programmers.SE risponde sull'argomento .

Per le variabili locali, underscored_lowercase funziona bene, così come InitialCapitalCamelCase per i nomi di classe. Questo è tutto per PEP8.

C / Java traccia un buon bilanciamento, imho, usando initialLowerCamelCase per le funzioni che è difficile mescolare con vars o classi locali. Mentre lo stdlib di Python usa una convenzione diversa, molte librerie Python di terze parti usano questa convenzione. Questo non contraddice PEP8 che 'fornisce le convenzioni di codifica per il codice Python che comprende la libreria standard nella distribuzione Python principale' e non tenta di regolare altro codice.

Inoltre, come si suol dire, la coerenza conta. Non è così importante quale convenzione scegli, è importante mantenerla per tutto il tempo. Il punto della convenzione è rimuovere un pezzo di sforzo mentale riguardante la denominazione; l'incoerenza distrugge tutti i suoi benefici.