¿Cuál es la razón para usar minúsculas para la primera palabra en una variable local (por ejemplo, employeeCount, firstName)

20

Recibo muchas críticas de otros programadores debido a mi uso de una carcasa completa para todas mis variables. Por ejemplo, su programador típico usará employeeCountpara un nombre de variable, pero yo uso EmployeeCount. Utilizo una carcasa completa para todo , ya sea un método nulo, un método de retorno, variable, propiedad o constante. Incluso sigo esta convención en Javascript. Ese último realmente susurra las travesuras de la gente.

La razón típica dada por la que no debería seguir esta convención de carcasa "no estándar" es porque el caso completo debe reservarse para propiedades y métodos nulos. La variable local y los métodos que devuelven un valor deben tener la primera palabra en minúscula como int employeeCount = getEmployeeCount().

Sin embargo, no entiendo por qué.

Cuando cuestiono esto, parece que solo recibo una respuesta arbitraria de ese es el estándar . Cualquiera sea la respuesta, generalmente siempre se reduce a Así es como es y no lo cuestiono. Solo lo sigo. . Las respuestas arbitrarias nunca son lo suficientemente buenas para mí.

Desde mis primeros días de programación de macros de Excel 97 con el IDE de Office, nunca he necesitado una convención de mayúsculas o minúsculas para decirme si algo es o no una variable o propiedad local. Esto se debe a que siempre he usado una convención de nomenclatura muy intuitiva. Por ejemplo, GetNuggetCount()sugiere claramente un método que va a algún lado y obtiene un recuento de todas las pepitas. SetNuggetCount(x)sugiere que está asignando un nuevo valor al recuento de pepitas. NuggetCounttodo por sí mismo sugiere una propiedad o variable local que simplemente contiene un valor. Para el último, uno puede sentirse tentado a decir: "¡Ah, ja! Esa es la pregunta. ¿Propiedad o variable? ¿QUÉ ES?" A eso, respondería con: "¿Realmente importa?"

Así que aquí está el tl; dr ;: ¿Cuáles son las razones objetivas, lógicas y no arbitrarias para usar minúsculas para la primera palabra en su variable o método de retorno?

Editar: para MainMa

Reemplace este código con el primer ejemplo de código en su respuesta y vea qué tan bien se sostiene su argumento:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}
oscilantecretina
fuente
77
Si estuvieran en mayúsculas, habría alguien más preguntando por qué no están en minúsculas ...
m3th0dman
11
¿no sería bueno si nuestros todopoderosos IDE pudieran tener un complemento que mapeara nuestras preferencias personales para problemas estilísticos como este y nos permitiera usarlos pero detrás de escena, para la "versión real" del archivo fuente, aplicado la semántica de estilo del "proyecto". Es completamente un problema visual hasta que necesite auditar la versión oficial del archivo. solo soñando ...
Sassafras_wot
59
Desafortunadamente para usted, la razón real y válida es "porque es el estándar". Vale la pena que las personas en el mismo equipo sigan el mismo estándar de estilo de código. Si no puede ver por qué, entonces quizás debería hacer otra pregunta: "¿por qué son útiles los estándares?"
Andres F.
3
Siempre he asumido que los desarrolladores se decidieron por camelCase porque parecía kewl. No hay una razón 'objetiva' para camelCase en sí por encima de PascalCase. Personalmente, creo que PascalCase (como su ejemplo) es mucho más fácil de leer, y lo uso en la mayoría de los lugares que no sean JavaScript, donde me quedo con camelCase para no perderme las invitaciones a fiestas.
GrandmasterB
77
Investigación sobre las ventajas de tener un estilo de codificación estándar Realmente no importa cuál sea el estándar, solo que se cumpla.
Mr.Mindor

Respuestas:

88

Esa convención de nomenclatura se usa a menudo cuando las personas quieren poder dar a una variable el mismo nombre que su tipo. Por ejemplo:

Employee employee;

Algunos idiomas incluso imponen esa capitalización. Esto evita tener que utilizar nombres de variables molestas como MyEmployee, CurrentEmployee, EmployeeVar, etc Usted siempre puede decir si algo es un tipo o una variable, sólo de la capitalización. Eso evita la confusión en situaciones como:

employee.function(); // instance method
Employee.function(); // static method

Además, en inglés, los sustantivos generalmente no se escriben con mayúscula, por lo que no se puede afirmar que su capitalización sea "correcta".

Entonces, ¿qué tiene eso que ver con su situación? Obviamente no tiene problemas para leer su propio código, pero al mantener las cosas lo más consistentes posible, reduce la carga de trabajo mental de cualquier otra persona que necesite leer su código. En la codificación como en la escritura, ajusta su estilo para que coincida con los lectores.

Karl Bielefeldt
fuente
1
Tenga en cuenta que el problema todavía existe en el lenguaje utilizado por el OP, ya que las propiedades están en mayúsculas (por supuesto, las propiedades pueden tener el prefijo this., lo que evita la confusión; las variables locales no pueden tener dicho prefijo).
Arseni Mourzenko
1
@oscilatingcretin se llama PascalCase.
Mr.Mindor
21
Employee Employeefunciona, pero argumentaré que es más confuso para un lector humano que Employee employee. Este último parece dos cosas diferentes. El primero parece una repetición innecesaria.
Jamie F
14
@oscilatingcretin Exactamente: "asume que el lector comprende el marco subyacente ..." Me gusta leer JavaScript, Java, C #, C ++ y otros, y traducir el código en mi cabeza. No me gusta tener que seguir pensando "Oh, el compilador de este lenguaje puede tratar con x ". mientras estoy tratando de entender el significado del código.
Jamie F
1
Tenga en cuenta que employee.function()también podría ser un método estático, si el lenguaje permite llamar a métodos estáticos desde un objeto (como lo hace Java). El compilador da una advertencia, pero puede hacerlo.
Uooo
34

No hay ninguno Es lo que hace la mayoría de la gente, por lo que se ha convertido en el estándar porque eso es lo que todos hacen. Una gran cantidad de literatura sigue esta convención, por lo que las personas adoptaron el hábito.

La convención no es tan importante como la consistencia en todo el código. Siempre que todo se nombre de manera coherente para que pueda saber qué cosas son al mirarlas, realmente no importa si la primera letra está en mayúscula o no.

Me parecería extraño encontrar código escrito a su manera y diría que no me gusta. Pero eso es una cuestión de estilo.

Ahora, si está haciendo esto en el lugar de trabajo, sería mejor codificar al estilo del equipo para que el código permanezca consistente en todas partes. En lugar de que su código sea diferente a todos los demás.

http://thecodelesscode.com/case/94

Schleis
fuente
3
Desearía que la mayoría de los programadores fueran como tú. Muchos son cuestionablemente apasionados y / o dogmáticos acerca de seguir el estándar de carcasa que he mencionado.
oscilatingcretin
1
@Schieis importa si eres el próximo programador en trabajar en el proyecto.
N4TKD
3
@oscilatingcretin Puede terminar siendo tan apasionado y / o dogmático una vez que haya trabajado en un código lleno de contenido var m_someVariableID = GetVariableValueId(). Especialmente si tiene que hacerlo sin soporte de autocompletado.
Tacroy
77
Si está en un equipo, seguir ese estándar de equipos es importante. Sin embargo, tenga en cuenta que muchos lenguajes de programación tienen estándares de facto que debe tratar de seguir al crear un nuevo proyecto donde el equipo no tiene estándares (o donde el equipo le ha aplazado para que los establezca). Si no está seguro de qué convención de codificación usar, seguir la convención utilizada por el proveedor del idioma principal o el marco incluido es preferible a su propio estándar, a menos que pueda justificar su estándar.
Brian
2
@Schleis buena actualización, no estoy de acuerdo en que sea solo una cuestión de estilo, pero la convención y la convención se convierten en convención por buenas razones y deben seguirse. No es una religión y en algún momento debes ser muy convencional, pero debes tener una buena razón.
N4TKD
25

1. ¿Por qué existe el estándar?

Después de todo, ¿no sería mejor dejar que todos escriban el código de acuerdo con sus preferencias personales y dejar de hablar sobre qué estándar es mejor?

El hecho es que cuando estás habituado a un estilo, es más difícil leer el código que usa un estilo diferente. Su cerebro pasa más tiempo tratando de entender la convención (si hay alguna), en lugar de entender lo que hace el código.

¿Qué es más legible entre esas dos piezas de código?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

o:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Ambas piezas de código se ejecutan de manera similar. La única diferencia es que en el primer caso, cada desarrollador que trabajó en el proyecto usó su propio estilo. Esto hizo que el código fuera inconsistente, ilegible y peligroso. El hecho de que los miembros del equipo no pudieron ponerse de acuerdo sobre el tamaño de la sangría, junto con el hecho de que uno de ellos se negó a usar llaves después de cada ifcódigo extremadamente propenso a errores: al mirarlo, podemos creer que el segundo ifes ejecutado solo cuando el primero ifes verdadero, que no es el caso.

En el segundo caso, todos los desarrolladores siguieron el mismo estándar. Algunos de ellos eran quizás infelices, porque preferían dos espacios de sangría o porque estaban acostumbrados a métodos que comienzan con una letra minúscula. El hecho es que el código todavía es mucho más legible de esta manera, y aún lo sería si estuvieran usando un estándar diferente.

Al tener un estándar estricto y uniforme, hace que el código sea más fácil de leer.

2. ¿Por qué su estándar es mejor que el que inventé ahora?

Si cientos de miles de desarrolladores de todo el mundo usan un estándar, simplemente manténgalo. No inventes el tuyo: incluso si es mejor, es más fácil para ti migrar al estándar global que a esos cientos de miles de desarrolladores para comenzar a usar el tuyo.

Ejemplo: en mi propia empresa, tengo una convención específica para nombrar claves e índices primarios y externos en la base de datos. Esos nombres se ven así:

  • [FK for Application: CreatedByApplicationId],
  • [IX for SessionIPAddress: SessionId] o
  • [PK for RoleOfPassword: RoleId, PasswordId].

Personalmente, esta convención me parece excelente y extremadamente clara. Para mi. Pero apesta totalmente. Es una mierda, porque es mío, y porque ninguno de los miles de administradores de bases de datos nunca lo usó. Esto significa que:

  • Cuando contrate a un DBA, se verá obligado a aprender la nueva convención, en lugar de comenzar su trabajo ahora mismo,

  • No puedo compartir fragmentos de código en Internet tal como están: esos nombres de aspecto extraño perturbarán a las personas que leerán mi código,

  • Si tomo el código del exterior para usarlo en mi cuenta, me vería obligado a modificar los nombres para que sea uniforme,

  • Si algún día decido usar algún estándar conocido, me veré obligado a modificar cada uno de los cientos de nombres.

3. Entonces, ¿qué pasa con la capitalización?

Las propiedades tienen un alcance o visibilidad mayor que los campos o las variables locales. Hacer que las propiedades comiencen con una letra mayúscula, y los campos y las variables, con una pequeña va en esta dirección.

Si considera C #, esta lógica es lo suficientemente consistente.

Si considera Java, los métodos comienzan con letras minúsculas, que no siguen la lógica.

Entonces, no, no hay pruebas definitivas de que esta convención sea mejor que la suya. Es solo que se usa globalmente, y el tuyo no. Ninguno es mejor .

En JavaScript, las funciones comienzan con una letra minúscula, a menos que requieran un newantes. ¿No sería mejor a la inversa? Tal vez. El hecho es que durante años, los desarrolladores de JavaScript usaron este estándar, y no al contrario. Reescribir cada libro y obligar a cada desarrollador a cambiar el estilo ahora sería un poco complicado.

Arseni Mourzenko
fuente
1
En cuanto a la parte sobre el código que es menos legible porque sigue un estándar ligeramente diferente, nunca he tenido ese problema. A menos que las variables de alguien se denominen como hookyDookyDoo, ninguna convención de nomenclatura o mayúscula disminuye la legibilidad. Además, tenga en cuenta que no estoy diciendo que mi convención sea "mejor" ya que realmente no aporta nada especial a la tabla de desarrollo. Por último, no entiendo su punto de [Las propiedades tienen un alcance mayor ... va en esta dirección] . ¿Qué tiene que ver el alcance con la convención de carcasa? Ir en qué dirección?
oscilatingcretin
23
@oscilatingcretin, la pregunta no es si alguna vez has tenido ese problema, es si tus colegas lo han tenido. Obviamente lo han hecho, o no se estarían quejando.
Karl Bielefeldt
1
Re: su edición: su primer ejemplo de código demuestra un código simplemente pobremente construido y propenso a desastres. Mi OP no se trata de códigos mal construidos y propensos a desastres. Se trata exactamente del mismo código que su segundo ejemplo, pero con una convención de carcasa diferente. Edité su segundo ejemplo de código y lo publiqué en mi OP con mi convención de carcasa. Reemplace eso con su primer ejemplo de código, por favor.
oscilatingcretin
55
@oscilatingcretin: El primer ejemplo de código demuestra un código no mal construido, sino un código escrito por un equipo donde cada desarrollador siguió su propio estilo. Esto sucede con demasiadas bases de código, dado el tiempo suficiente (por ejemplo, cinco años). Nota: ¿se ha perdido el: "El hecho es que el código todavía es mucho más legible de esta manera, y aún lo sería si estuvieran usando un estándar diferente". ?
Arseni Mourzenko
66
@oscilatingcretin Hay mucha investigación que muestra que la consistencia disminuye significativamente el esfuerzo cognitivo requerido para entender algo que estás leyendo. Para la prosa regular, la mala ortografía, la mala puntuación y la mala gramática dificultan la lectura de alguien, ya sea que lo noten conscientemente o no. El código es lo suficientemente difícil de leer, sin que sea más difícil: el cumplimiento del "estándar común" (para su pila de tecnología de elección) aumenta la consistencia general y libera a las neuronas para concentrarse en el negocio importante de lo que hace el código, en lugar de cómo está escrito.
Bevan
10

Técnicamente, no importa (o al menos, en la mayoría de los idiomas no importa).

Sin embargo, la mayoría de las comunidades de programación (ya sean comunidades mundiales que se han formado alrededor de un idioma en particular, subgrupos de tales comunidades, grupos que se han formado alrededor de alguna biblioteca popular o kit de herramientas, o solo equipos individuales) han desarrollado estándares de codificación establecidos. Los detalles exactos son relativamente poco importantes (aunque en muchos casos, se puede hacer un buen argumento para ellos), qué es importante es que se adhieren a ellos.

No porque sean los mejores, sino porque son lo que todos los demás usan; Si sigue el estándar, su código será coherente con la mayoría del otro código que eventualmente terminará usando: bibliotecas, código de compañeros de equipo, lenguaje incorporado. Los nombres consistentes son una poderosa arma de productividad, porque significa que cuando adivinas el nombre de algo, generalmente adivinarás bien. ¿Es file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? La convención de nombres te lo dirá.

Llevar sus preferencias personales a cada idioma que encuentre es particularmente peligroso, porque antes que nada, cada idioma tiene su propia cultura, y las convenciones de nombres a menudo son incompatibles; y segundo, hay muchas diferencias sutiles entre los idiomas en lo que respecta a la denominación.

Solo un ejemplo: en C #, los tipos y las variables viven en espacios de nombres separados; El compilador es lo suficientemente inteligente como para saber la diferencia. Sin embargo, en C, ambos tipos de nombres comparten un espacio de nombres, por lo que no puede tener un tipo y una variable del mismo nombre dentro del mismo ámbito. Debido a esto, C necesita una convención de nomenclatura que distinga los tipos de las variables, mientras que C # no.

tdammers
fuente
Por lo tanto, realmente parece que algunos idiomas más antiguos han allanado el camino para la codificación de estándares de idiomas futuros (como su ejemplo C / C #). Eso es muy desafortunado porque tener que hacer un seguimiento de cómo encajar las variables y los miembros de los objetos solo agrega un nivel innecesario de complejidad que se puede hacer sin ellos.
oscilatingcretin
44
@oscilatingcretin Cuando todos usan la misma convención, no agrega complejidad continua, la convención se convierte en parte de su modelo mental para el idioma en cuestión Y facilita el uso de ese idioma. Esto es demostrable y medible.
Mr.Mindor
Te iba a votar pero primero dices que no importa, luego escribes varios párrafos explicando por qué importa. Si eliminas "no importa" al principio, te votaré.
Tulains Córdova
10

Me sorprende que nadie más haya dicho esto, pero creo que la diferencia de capitalización es increíblemente útil por una razón: es agradable y conveniente poder saber si una variable solo tiene alcance local o no. Si la variable es local, no me preocupo tanto por los efectos secundarios de cambiarla, como la refactorización del nombre. Entonces, me gusta una convención que distingue a los miembros de la clase de las variables de clase privada de las variables locales.

Con el Intellisense moderno, esto importa cada vez menos, pero aún me da algunos puntos de referencia a medida que leo el código para saber dónde debo buscar para encontrar la definición.

Y un poco de esto puede quedar de mi peor estilo hace años, cuando los métodos no encajaban tan bien en una pantalla.

Jamie F
fuente
Varios proyectos en los que he trabajado especifican algo como esto en su guía de estilo.
anaximander
7

Esto parece más una cuestión de convenciones que una convención específica.

Por cada convención que rompas, solo estás agregando más trabajo para todos los demás. Quizás en un mundo perfecto, toda la compañía trabaja en un solo producto durante toda su vida ... sin embargo, en realidad, esto no es cierto. La gente salta entre proyectos, a veces entre empresas o incluso por diversión. Cuanto más aleatorio sea el código, más difícil y costoso será trabajar en él. Como propietario de una empresa o parte interesada, no me gustaría contratar desarrolladores que piensen egoístamente en lugar de por el bien del proyecto.

Esto se reduce a la profesionalidad: a veces necesitamos dejar a un lado nuestros estilos personales e ir con lo que es más eficiente para la adopción masiva. Esto fomenta la colaboración y elimina las barreras extrañas que no deberían estar allí en primer lugar.

En cuanto a su convención real, CapitalCamelCase generalmente está reservado para los nombres de clase (o en Javascript, constructores). Si veo una variable en mayúscula, una suposición educada dictará que necesitaré crear una instancia para usarla. Si eso está mal, me enojará que el código no siga los estándares de la comunidad. Incluso con la mayoría de los otros idiomas, todos los demás que lo miran por primera vez se engañan al instante. Quiero que el código sea obvio, no engañoso.

Adrian Schneider
fuente
"Si veo una variable en mayúscula, una suposición educada dictará que necesitaré crear una instancia para usarla". No entiendo. ¿Cómo ver una variable en mayúscula te hace pensar que necesitas crear una instancia antes de usarla? ¿Porque parece un nombre de clase? ¿Entonces no sabes la diferencia entre MyClass MyClass = nully class MyClass { }?
oscilatingcretin
3
Sí, veo la diferencia. La convención existe para evitar la ambigüedad. var car = new Car();Según mi última línea, ¿por qué no hacerlo obvio?
Adrian Schneider
3
@oscilatingcretin Hay una diferencia, por supuesto. Pero el cerebro humano se beneficia de las señales visuales que un analizador informático no necesita. Parece que está cuestionando la necesidad de convenciones / estándares ... lo cual es una pregunta válida, si es diferente a la que originalmente preguntó.
Andres F.
2

"porque el caso apropiado completo debe reservarse para propiedades y métodos nulos. Las variables locales y los métodos que devuelven un valor deben tener la primera palabra en minúscula" y porque es una convención estándar.

Otros programadores están sacando su código en este momento y piensan que esta es una propiedad y es realmente una variable local, lo que dificulta su trabajo.

N4TKD
fuente
1
¿Leíste mi pregunta por completo? Eche un vistazo hacia el final donde dije:NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
oscilatingcretin
8
Sí y sí, es importante, el próximo programador nunca debería necesitar pensar en NuggetCount, debería poder mirar el nombre y decirlo. Un buen libro para leer es "Código limpio", debería poder leer el código como una historia y saber lo que está sucediendo.
N4TKD
2
@oscilatingcretin Creo que la frustración que está viendo con las personas que responden preguntas ligeramente diferentes de las que está preguntando es evidencia de la confusión que se puede generar cuando se rompen las convenciones aceptadas.
Mr.Mindor
77
Las convenciones tienen significado. Si según la convención NuggetCount implica una propiedad, significa que tiene un alcance más allá de lo que tendría una variable local. Lo que significa que tengo que investigar más para determinar ese alcance. Necesito determinar: ¿Hay efectos secundarios por cambiarlo? ¿Puedo confiar en que su valor no sea cambiado por otro hilo mientras lo estoy usando? nuggetCount implica un alcance local y debería ser capaz de asumir que toda su historia es local.
Mr.Mindor
55
@oscilatingcretin ¡SÍ! ¡Exactamente! Confié en que lo que escribieron siguió a la convención y llevó todo lo que conlleva. Confié en que estaban trabajando como parte del equipo y podría cosechar los beneficios de usar esa convención (sabiendo lo que nuggetCount era de un vistazo) Si no lo hicieron, probablemente haga lo que han hecho sus compañeros de trabajo: trato de educar al responsable , y pierdo más tiempo la próxima vez que tenga que seguirlos sin confiar. Al no seguir la convención, han producido un código menos legible y menos mantenible. ¿Tiene alguna razón para querer romper la convención?
Mr.Mindor
0

Como otros han dicho, no hay una razón real, excepto para obtener una convención de nomenclatura. Si puede lograr que todo su equipo esté en la misma página, probablemente pueda ahorrarse algo de tiempo. Por ejemplo, personalmente comencé una cosa de estándares de codificación que entró en esto y usamos camelCase para todas las variales privadas, así como las cosas pasadas por Val, mientras que usamos PascalCase para las cosas que son públicas y las que pasan Ref.

Las líneas se vuelven un poco borrosas cuando se trata de cosas como protegido o fuera o algo así.

John
fuente
-2

El lenguaje (con su aspecto formal y convencional) es importante para organizar sus pensamientos, tiene poder sobre sus formas de pensar. Por lo tanto, es simplemente un dolor pasar de un estilo a otro.

Los símbolos en minúsculas y mayúsculas tienen grandes diferencias semánticas en Haskell, también difieren ligeramente en Scala y he usado ambos. Otros idiomas que uso no hacen ninguna diferencia entre estos dos tipos de identificadores, pero mantener los pensamientos en la forma en que Haskell percibe los identificadores es mucho más fácil para mí que fragmentar mi mente para diferentes idiomas.

ayvango
fuente
-2

Para mí todo se reduce a la expectativa.

Cuando leo la mayoría del código, espero que todo lo que comienza con lowerCasea sea una variable local o una función (en C # eso sería solo una variable). Si veo una variable local en ProperCase, probablemente tropezaré y me confundiré por un tiempo, pensando que es un nombre de clase o una propiedad u otra cosa. Eso haría que volviera a leer el código y me molestaría.

Es probable que eso esté sucediendo en su caso.

Además, es conveniente saber qué papel juega una variable con solo mirar la primera letra, y evita conflictos entre un nombre de instancia y un nombre de clase.

ikh
fuente
-3

Se deben usar minúsculas para las variables locales para facilitar la escritura (tecla de velocidad / sin cambio). Las mayúsculas se utilizan para ayudar a la legibilidad al separar las palabras dentro de un nombre. Los códigos con nombres de variables locales de una sola palabra (que deberían ser comunes) son rápidos y fáciles de escribir. El uso de mayúsculas para cada nueva palabra en el nombre también es más rápido (y menos espacio) que el uso de guiones bajos que agregan otro carácter, esto también se conoce como camello.

phkahler
fuente
Creo que esta es una muy buena respuesta y no entiendo los votos negativos. Es una respuesta lógica, basada en hechos solicitados por el OP. Si vota en contra, explíquese. La tecla shift presionada por todo el lugar es masiva. Piénselo, casi cada palabra que escriba en su código iniciará PascalCase y para cada una necesitará presionar otra vez la tecla Mayús. Si quieres ser minimalista y efectivo, tiene sentido eliminar las pulsaciones innecesarias de las teclas shift. Y lógicamente hablando, querrías ser más productivo, lo que desde donde estoy parado significa presionar menos teclas. ¿Por qué presionar más?
AIon
-3

Estoy de acuerdo con el OP aquí. camelCase simplemente se ve mal. También estoy de acuerdo con el hecho de que ese es el estándar y debemos mantener el mismo estándar o cuál es el punto de tener un estándar. También tiene sentido que PascalCaps se use para métodos, etc. y camelCase para sus propias variables, etc., como una forma de diferenciarse cuando no se usa un IDE que colorea los métodos para usted.

Para evitarlo, siempre prefijo los nombres de mis objetos con el tipo de objeto que es. Entonces, si es una variable de cadena, llamo strMyVariable. Si se trata de algún tipo de objeto, lo llamo objMyObject, etc. De esa manera comienza con mayúsculas según el estándar y se ve bien.

Filipe
fuente
3
Esto no parece ofrecer nada sustancial sobre los puntos formulados y explicados en 11 respuestas anteriores
mosquito