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

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);
    }
}

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.

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.