online - python docstring
¿Por qué razón tenemos la convención de nomenclatura lower_case_with_underscores? (10)
¿Fue Meyers a quien se le ocurrió una comparación de LongYMyTotallyUnreadableMethode vs. an_even_longer_but_perfectly_readable_method_name?
Si ya estás acostumbrado a una, tu convención favorita se verá más natural. Pero los nuevos programadores pueden preferir los guiones bajos (tamaño de muestra N = yo, 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())
Dependiendo de su interpretación, esto 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 una razón detrás de ellas, pero ¿por qué desviarse de la ya popular camelCase? ¿Hay una rima y una razón detrás de lower_case_with_underscores que me falta de alguna manera? (y sí, he leído PEP 8 en su totalidad, y sí, entiendo que es simplemente una propuesta, una guía, etc.)
Supongo que mi verdadera pregunta sería esta: estoy escribiendo una biblioteca de Python. 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 he mantenido lower_case_with_underscores como PEP 8 indica los nombres de funciones y métodos. Pero me molesta que tenga que acordarme de usar camelCase for Twisted, camelCase para el logging y casi todo lo demás. ¿Qué convención de nombres debo usar y por qué?
Probablemente sorprendería a la gente que me preocupe tanto su nombre, lo suficiente como para escribir una larga pregunta al respecto, y también me sorprende. Tal vez tengo un poco de TOC cuando se trata de estas cosas. No tengo mucho de una "opinión personal" al respecto, sino que tengo una tendencia a ir solo por lo que más se use, lo 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 contra implícito y el zen de python escrito en piedra o algo así.
Es solo una convención, pero útil si trabajas con muchas abreviaturas.
¿Cómo escribiste EmailConfig (o fue EMailConfig)? HTTPRequest? email_config y http_request son convenciones mucho más claras.
Hagas lo que hagas, creo que es importante que seas coherente. He visto un par de guías de estilo (por ejemplo, la Guía de estilo de Google Python ) que te dicen que uses 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 usa camelCasing? No me importa Siempre hay modo de gafas . :)
He escuchado que en otros contextos se ha dicho que es más fácil separar words_with_underscores para los lectores de inglés no nativos que wordByCamelCase. Visualmente requiere menos esfuerzo para analizar las palabras separadas, extranjeras.
La minúscula con la convención de guiones bajos se remonta a las apis de Unix. Todo su equipo está en esta convención.
LowerCaseWithUnderScoresAreSuperiorBecauseTheTextYormallyRead InABookOrNewsPaperForExampleIsWottenLikeThis. .
Siéntase libre de hacer lo que más le convenga, pero considere usar una de las convenciones populares. Facilita a otros desarrolladores ponerse al día con su código.
Recuerde que a lo largo de la vida del proyecto, se gasta más tiempo en leer el código que en escribirlo.
Una razón podría ser históricamente, muchas computadoras no tenían capacidades mixtas de casos. En los días de COBOL , los programas eran mayúsculas. A principios de los años 80, muchas ''computadoras personales'' solo venían con mayúsculas. Por ejemplo, podría obtener una tarjeta de extensión en minúsculas para Apple II +. Cuando los programas comenzaron a permitir el caso mixto, el caso de camello no era popular. Muchos programas tomaron lo que solía estar en mayúsculas, y solo se convirtieron a minúsculas. A través de la década de los 80, varios idiomas atribuyeron el significado al caso, y en los años 90, Java popularizó la sintaxis de camelCase. Los lenguajes que tienen una historia más antigua o están más vinculados a la programación del sistema UNIX tienden a evitar el uso semántico de casos mixtos.
Utilice la convención de nomenclatura que utiliza su tienda.
Si están de acuerdo en que la convención existente es estúpida (o no tienen un estándar), y no les importa un poco de trabajo limpiar todo el código para una convención nueva y mejorada (más estándar), entonces puede hacer eso .
camelCase y / o CamelCase (y eso es un debate en sí mismo ;-) puede ser abrumadoramente más popular para el tipo de entornos con los que está más familiarizado, pero eso no los hace universales, o nunca ha 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 lo establece, en PEP 8, simplemente una elección hacia C ++: convenciones estándar contra las más populares en, digamos, Java o C #.
En cuanto a lo que debe hacer para su propio código, simplemente elija una convención y apéguese a ella: la coherencia es más importante que otras consideraciones. Mi empleador utiliza una convención de 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 tema aparte), lo detesto personalmente (desearía poder destruir toda confianza en la sensibilidad a las mayúsculas y minúsculas en toda la programación universo! -), pero me atengo a él, y en realidad lo ayudo a cumplir (en las revisiones de código), porque la uniformidad es importante.
Supongo que entenderá por qué confiar en la sensibilidad a las mayúsculas y minúsculas es una idea horrible solo si tiene que utilizar un lector de pantalla para leer el código. La mayoría de los lectores de pantalla hacen un trabajo horrible al identificar problemas de casos, y no hay De una manera realmente buena, no existe una convención fuerte o fácil para convertir las diferencias de casos en pistas auditivas fáciles (al traducir los guiones bajos en "clics", en un buen lector de pantalla configurable, resulta muy sencillo). Para las personas sin ningún tipo de discapacidad visual, que sin duda es del 90% o más, no necesita atención (a menos que quiera ser inclusivo y ayudar a las personas que no comparten su don de visión perfecta ... naah, que se preocupa por esos tipos, ¿verdad?!).
Pero, la consistencia sigue siendo importante y ayuda a todo el mundo.