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

70

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

poelinca
fuente
66
"honestamente, el código es más fácil de leer" ¿Opinión o hecho?
JD Isaacks
9
IThinkTheyAreBothAboutTheSame but_i_think_mixing_them_is_pretty_bad.
dietbuddha
77
@dietbuddha: Acabo de leer 'but_i_think_mixing_them_is_pretty_bad' mucho más rápido que 'IThinkTheyAreBothAboutTheSame'. Estoy bastante seguro de que se puede demostrar científicamente. :)
Steven Jeuris
@John Isaacks: Me entristece informar (como un defensor encubierto), que un estudio concluyó que "la cubierta del camello conduce a una mayor precisión entre todos los sujetos, independientemente del entrenamiento" .
Steven Jeuris
IWonderWhetherReadingEnglishWrittenInOneStyleVersusAototherMakesMuchDifference. InTheEnd, IFindThatNeitherIsMeryGoodAtBeingEasyToRead. Se "atornilla" horriblemente con la longitud de la línea y hace incluso la cosa complicada. I_wonder_whether_there_w__ould_language_support_in_the_future_for_quoted_variable_names. "En mi opinión, esto tendría mucho más sentido que camelCase o underscore_separators".
Christopher Mahan

Respuestas:

84

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.

Simon Whitaker
fuente
25
Un problema con los guiones bajos: usabilidad. Para la mayoría de los teclados (europeos), escribir el signo de subrayado requiere mantener presionada la tecla MAYÚS. También debe hacer eso para camelCase, pero puedo mantener presionada la tecla MAYÚS con el meñique y escribir cualquier letra, pero como la tecla de subrayado está justo al lado de la tecla MAYÚS, presionar ambas al mismo tiempo es bastante incómodo e interrumpe flujo de mecanografía.
LearnCocos2D
11
Para el primero, realmente encontré camelCase más fácil de leer, aunque el último es obviamente diferente.
Phoshi
19
De hecho, esto depende de lo que estás acostumbrado. Encuentro camelCases más fácil de leer, y además, son más cortos que los nombres de subrayado equivalentes.
Joonas Pulakka
17
Me odio a escribir guiones.
EpsilonVector
66
El punto de "usabilidad" es irrelevante para esto. El código generalmente es escrito solo una vez por una persona, pero digamos en el orden de 1 a 10 veces contabilizando alguna edición y programación potencial de pares. Pero el código generalmente es leído docenas / cientos / miles de veces por una o potencialmente muchas personas. Por lo tanto, hacer que el código sea fácil de leer es varias magnitudes más importantes que tener un código fácil de escribir.
hlovdal
97

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 =)

Alexey Anufriyev
fuente
23
La consistencia es una clave. Si está de acuerdo con la convención local o no, facilitará su propio tiempo (y el de todos los demás) al ser coherente. (A menos que la convención local sea en sí misma inconsistencia). Además, la legibilidad es principalmente un argumento falso: lea el código suficiente, descubrirá que hay poca diferencia a menos que decida que es ilegible.
Richard
1
Completamente de acuerdo. Simplemente creo que es mejor usar la convención de plataforma en lugar de las personalizadas, porque, por ejemplo, los nuevos integrantes del equipo se sentirán más cómodos con ella.
Alexey Anufriyev
2
Pero ¡ay de aquellos de nosotros que trabajamos en dos plataformas con dos convenciones, donde algunos prefieren y otros prefieren el otro!
Michael K
Si la plataforma tiene 2 convenciones, les pediría a todos los miembros del equipo que voten por una convención con la que se
sientan
20

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.

dafmetal
fuente
tiene toda la razón, sin embargo, estoy tratando de averiguar la opinión de la gente sobre la bruja que sería mejor usar (digamos para todo el equipo), y por qué ... mientras entiendo que algunas personas podrían estar acostumbradas a alguna convención o otros se sienten más naturales con el otro.
poelinca
20

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

Steven Jeuris
fuente
3
Por supuesto, de descartar todos los otros puntos debido a su preferencia por los guiones y los otros puntos no ayudará a su caso ...
Charles Boyung
2
@Charles: Sí y no, en mi humilde opinión, hago buenos argumentos por los que son descartables, y algunos de ellos incluso son discutidos como problemáticos por el propio documento. Un documento de seguimiento investiga algunos de los problemas de este documento , y los resultados son subrayados favorables.
Steven Jeuris
11

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".

Mark Harrison
fuente
12
El original no siempre es el mejor. Hay muchas malas prácticas en el libro del evangelio de K&R sobre C. Antes de que esto comience una guerra de llamas ... lea algunas de las recomendaciones de MISRA.
rápidamente_ahora
10
No olvide que K&R se escribió cuando no hay GUI-IDE. La mayor parte del trabajo se realizó en terminales de 80x25 caracteres, por lo que el espacio de la pantalla era escaso, ¡ if (...) {ahorrando una línea! En estos días, hay más espacio en la pantalla: ¿K&R sería diferente si se escribiera hoy con IDE GUI de alta resolución y múltiples configuraciones de monitor?
Skizz
3
Sí, pero cuando alguien dice que codifican C como K&R, obtienen accesorios por ser de la vieja escuela.
Christopher Mahan
3
@quickly_now, ¡habla con Dennis Ritchie y hazme saber lo que dice!
Mark Harrison el
Adopté mucho formato de MS: _internalToClassOnly, accesibleByGetter, PublicVariable.
Resumen de
10

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.

Carnicero paul
fuente
2
¡+1 por hacerme descubrir el modo gafas! Acabo de probarlo en un archivo de código que usa camelCase y noté cómo inmediatamente comenzó a verse mejor (ensamblaje con un montón de etiquetas en camelCase).
Gauthier
¿Qué es el modo gafas?
Marcie
8

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.

AShelly
fuente
No estoy de acuerdo con eso, escribes el código solo una vez, pero tienes que leerlo varias veces después
Roman Pekar
7

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 :)

duros
fuente
6

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
Lionel
fuente
8
@Kevin Cantu: En realidad, el nombre Javascript está en PascalCase en lugar de camelCase ...
Guffa
1
@Guffa: touché!
Kevin Cantu
2
@Kevin Cantu: en JavaScript: XMLHttpRequest<- Odio este nombre con pasión.
Thanatos
1
hypotheticalReasonsToNukeRedmond.push (XMLHttpRequest)
Kevin Cantu
44
@Lionel: en realidad, la notación húngara casi nunca se usa en C ++, ya que C ++ ya verifica sus tipos. Es más un artefacto histórico que otra cosa.
En silico
6

¡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();
Stephen
fuente
3
tengo que estar de acuerdo contigo, tener el primer personaje en minúsculas me vuelve loco! Odio camelCase con pasión.
HLGEM
En Java, donde los nombres son típicamente camelCased, los nombres de las clases realmente comienzan con una letra mayúscula. Esto es para distinguirlos de los nombres de los métodos.
James P.
5

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

Paul Stephenson
fuente
5

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 ... :(

Kosta
fuente
3
También estoy cansado de presionar shift para escribir guiones bajos.
Gauthier
8
Por lo general, esto no es posible para nombres de variables, ya que "-" generalmente significa menos.
Eric Wilson
4

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.

Ross
fuente
44
bueno, no es más fácil porque has leído en alguna parte, es más fácil porque fue el primero con el que trabajaste y principalmente porque estás más acostumbrado, por ejemplo, estoy más cómodo con el subrayado_casete.
poelinca
1
como en he leído que se realizó un estudio y encontré que era mejor ..
Ross
4

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á.

Colin Goudie
fuente
4

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é.

Gauthier
fuente
1
+1 para las últimas 2 líneas, sin embargo, no le recomiendo que combine las convenciones de nomenclatura, debe seguir con una u otra.
poelinca
Siempre que la convención esté bien definida (prefijo + guión bajo + PascalCase) ...
Gauthier
Me gusta usar guiones bajos para separar partes de un nombre que tienen propósitos semánticamente disjuntos, especialmente si la similitud en cualquier mitad puede ser significativa. Por ejemplo, las rutinas Motor1_Start(), Motor2_Start(), Motor1_Stop()y Motor2_Stop()tener una relación que podría ser menos clara sin los guiones.
supercat
4

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.

Kevin Cantu
fuente
1
Una de las razones para usar camelCase o underscore_case es que no necesito encontrar la definición de los objetos para discernir cuál es.
Joshua Shane Liberman
2

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.

phant0m
fuente
2

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.

Ed Harper
fuente
2

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

Dandre Allison
fuente
1

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.

Skizz
fuente
1
Ruego diferir, la apariencia de la fuente es importante. Consulte la teoría de ventanas rotas de "El programador pragmático". La convención de nomenclatura variable empeora la apariencia. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
Gauthier
1
@Gauthier: Aunque estoy de acuerdo con la idea de 'ventana rota', no creo que la capitalización de símbolos constituya una 'ventana rota'. Ciertamente, el código presentado de manera fortuita sí lo es, y mi proyecto actual ciertamente tiene mucho de lo que trato de ordenar siempre que puedo.
Skizz
Estoy de acuerdo. Puedo leer los tres igualmente bien. No importa. Solo uso lo que sea que esté usando el archivo, luego lo que proponga el lenguaje (python) y luego lo que sea que sienta que el proyecto será mejor servido. (Solía ​​programar en gwbasic, y todo era mayúscula - ¡los buenos viejos tiempos!)
Christopher Mahan
0

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.

Charles Bretana
fuente
0

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.

Bassam
fuente