Convenciones de nomenclatura: camelCase versus underscore_case? ¿Qué piensas al respecto? [cerrado]

He estado usando underscore_case durante aproximadamente 2 años y recientemente me cambié a camelCase debido al nuevo trabajo (he estado usando el último durante aproximadamente 2 meses y todavía creo que underscore_case es más adecuado para grandes proyectos donde hay muchos programadores involucrados, principalmente porque el código es más fácil de leer).

Ahora todos en el trabajo usan camelCase porque (eso dicen) el código se ve más elegante.

¿Qué piensas sobre camelCase o underscore_case?

PD por favor disculpa mi mal inglés

Editar

Algunas actualizaciones primero:

• la plataforma utilizada es PHP (pero no espero respuestas estrictas relacionadas con la plataforma PHP, cualquiera puede compartir sus pensamientos sobre cuál sería el mejor para usar, por eso vine aquí en primer lugar)

• Yo uso camelCase como todos los demás en el equipo (como la mayoría de ustedes recomiendan)

• utilizamos Zend Framework que también recomienda camelCase

Algunos ejemplos (relacionados con PHP):

• Codeigniter framework recomienda underscore_case, y sinceramente, el código es más fácil de leer.

• ZF recomienda camelCase y no soy el único que piensa que el código ZF es un poco más difícil de seguir.

Entonces mi pregunta sería reformulada:

Tomemos un caso en el que tiene la plataforma Foo que no recomienda ninguna convención de nomenclatura y es la elección del líder del equipo elegir una. Eres el líder de ese equipo, ¿por qué elegirías camelCase o underscore_case?

ps gracias a todos por las prontas respuestas hasta ahora

Estoy de acuerdo en que depende del idioma que estés usando hasta cierto punto; el código tiende a verse más ordenado cuando los nombres de sus símbolos siguen el mismo régimen de formato que las bibliotecas de valores y las incorporaciones del idioma.

Pero donde hay una opción, prefiero los guiones bajos al caso de camello, por una simple razón: encuentro que ese estilo es más fácil de leer. Aquí hay un ejemplo: ¿cuál te parece más legible? Esta:

aRatherLongSymbolName

o esto:

a_rather_long_symbol_name

La versión de subrayado me parece mucho más fácil de leer. Mi cerebro puede ignorar los guiones mucho más fácilmente de lo que puede detectar los límites minúsculas / mayúsculas en caso de camello, especialmente donde están los límites entre los glifos que se parecen a otros glifos del caso opuesto, o números ( I/l, O/0, t/I, etc.). Por ejemplo, esta variable booleana almacena un valor que indica si se ha construido un Igloo con el permiso de planificación adecuado (sin duda, un caso de uso común para todos nosotros):

isIllicitIgloo

Encuentro esta versión mucho más fácil de leer:

is_illicit_igloo

Quizás incluso peor que un nombre de símbolo difícil de leer es un nombre de símbolo fácil de leer. Los buenos nombres de símbolos se documentan automáticamente, lo que para mí significa que debería poder leerlos y comprender su significado de un vistazo. (Estoy seguro de que todos leemos las impresiones de códigos en la cama por placer, pero a veces también nos apresuramos). A menudo encuentro con nombres de símbolos de casos de camellos que es fácil leerlos mal y tener la impresión equivocada de un Semántica del símbolo.

Creo que debería usar la convención de nomenclatura adoptada por su plataforma. underscore_case se verá raro en el código C #, como camelCase en Ruby =)

Honestamente, realmente no importa mientras todos en el equipo usen el mismo esquema. Lo más probable es que uno u otro sea más natural para usted, aunque la importancia real es la legibilidad del código a largo plazo y luego es crucial que todos se adhieran a las mismas reglas de nomenclatura.

Basado en una respuesta, la respuesta de John Isaacks:

"honestamente, el código es más fácil de leer" ¿Opinión o hecho?

Decidí investigar un poco y encontré este artículo . ¿Qué tiene que decir la ciencia sobre el tema?

1. La carcasa de camello tiene una mayor probabilidad de corrección que los guiones bajos. (las probabilidades son 51.5% más altas)
2. En promedio, el caso del camello tardó 0.42 segundos más , que es 13.5% más largo.
3. El entrenamiento no tiene un impacto estadísticamente significativo sobre cómo el estilo influye en la corrección.
4. Aquellos con más entrenamiento fueron más rápidos en los identificadores en el estilo de caso de camello.
5. El entrenamiento en un estilo impacta negativamente el tiempo de búsqueda para otros estilos.

En mi publicación de blog sobre el tema, reviso el artículo científico y hago la siguiente conclusión.

Solo la lentitud del caso camel (2) es realmente relevante para la programación, descartando los otros puntos como irrelevantes debido a los IDEs modernos y a la mayoría de los usuarios de camelCase en el estudio. La discusión (junto con una encuesta) se puede encontrar en la publicación del blog.

Tengo curiosidad por cómo este artículo podría cambiar las opiniones. :)

Copia a los chicos más inteligentes

En el caso de los lenguajes de programación, copie el estilo del desarrollador del lenguaje.

Por ejemplo, codifico C exactamente como se hace en K&R.

Entonces, cuando alguien intenta iniciar una conversación aburrida al estilo de la codificación, puedo decirles "traigan eso con Dennis Ritche y háganme saber lo que dice".

En general, prefiero camelCase. Sin embargo, eso es porque la mayor parte de mi carrera, he trabajado en idiomas y entornos donde las guías de estilo normalmente recomiendan camelCase. (Java, ECMAScript, C ++). Usted, siendo una persona PHP, es probable que tenga la preferencia opuesta.

Dicho esto, cuando va más allá de threeOrFourWords, o si usa initialisms como XmlForExample, deja de ser tan legible.

Es por eso que emacs nos da el modo gafas.

el caso de Carmel

Este es uno de los pocos lugares donde siempre elegiré 'capacidad de escritura' en lugar de legibilidad. CamelCase es más fácil de escribir, y ser más amable con mis dedos gana sobre una ligera ganancia de legibilidad para mí.

suponiendo, por supuesto, que el proyecto no se basa en una base de código existente con un estándar diferente.

Es una pregunta interesante, he pensado en esto muchas veces. Pero no hay una respuesta definitiva, creo.

Siguiendo las convenciones "culturales" es una buena elección. "Cultural" en este caso significa convenciones establecidas en el equipo / empresa y, básicamente, también llevan las convenciones de lenguaje / plataforma. Ayuda a otros a leer / usar su código fácilmente y no requiere esfuerzos y tiempo adicionales para entender su código.

A veces es interesante romper las notaciones aceptadas. Uno de mis pequeños proyectos (en Python) lo utilicé underscored_namespara funciones de utilidad / métodos "protegidos" y estilo Java methodNamespara métodos. Mi equipo estaba contento con eso :)

Depende del lenguaje de programación.

Considero usar el caso en el mismo barco de si usar o no la notación húngara:

• Python: underscore_case, sin notación húngara
• C ++: camelCase, notación húngara

¡Ambos!

Hago un montón de desarrollo en CakePHP, y utilizo bien CamelCaseo $underscored_vars, de la siguiente manera (incluso fuera de CakePHP Proyectos):

1. nombres de archivo : /lowercased_underscored.phptípicos, pero vale la pena mencionarlos.
2. clases - class CamelCase extends ParentObject. Tenga en cuenta que, cuando se usa CamelCase, el carácter inicial no está en minúsculas. Me parece camelCaseque me veo realmente raro.
3. las variables -$are_variables_underscored === TRUE;
4. variables que contienen los casos -$CamelCase = new CamelCase();
5. claves de matriz -$collection['underscored_keys'];
6. constantes : creo que todos pueden estar de acuerdo en que las constantes deberían serlo ALL_CAPS_AND_UNDERSCORED.
7. métodos -$CamelCase->foo_method_underscored();
8. métodos estáticos -CamelCase::just_like_regular_methods();

Personalmente prefiero underscore_caseporque me parece más legible, pero estoy de acuerdo con los otros respondedores que señalan que la coherencia con la base de código existente es mucho más importante.

Sin embargo, tengo un contraejemplo para aquellos que dicen "sigue la convención de tu idioma y sus bibliotecas".

En el pasado escribimos código C en Windows usando underscore_case, y llamamos PascalCasefunciones Win32:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

La distinción visual entre nuestros nombres de funciones y los nombres de funciones de Microsoft fue una ayuda más que un obstáculo, como lo demostró claramente cuando el código entraba en "tierra del sistema".

Además, pude cambiar las reglas de resaltado de sintaxis de mi editor para mostrarlas en diferentes colores, lo que dio más pistas visuales al intentar comprender secciones de código desconocidas (o incluso las mías).

Realmente me gustan los guiones simplemente normales de Dylan, ya que son fáciles de escribir y fáciles de leer.

Me gusta

result-code := write-buffer(file-stream, some-string)

Pero supongo que como este lenguaje es bastante oscuro, esto está fuera de tema ... :(

Me enseñaron a usar camelCase en la universidad. He usado algunas convenciones diferentes en los últimos años, pero prefiero camelCase sobre cualquier otra cosa. Creo recordar haber leído en alguna parte que camelCase es en realidad el más fácil de leer y comprender.

Como la mayoría de la gente ha mencionado: use el estándar existente. Si se trata de un proyecto nuevo, use el estándar para el lenguaje y los marcos que usará.

Y no se confunda, no se trata de legibilidad (que es subjetiva), se trata de ser coherente y profesional. Cualquiera que haya trabajado en una base de código con numerosos 'estándares' en marcha lo entenderá.

A veces uso una mezcla: module_FunctionName. Todas las funciones (no estáticas) en mis módulos comienzan con una abreviatura de módulo.

Por ejemplo, una función para enviar el contenido de un búfer en el bus I2C:

i2c_BufferSend()

La alternativa i2c_buffer_sendno muestra una separación lo suficientemente grande entre el prefijo y el nombre de la función. i2cBufferSendse mezcla demasiado en el prefijo (hay muchas funciones I2C en este módulo).

i2c_Buffer_send Sin embargo, podría haber sido una alternativa.

Mi respuesta es que te adaptas a lo que funciona mejor para tu proyecto (tu idioma, tu arquitectura SW, ...), y quería señalar que mezclar estos estilos podría ser útil.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. Yo_respeto_el_facto_que_algunos_podría_ pensar_de otra manera_pero_Yo no_realmente_ entendido_por qué.

Personalmente, prefiero camelCase, pero en algunas fuentes creo que los guiones bajos son más fáciles de leer.

Sugeriría que si necesita usar prefijos para diferenciar conjuntos de variables, debe usar un lenguaje que le permita crear espacios de nombres u objetos o algo para contener esa información.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Del mismo modo, si necesita diferenciar tipos, ¿por qué no usar un lenguaje que los permita?

var intThingy = 7; // :(

int thingy = 7;    // :)

Una vez que lo tiene claro, y no solo está usando el nombre como metadatos, no tendrá suficientes nombres largos que importen mucho si prefiere o no presionar una tecla adicional.

Al principio, estoy de acuerdo con Dafmetal. Es de suma importancia que no mezcle diferentes estilos de programación. Hacer esto en un mismo archivo es lo peor que puedes hacer en mi humilde opinión. A través de diferentes archivos, es una distracción, pero no fatal.

Lo siguiente que tiene que hacer es nombrar reglas que sean populares para el lenguaje en el que está escribiendo. Mi código C ++ para instnace, se verá diferente a algo para Python, obviamente (PEP8 es una buena guía aquí)

También puede usar diferentes convenciones de nomenclatura para referirse a diferentes cosas, por mucho que probablemente use UPPER_CASE para constantes (esto solo se aplica a ciertos idiomas, por supuesto), puede usar this_style para nombres de variables locales, mientras que usa camelCase para instancia / miembro variables Esto puede no ser necesario cuando tienes cosas como selfo thissin embargo.

Actualizar

Tomemos un caso en el que tiene la plataforma Foo witch no recomienda ninguna convención de nomenclatura y es la elección del líder del equipo elegir una. Eres el líder del equipo, ¿por qué elegirías camelCase o por qué underscore_case?

No hay ventajas para uno sobre el otro realmente. Este asunto es muy subjetivo y una vez acordado, no hará la diferencia. Siempre hay guerras religiosas sobre estas pequeñas cosas. Pero una vez que te has acostumbrado a cualquiera de los dos, las discusiones parecen ser completamente superfluas.

Para citar a Alex Martelli sobre un asunto muy similar:

Claro, me canso, en Ruby, de escribir el tonto "final" al final de cada bloque (en lugar de simplemente desangrar), pero luego evito escribir el igualmente tonto ':' que Python requiere en el comienzo de cada bloque, así que eso es casi un lavado :-). Otras diferencias de sintaxis como '@foo' versus 'self.foo', o la mayor importancia del caso en Ruby vs Python, son realmente tan irrelevantes para mí.

Sin duda, otros basan su elección de lenguajes de programación en tales problemas, y generan los debates más candentes, pero para mí eso es solo un ejemplo de una de las Leyes de Parkinson en acción ( la cantidad de debate sobre un tema es inversamente proporcional a la del tema importancia real ).

Fuente

Si usted es el líder del equipo, simplemente vaya con uno. Dado que uno no tiene ninguna ventaja sobre el otro, puede lanzar dados o elegir lo que más le guste.

Leí hace varios años que los programadores que no hablan inglés como primer idioma tienden a encontrar el caso de subrayado más fácil de entender que el caso del camello, pero no puedo encontrar la referencia, y no tengo idea de si es cierto.

Para los lenguajes de programación que he usado, como Java, Python, C ++, he adoptado un formato claro:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variables_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Esto me permite discernir de inmediato con lo que estoy tratando. He encontrado que es útil mantenerlo por mí mismo, y debería ser fácil de seguir para alguien más que lea el código. Creo que, como otros mencionaron, la consistencia es lo más importante. Por lo tanto, creo que mi formato es lo suficientemente simple como para mantener, al tiempo que proporciona distinciones claras entre los tipos de nombres. Me imagino interface_Names_Are_Like_This y Abstract_Classes_Are_Like_This como posibles extensiones, pero parece ser más complicado de seguir y tal vez no sea tan útil hacer una distinción.

También he encontrado útil ser estricto y nombrar cosas en PascalCase, como un analizador HTML como HtmlParser en lugar de HTMLParser o HTMLparser. Porque creo que es más fácil recordar la regla estricta y mantiene los límites de las palabras más claros (desafortunadamente requiere errores ortográficos como HTML o SQL). De manera similar con camelCase, htmlParserMethod en lugar de HTMLParserMethod o HTMLparserMethod.

ACTUALIZACIÓN :

Desde entonces he encontrado uso en la expansión de estas reglas para incluir variables privadas. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

En Java, esto significa que los campos privados están, por definición, en un espacio de nombres diferente que las variables locales, lo que significa que puede omitir los this.campos privados. En otros formatos he visto el prefijo " m", pero esos formatos también usan camelCase para los nombres de las variables. Esto también me permite hacer una distinción entre los campos a los que solo debe acceder internamente la clase (y dejarlo muy claro cuando sucede fuera de la clase se object._field_xdestaca).

Si fuera por mí, no impondría ni insinuaría el uso de ningún estilo en particular porque, como programadores, podríamos leer un símbolo IfItIsInCamelCase o in_underscore_space o incluso in_SomeOtherStyle y comprender lo que significa. Tener que pasar una pequeña cantidad de tiempo analizando el símbolo no es una gran sobrecarga en el gran esquema de las cosas.

Ahora, supongo que el argumento principal para una convención es que usted sabe por adelantado cuál es el formato de un nombre de función / variable y no necesita buscarlo: ¿es LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Ahora, contrarrestaría ese argumento diciendo "¡Obtén un IDE que admita la finalización automática del estilo intellisense!" (aunque no siempre es posible).

Al final, sin embargo, realmente no importa qué estilo uses porque al compilador / intérprete realmente no le importa. Lo importante es que el nombre sea útil:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Tres estilos diferentes, pero sabes exactamente lo que hace cada uno.

Puede parecer tonto, pero no me gustan los guiones bajos porque el guión bajo es delgado y se esconde en texto de varias líneas y lo extraño. Además, en algunos (muchos) editores de texto y / o entornos de desarrollo, cuando hace doble clic en el nombre de un token para resaltarlo y copiarlo, arrastrarlo y soltarlo, el sistema no resaltará todo el token, solo resaltará una parte de la ficha, entre guiones bajos adyacentes. Eso me vuelve loco.

Tiendo a preferir camelCase por la tonta razón de que hago la mayor parte de mi desarrollo en Eclipse (para Java, PHP y JavaScript), y cuando I Ctrl+ ←o Ctrl+ a →través de palabras, en realidad se detiene en los límites de camelCase.

Es decir: myIntVariablesería tratado por Eclipse como 3 palabras cuando Ctrl+ ← →a través de él.

Sé que es un capricho extraño, pero prefiero poder editar las palabras del medio en un nombre de camelCase.