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

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

Casi sin excepción, los nombres de clase utilizan 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 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 se ve raro, y el # 2 parece violar el PEP 8.

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.

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 pedante ).

#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 se combinan dos acrónimos, es probable que desee dividir la funcionalidad entre los módulos (nunca se sabe cuándo está agregando la siguiente característica a su progtwig):

 from NASA import JPL from NASA import ARC 

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.

Lo estás haciendo bien.

Si ChristophD lo 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 frase de la guía de “Nombres de clase de CamelCase” comienza:

Casi sin excepción, […]

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

Emerson sobre la aplicación del 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, utilice su mejor criterio. 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).

Tiendo a usar el # 3. Parece raro al principio, pero (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úsculas 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 statement; Encuentro 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.

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 progtwigción en C #; así es como se supone que debes hacerlo en C #.

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.