2009-11-16 11 views
17

Dependiendo de su interpretación, esta puede ser o no una pregunta retórica, pero realmente me desconcierta. ¿Qué sentido tiene esta convención? Entiendo que las convenciones de nombres no necesariamente tienen que tener una rima o razón detrás de ellas, pero ¿por qué desviarse del ya famoso camelCase? ¿Hay una rima y razón detrás de lower_case_with_underscores que de alguna manera me falta? (y sí, he leído PEP 8 en su totalidad, y sí, entiendo que es meramente una propuesta, una guía, etc.)¿Por qué razón tenemos la convención de nomenclatura de lower_case_with_underscores?

Supongo que mi verdadera pregunta sería esta: estoy escribiendo un Python biblioteca. De hecho, con un poco de suerte, puede ser una biblioteca bastante grande, en relación con mis otros proyectos. Ya trato de adherirme a PEP 8 tanto como sea posible, y hasta ahora incluso he mantenido lower_case_with_underscores ya que PEP 8 instruye sobre nombres de funciones y métodos. Pero me molesta que tengo que recordar usar camelCase para Twisted, camelCase para logging, y casi todo lo demás. ¿Qué convención de nomenclatura debería usar y por qué?

Probablemente sorprenderá a la gente que me preocupe tanto por el nombre, lo suficiente como para escribir una larga pregunta al respecto, y me sorprende también. Tal vez tengo un pequeño TOC cuando se trata de estas cosas. No tengo mucha "opinión personal" al respecto, tanto como tengo la tendencia de elegir lo que más se usa, que en este caso sería camelCase, pero me molesta aún más descubrir que Probablemente estoy rompiendo algunas leyes eternas sobre explícito vs implícito y el zen de pitón escrito en piedra o algo así.

+5

"pero ¿por qué desviarse del ya famoso camelCase?" Creo que lower_case_with_underscores es mucho más antiguo que camelCase. Además, personalmente aborrezco camelCase de cualquier tipo de MixedCase con una pasión ardiente. Use la convención que prefiera. –

+1

Usar sistemas húngaros. : P Pero en serio, no sorprendería a la gente en absoluto: las convenciones de estilo de codificación son una guerra religiosa tanto como cualquier otro aspecto de la programación. Encontrará muchas preguntas sobre SO dedicadas a dónde colocar las llaves, o el zen del espacio en blanco. – Xiaofu

+1

¿Cómo se supone que el húngaro funciona con pato? : p –

Respuesta

47

camelCase y/o CamelCase (y eso es un debate en su propio derecho ;-) puede ser abrumadoramente más popular para el tipo de entornos que estamos más familiarizados, pero eso no los hace universales - o si tiene nunca he oído hablar del lenguaje oscuro llamado C++, con sus algoritmos std::find_first_of y std::replace_copy_if y así sucesivamente ?!

Así que no hay "desviación", como usted dice, en PEP 8 - simplemente una elección hacia el C++ - convenciones estándar contra las más populares, por ejemplo, Java o C#.

En cuanto a lo que debe hacer por su propio código, simplemente seleccione una convención y apéguese a ella - la consistencia es más importante que otras consideraciones. Mi empleador usa una convención CamelCase en todos los idiomas para todas las fuentes internas (aunque no necesariamente cuando se trata de exponer las API públicas, que es un problema aparte), personalmente lo detesto (ojalá pudiera destruir cada confianza en la distinción entre mayúsculas y minúsculas ¡el universo de programación! -), pero me atengo a él, y de hecho ayudo a aplicarlo (en revisiones de código), porque la uniformidad es importante.

Supongo que comprenderá por qué confiar en la distinción entre mayúsculas y minúsculas es una idea horrible solo si tiene que confiar en un lector de pantalla para leer el código: la mayoría de los lectores de pantalla hacen un trabajo horrible para detectar problemas , y no hay una manera realmente buena, ninguna convención fuerte o fácil de convertir las diferencias entre mayúsculas y minúsculas en pistas auditivas fáciles (mientras que traducir subrayados a "clics", en un buen lector de pantalla configurable, hace que sea muy fácil). Para las personas sin ningún tipo de impedimentos visuales, que sin duda es 90% o más, no es necesario que se preocupe (a menos que desee ser incluyente y ayudar a las personas que no comparten su regalo de visión perfecta ... naah , ¿a quién le importa esos muchachos, ¿verdad?!).

Pero la coherencia sigue siendo importante y ayuda a _every_body.

+12

¡Guau! Nunca consideré nombrar las convenciones como un problema de accesibilidad. +1 solo por abrir mis ojos a esto. – gotgenes

+3

@gotgenes, tx - y al mismo tiempo, alguien más lo hizo de forma anónima ... Supongo que a algunas personas simplemente no les gusta ** que les recuerden que no todos tienen una vista perfecta, así que, mencionando ese pequeño detalle también atraerá votos a la baja (bajo la tapa y la protección del anonimato, por supuesto, por cobardes anónimos felices de ser así ;-). Pero incluso haciendo que ** una ** buena persona como tú (alguien que _cares_ y que simplemente no estaba al tanto del tema) ahora consciente y con la posibilidad de considerar esto en el futuro, valga la pena lo que sea que los votos negativos se presenten en mi camino. –

+1

En segundo lugar, nunca antes había pensado en el tema de la accesibilidad. Gracias por iluminarme (a nosotros). – dav

2

Use la convención de nomenclatura que utiliza su tienda.

Si aceptan que la convención existente es tonta (o no tienen un estándar), y no les importa un poco limpiar todo el código para una convención nueva y mejorada (más estándar), entonces usted puede hacer eso.

15

He escuchado que en otros contextos se dice que las palabras con las marcas de los mandatos son más fáciles de separar para los lectores de inglés no nativos que las palabras de la Causa de la Palabra. Visualmente requiere menos esfuerzo analizar las palabras extranjeras separadas.

+0

Separación visual más fácil * es * la razón mencionada explícitamente para el lenguaje de programación Eiffel. También tienen este underscore_separator_standard. Probablemente también ayude a los lectores nativos de inglés :-) –

+0

. Es más fácil de leer en cualquier caso. Prueba de concepto: TheQuickBrownFoxJumpsOverTheLazyDog vs the_quick_brown_fox_jumps_over_the_lazy_dog. El último es posible leer a alta velocidad normal, mientras que el cerebro entra en el modo de concentración súper lenta cuando intenta decodificar la primera alternativa. – hlovdal

+3

Hmm - Creo que analicé el primero más rápido que el último. Aunque soy un hablante nativo de inglés. –

5

La convención de minúsculas con guiones bajos llega hasta las aplicaciones de Unix. Toda su syscall están en esta convención.

+3

Retrocede aún más: Lisp permite guiones en los identificadores, y los nombres de funciones de palabras múltiples en Lisps se separan con guiones de la misma manera que los idiomas modernos usan guiones bajos. Yo diría que este es al menos el mismo concepto (usando un personaje sustituto ya que el espacio en blanco no está permitido). –

2

Hagas lo que hagas, creo que es importante que seas coherente. He visto un par de guías de estilo (por ejemplo, Google Python Style Guide), que le indican que use guiones bajos.

Personalmente creo que usar letras minúsculas con guiones bajos hace que el código sea más fácil de leer.

Usted utiliza camelCasing? ¡No me importa! Siempre hay Glasses Mode. :)

0

Siéntase libre de hacer lo que más le convenga, pero considere usar una de las convenciones populares. Hace que sea más fácil para otros desarrolladores ponerse al día con su código.

Recuerde que durante la vida del proyecto, se pasa más tiempo leyendo el código de lo que se necesita para escribirlo.

6

Una razón podría ser históricamente, muchas computadoras no tenían capacidades mixtas. En los días de COBOL, los programas eran todos mayúsculas. A principios de los 80, muchas "computadoras personales" solo venían con letras mayúsculas. Por ejemplo, podría obtener una tarjeta de extensión de minúscula para Apple II +. Cuando los programas comenzaron a permitir la mezcla de casos, camel case no era popular. Muchos programas tomaron lo que solía ser todo en mayúsculas y se convirtieron a minúsculas. A través de los años 80 varios lenguajes atribuyeron el significado al caso, y en los años 90 Java popularizó la sintaxis de camelCase. Los lenguajes que tienen un historial anterior o que están más ligados a la programación del sistema Unix tienden a evitar el uso semántico de casos mixtos.

1

¿Fue Meyers quien creó unLongAndTotallyUnreadableMethodeName frente a una comparación de un_nuevo_nivel_pero_perfectamente_de_nombre_de_datos?

Si ya está acostumbrado a uno, su convención favorita se verá más natural. Pero los nuevos programadores pueden preferir subrayados (tamaño de muestra N = me, en el año 2001).

Creo que algunos lenguajes usan camelCase porque su API puede ser realmente horrible. Necesita el espacio adicional para que el código pueda caber en el IDE sin envolverse.

Por ejemplo:

poly = geometryLibrary.polygonGenerator.createFromPointSet(myList.listContentsToPointset()) 
+0

No estoy seguro de si el código de ejemplo es un argumento en contra del caso de serpiente, ya que no se ajusta bien a la Ley de Demeter. – Juliet

+1

¡Un ejemplo válido! –

11

LowerCaseWithUnderScoresAreSuperiorBecauseTheTextYouNormallyReadInABookOrNewsPaperForExampleIsNotWrittenLikeThis. .

+11

but_its_not_written_like_this_either_so_I_dont_see_your_point –

+40

@Scott: su comentario fue * mucho * más fácil de leer, sin embargo. –

+0

@Steve, tu comentario fue el más fácil de leer de todos ellos – Dennis

2

Es simplemente una convención, pero útil si trabaja con muchas abreviaturas.

¿Cómo escribiste EmailConfig (o fue EMailConfig)? HTTPRequest? email_config y http_request son entonces una convención mucho más clara.

Cuestiones relacionadas