python - functions - ¿Cómo hace PEP 8-nombrar una clase cuyo nombre es un acrónimo?

pep8 pdf

Question

Intento adherirme a la guía de estilo para el código Python (también conocido como PEP 8 ). Por consiguiente, la forma preferida de nombrar una clase es usar CamelCase:

Casi sin excepción, los nombres de clase usan la convención de CapWords. Las clases para uso interno tienen además un guión bajo.

¿Cómo puedo ser coherente con PEP 8 si mi nombre de clase está formado por dos acrónimos (que en inglés apropiado deben estar en mayúsculas) Por ejemplo, si mi nombre de clase fuera ''NASA JPL'', ¿cómo lo llamarías ?:

class NASAJPL():  # 1
class NASA_JPL(): # 2
class NasaJpl():  # 3

Estoy usando el # 1, pero se ve raro; El # 3 también parece raro, y el # 2 parece violar el PEP 8.

Answer 1

Lo estás haciendo bien.

Si divide en una sugerencia de jerarquía de módulos no es una opción viable, entonces sugeriría que su forma # 2 ( class NASA_JPL (): es la más legible, se puede condenar el PEP-8.

No realmente...

Dicho esto ... No creo que el PEP-8 deba ser condenado para que usted use esa opción y aún se adhiera a sus principios básicos. Como señala en su pregunta original, la primera oración de la guía de "Nombres de clase de CamelCase" comienza:

Casi sin excepción, [...]

La declaración de "principios fundamentales" de PEP-8, como Dan alude a la línea "Una consistencia [...] tonta " , declara legibilidad y comprensibilidad los objetivos principales de las recomendaciones de PEP-8. PEP-8 es una colección de patrones establecidos y exitosos en el servicio a esos objetivos.

Emerson sobre la aplicación de PEP-8 a la realidad ...

Fundamentalmente, cualquier sistema tiene aspectos que son necesariamente inconsistentes con el carácter del conjunto. Cuando un sistema hace un uso bueno y consistente de las recomendaciones de una guía de estilo, cualquier inconsistencia será una respuesta consciente a la necesidad . (Considero que mantener la legibilidad de los casos de esquina es una necesidad).

Cuando se manejan de esta manera, esas inconsistencias, contraintuitivamente, refuerzan la cohesión del conjunto, en lugar de interrumpirlo.

PEP-8 dice esto de manera más sucinta (y, por lo tanto, más útil :)):

Pero lo más importante: saber cuándo ser inconsistente, a veces la guía de estilo simplemente no se aplica. En caso de duda, utiliza tu mejor juicio. Mira otros ejemplos y decide qué se ve mejor. ¡Y no dudes en preguntar!

Dos buenas razones para romper una regla particular:

1. Al aplicar la regla, el código sería menos legible, incluso para alguien que esté acostumbrado a leer el código que sigue las reglas.

2. Para ser coherente con el código circundante que también lo rompe (quizás por razones históricas), aunque esta también es una oportunidad para limpiar el desorden de otra persona (en el verdadero estilo XP).

Answer 2

Como han señalado otros, NASAJPL es probablemente el formulario aprobado por PEP-8.

Sin embargo, solo por el contrario, probablemente usaría NasaJPL. Porque si lo estás leyendo, pronuncias "NASA" como una sola palabra, mientras que "JPL" lo explicas.

Puede argumentar que esto es coherente con PEP-8, ya que "NASA" es un acrónimo, pero "JPL" es una abreviatura (o initialism, si desea obtener pedantic ).

Answer 3

Depende del acrónimo. Otra opción sería la class NASAJpl(): que hace que parezca que "NASA" es la parte principal, y "JPL" es la parte subordinada.

Answer 4

El número 1 es demasiado difícil de leer para mí; no hay forma de saber que son dos acrónimos.

El número 2 viola PEP8, pero se ve bien. Recuerde: "Una consistencia tonta es el duende de las mentes pequeñas" :)

Me gusta el número 3 el mejor, pero hago mucha programación en C #; así es como se supone que debes hacerlo en C #.

Answer 5

También trabajo en un entorno con muchas siglas. Tiendo a preferir la forma # 3 porque, aunque en minúsculas partes de un acrónimo, delinea claramente partes del nombre. También evita la confusión cuando parte del nombre es un acrónimo y parte es una palabra.

Answer 6

Tiendo a usar el # 3. Parece raro al principio, pero tú (más o menos) te acostumbras. Fui de esta manera después de sufrir durante mucho tiempo bajo cadenas de acrónimos atascados, por ejemplo, NPCAIXMLParser era uno. Decidí que NpcAiXmlParser era mucho más fácil de leer y lo he estado haciendo desde entonces, a pesar de que ver estas cosas en minúscula todavía parece extraño a veces.

En términos de "los estándares", tiendo a pensar en estas entidades como "palabras" y, como tales, las capitaliza como yo capitalizaría cualquier otra palabra. Por ejemplo, si tuviera una variable local que representara algún NPC (personaje no jugador), lo nombraría "npc" y no "nPC".

En lo que respecta a PEP-8, no estoy de acuerdo con esta declaración; Me parece que la última ortografía de la palabra es preferible.

Nota: Cuando use abreviaturas en CapWords, use mayúsculas en todas las letras de la abreviatura. Por lo tanto, HTTPServerError es mejor que HttpServerError.

Answer 7

PEP-8 cubre esto (al menos parcialmente):

Nota: Cuando use abreviaturas en CapWords, use mayúsculas en todas las letras de la abreviatura. Por lo tanto, HTTPServerError es mejor que HttpServerError .

Lo que leería para significar que NASAJPL() es el nombre recomendado de acuerdo con PEP-8.

Personalmente, me parece que NasaJpl() el más fácil de escanear, ya que las letras mayúsculas marcan fácilmente los límites de las palabras y le dan al nombre una forma distintiva.

Answer 8

#1 en este caso particular me parece bien (si es realmente un acrónimo). Por curiosidad, ¿qué significa (y qué es exactamente la instancia de clase, tal vez un module sería el divisor más apropiado)?

class NASAJPL:

EDITAR : cuando está combinando dos acrónimos, es probable que desee dividir la funcionalidad en módulos (nunca se sabe cuándo está agregando la siguiente característica a su programa):

from NASA import JPL
from NASA import ARC