¿Soy inmoral por usar un nombre de variable que difiere de su tipo solo por caso?

Por ejemplo, tome este fragmento de código:

var person = new Person();

o para ustedes Pythonistas:

person = Person()

Constantemente me dicen lo malo que es esto, pero aún no he visto un ejemplo de la inmoralidad de estas dos líneas de código. Para mí, la persona es una Persona y tratar de darle otro nombre es una pérdida de tiempo. Supongo que en los días previos al resaltado de sintaxis, esto habría sido un gran problema. Pero en estos días, es bastante fácil diferenciar el nombre de un tipo de un nombre de variable. Diablos, incluso es fácil ver la diferencia aquí en SO.

¿O hay algo que me estoy perdiendo? Si es así, sería útil si pudiera proporcionar un ejemplo de código que causa problemas.

¿Cuál es el razonamiento de quienes te dicen que esto es malo? Hago esto todo el tiempo. Es la forma más simple y expresiva de nombrar una sola variable de un tipo. Si necesita dos Personobjetos, puede prefijar personadjetivos significativos como

fastPerson
slowPerson

de lo contrario solo

person

esta bien conmigo.

Utilizo mucho este patrón en las firmas de métodos. Si no puedo proporcionar un nombre descriptivo alternativo, en mi humilde opinión, no hay nada de malo en esto.

Lo que está mal sería si tienes dos tipos Persona y persona, entonces eso está muy muy mal.

Lo uso todo el tiempo para referencias de objetos temporales. Lo evitaría como la plaga de tipos de datos primitivos.

Person person = new Person(); // okay

int Int = 42; // pure evil

Si alguien dice que eso es malo, pregúntele si es mejor:

var abc = new Person();

Si la Persona es una Persona general en el contexto, entonces "persona" es un nombre realmente bueno. Por supuesto, si la Persona tiene un rol específico en el código, entonces es mejor nombrarla usando el rol.

Supongo que me votarán negativamente por decirlo, pero ...

Habiendo pasado un siglo siendo testigo de asesinatos épicos y codicia, los programadores somos realmente bendecidos si lo más inmoral que podemos hacer es nombrar una variable.

No creo que sea necesariamente "malo", pero obviamente si puedes calificarlo para darle más contexto, como qué tipo de persona es (estás tratando con solo una de las muchas personas posibles), entonces alguien más lo elige puede entender mejor.

Jason: no estoy seguro de quién te ha dicho que esto es malo. Varios autores utilizan esto como una forma estándar de expresar una instancia (minúscula) de una clase (en mayúscula).

Utilizo esto con bastante frecuencia ya que encuentro que la variable en minúsculas en realidad me comunica no solo que se trata de una instancia, sino también el nombre de la clase.

A menos que alguien tenga un argumento sólido en contra, ciertamente continuaré haciendo esto.

La razón por la que se considera malo es que si necesita tener 2 Person's en el futuro, puede terminar con un código similar.

Persona persona = nueva Persona ();

Persona person2 = nueva Persona ();

Eso estaría al borde de "Malo". Sin embargo, en ese caso, debe refactorizar a su persona original para distinguir entre los dos.

Como en su ejemplo, el nombre de variable "persona" es un nombre perfectamente descriptivo para el objeto "Persona". Por lo tanto, no hay nada de malo en ello.

Digo nombre por lo que es: si la variable representa a una persona con 2 perros, llámala personWith2Dogs. Si la variable tiene un alcance corto (como una var de bucle), la persona está bien.

Lo uso mucho en mi código y no creo que tenga nada de malo. Dicho esto, (probablemente) no lo usaría en un método más largo que, digamos, una pantalla, y si hay varias instancias de la clase Person. Definitivamente no los nombre person1, person2, person3 ... en su lugar use algo más descriptivo, como person_to_del, person_to_ban, person_to_update, etc.

No es inmoral, pero una búsqueda global encontrará ambos Persony personsi no activa la distinción entre mayúsculas y minúsculas. Prefiero un prefijo para facilitar la búsqueda / reemplazo global, pero absolutamente NO húngaro o algo largo / complicado. Entonces, uso ...

Personpara la clase / tipo aPersonpara una variable local thePersonpara un parámetro de método myPersonpara una variable de instancia ourPersonpara una variable de clase

En raras ocasiones, podría usarlo pen un contexto local donde tengo MUCHAS referencias, pero eso generalmente solo se aplica a índices de bucle y similares.

Depende.

Si tiene un estilo de uso de mayúsculas estricto, por lo que las variables comienzan en minúsculas (y usan under_scores o camelCase para los saltos de palabras), y las clases comienzan con letras mayúsculas, entonces es obvio que person es una variable y Person es una clase, y cuando alguien entienda esto , no parecerán estar en espacios de nombres superpuestos. (Del mismo modo, la gente casi nunca se confunde entre el verbo o sustantivo "polaco" y el adjetivo "polaco").

Si no tiene ese estilo, entonces tiene dos nombres que pueden confundirse fácilmente y difieren solo en mayúsculas y minúsculas. Eso es malo.

¿Cuáles son los argumentos exactos que usa esa gente?

Si no le permiten usar person como nombre de variable, podría considerar agregar el prefijo 'a'.

aPerson = Person()

Creo que lo que estás haciendo está bien. Creo que, en general, es importante tener estándares de codificación acordados.

Por ejemplo, uso lowerCamelCase para instancias, variables y UpperCamelCase para clases, etc.

Los estándares de codificación deberían eliminar este problema.

Cuando miro programas de código abierto exitosos, a menudo tienen estándares de codificación

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

Acordar los estándares de codificación debería ser la última batalla que tengas al respecto.

De hecho, mire la entrada de wikipedia (de http://en.wikipedia.org/wiki/CamelCase )

Estilo de programación y codificación

A veces se recomienda utilizar mayúsculas internas para indicar los límites de las palabras según las pautas de estilo de codificación para escribir código fuente (por ejemplo, el lenguaje de programación Mesa y el lenguaje de programación Java). Las recomendaciones contenidas en algunas de estas pautas están respaldadas por herramientas de análisis estático que verifican el cumplimiento del código fuente.

Estas recomendaciones a menudo distinguen entre UpperCamelCase e lowerCamelCase, y suelen especificar qué variedad se debe utilizar para tipos específicos de entidades: variables, campos de registro, métodos, procedimientos, tipos, etc.

Un estilo de codificación de Java ampliamente utilizado dicta que UpperCamelCase se use para clases y lowerCamelCase se use para instancias y métodos. [19] Reconociendo este uso, algunos IDE, como Eclipse, implementan accesos directos basados ​​en CamelCase. Por ejemplo, en la función de asistencia de contenido de Eclipse, escribir solo las letras mayúsculas de una palabra de CamelCase sugerirá cualquier clase o nombre de método coincidente (por ejemplo, escribir "NPE" y activar la asistencia de contenido podría sugerir "NullPointerException").

La notación húngara original para programación especifica que una abreviatura en minúscula para el "tipo de uso" (no el tipo de datos) debe anteponer todos los nombres de las variables, con el resto del nombre en UpperCamelCase; como tal, es una forma de lowerCamelCase. CamelCase es la convención oficial para los nombres de archivos en Java y para la computadora personal Amiga.

Microsoft .NET recomienda lowerCamelCase para parámetros y campos no públicos y UpperCamelCase (también conocido como "Estilo Pascal") para otros tipos de identificadores. [20]

Python recomienda UpperCamelCase para los nombres de clases. [21]

El registro NIEM requiere que los elementos de datos XML utilicen UpperCamelCase y que los atributos XML utilicen lowerCamelCase.

No existe una convención única para la inclusión de abreviaturas en mayúsculas (principalmente acrónimos e iniciales) dentro de los nombres de CamelCase. Los enfoques incluyen dejar toda la abreviatura en mayúsculas (como en "useHTTPConnection") y dejar solo la primera letra en mayúsculas (como en "useHttpConnection").

El caso Camel no es de ninguna manera universal en informática. Los usuarios de varios lenguajes de programación modernos, en particular los de las familias Lisp y Forth, casi siempre usan guiones. Algunas de las razones que se dan a veces son que para hacerlo no es necesario cambiar en la mayoría de los teclados, que las palabras son más legibles cuando están separadas y que el caso camel simplemente puede no conservarse de manera confiable en los lenguajes que no distinguen entre mayúsculas y minúsculas (como Common Lisp, que, aunque técnicamente es un lenguaje que distingue entre mayúsculas y minúsculas, canonicaliza (dobla) los identificadores a mayúsculas de forma predeterminada).

Es posible argumentar con más fuerza que los nombres de métodos de ese tipo no solo son inofensivos, sino que también pueden ser un indicador de código de buena calidad.

• Un indicador de buena granularidad de código: si sus métodos son cortos, de un solo propósito y con nombres descriptivos, no necesita mucha información en los nombres de las variables. Si tiene métodos largos que hacen muchas cosas y necesita realizar un seguimiento de una gran cantidad de contexto y estado, entonces los nombres de las variables deben ser más descriptivos.

• Un indicador de que los cálculos de propósito general se reducen a métodos de propósito general: si realiza una manipulación intermedia de las estructuras de datos en un método comercial, por ejemplo, se debe deduplicar una matriz de usuarios, tendrá que tener variables en el alcance con nombres como users[]y deduplicatedUsers[]. Si mueve la deduplicación a un método de utilidad, puede llamar al método Utils.dedup(array)y puede llamar a la matriz deduplicada deduplicatedArrayo simplemente result.

• Los descompiladores de Java a menudo usan un esquema como ese para nombrar variables locales (las variables de instancia y clase normalmente están disponibles en el código de bytes, pero las variables locales no lo están), y los resultados son más legibles de lo que cabría esperar, de hecho, a menudo más legibles que el fuente original.

• Vea el principio de Larry Wall de "La ambigüedad local está bien" - http://www.wall.org/~larry/natural.html .

Yo diría que probablemente tengas en mente algún uso específico cada vez que crees un objeto. El tipo por sí solo rara vez refleja ese uso.

Entonces, si desea crear un nuevo contacto en su aplicación de libreta de direcciones, es posible que desee llamar a la variable newContact.

Y si está probando unitariamente su código para verificar el comportamiento de Personobjetos sin nombres establecidos, es posible que desee llamarlos unnamedPersono algo similar.

Llamarlo simplemente personrenuncia a una gran oportunidad de hacer que su código se auto-documente.

Solo si está programando en VB6. En ese caso , lo que estás haciendo es ilegal, pero no inmoral.

Yo también lo hago, y tampoco entiendo por qué debería ser 'inmoral'. Aunque puedo entender que 'podría' a veces ser confuso, pero hoy tenemos IDE con intellisense y resaltado de sintaxis que se asegurará de que (si comete un error y hace referencia a su variable en lugar de su clase, y viceversa) vea su error bastante rápido. Y también tenemos el compilador. :)

Tampoco veo ningún problema con esta práctica. Siempre que haya solo una variable de esa clase, es fácil de escribir y de leer. Imo, eso incluso se aplica en un editor de texto básico. Personalmente, no recuerdo que nadie lo haya llamado malo o incluso inmoral. Solo continúa haciendo esto :)

Creo que la 'regla' en la que puede estar pensando está destinada más a tipos primitivos y clases donde el nombre de la clase hace un nombre de variable pobre.

Por ejemplo, si estuviera tratando de calcular el costo de un artículo en particular en una tienda en línea, el siguiente código no sería una buena forma:

Decimal _decimal = item.BaseCost + item.Tax;

En su lugar, se recomendaría un nombre más descriptivo, como '_total' o '_cost'.

El único problema con este tipo de cosas que he encontrado es si desea el mismo nombre para un miembro privado y también una propiedad pública.

Si estos difieren solo en el caso, funcionará bien en lenguajes que distinguen entre mayúsculas y minúsculas, como C #, pero no en VB.NET.

Entonces, por ejemplo, en VB, escribiría

Private _name As String

pero

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

Haría lo mismo en C #, para que la traducción de uno a otro sea indolora. También lo hace un poco menos propenso a errores, ya que es muy fácil leer mal, o incluso escribir mal, palabras que difieren solo en mayúsculas y minúsculas.

No es inmoral, pero si su mejor nombre para su variable es el nombre del tipo, algo anda mal o simplemente está haciendo una prueba de concepto o algo así. Para mí, un nombre de variable debe hacer referencia al significado en el contexto empresarial y no al lenguaje de programación. Será más difícil entender el código.

A menudo Person person = new Person()me uso . De uso común en Java / C #.

Aunque acabé preguntándome ayer por qué

private enum DataType {NEW, OLD}

no funciona en C # ...

Especialmente ver cómo se puede utilizar String, string, Double, double, ... a voluntad en C #.

Person person = new Person()

está bien en mi libro.

Cuando se vuelve horrible es cuando tienes:

string Person;
string person;

Es muy fácil mezclar los 2.

Lo que se me ha expresado, además de no cumplir con nuestros estándares de codificación, es evitar agregar confusión cuando alguien más está leyendo mi código. Personalmente, no veo ningún problema en ello, siempre que el significado sea claro.

En cuanto a los tipos CLR (int, string, etc.), puede usar String o string (etc.) para declarar el tipo, por lo que evitaría usar algo como

int Int = 0;
string String = "hi there";

Hacer de las mayúsculas la única diferencia es peligroso ... sigue haciendo esto para un gran proyecto y te garantizo que te encontrarás con errores extraños que parece que no puedes localizar.

fastPerson / slowPerson como arriba están bien ... son descriptivos y diferenciados del nombre del tipo de variable ... pero vamos hombre, llamar a un int "Int" sería simplemente perezoso.

Yo diría que nunca es inmoral, en realidad es solo el nombre de la variable de línea base. Si no puede pensar en un nombre mejor, nombrarlo después de su tipo es un buen valor predeterminado ( solo para tipos complejos , para tipos integrados es malo ) Y muchas veces no hay un nombre mejor porque no No sé nada más sobre la variable. Como con este método

void SaveToDatabase(Person person) {...}

Casi lo único más a lo que razonablemente podría llamar persona es person_to_saveo algo así que parece redundante.

Sin embargo, en muchos casos, puede mejorar la legibilidad de su código reemplazando persona con un nombre más descriptivo. Por ejemplo, esto es menos descriptivo

void AddToAccount(Account account, Person person)  {...}

que esto

void AddToAccount(Account account, Person dependent)  {...}

Sin embargo, por favor, por favor, no pongas una "a" o "t" delante del nombre del tipo. Es decir, aPerson para 'una persona' o tPerson para 'la persona'. Es demasiado complicado y no aporta mucho valor. Además, comienza a contaminar su alcance con un montón de variables que comienzan con aot que pueden minimizar el valor de intelli-sense.

No diría que es horrible. Por lo general, prefijo el nombre de la variable con 'a' en este tipo de cosas para mostrar que es una instancia única del tipo, por lo que haría

Person aPerson = new Person();

Hace que el código se lea de forma más natural, creo.

Absolutamente no tiene nada de malo, sujeto a las advertencias señaladas por otros (resumiendo aquí por conveniencia): no hacerlo con tipos primitivos, refactorizar la instancia original si se agrega otra instancia más tarde, no usar char-case para diferenciar nombres de clases, etc.

¿Mi regla de oro? Las declaraciones en código deben leerse como oraciones simples en inglés.

Persona persona = nueva Persona ();

Empleado empleado = person.getRole (EMPLOYEE);

Padre padre = person.getRole (PADRE);

person.getFullName ();

employee.getSalary ();

parent.getChildren ();

parent.getFullName (); // asumiendo el patrón del decorador en juego

if (person.hasRole (EMPLOYEE)) {

  ...

}

Etcétera.

Si el alcance de la variable es limitado (el método de encapsulación es de 10 a 15 líneas, por ejemplo), incluso podría usar 'p' en lugar de 'persona'. Los nombres de variables más cortos son una distracción menor cuando se trata de mantener el contexto en su cabeza. Evite los prefijos gratuitos como 'a' o (escalofrío) la notación húngara y sus derivaciones. (Eso sí, no tengo nada en contra de tales prefijos cuando se usan en el contexto apropiado: código API C ++ / COM / ATL / Win32, etc., donde ayuda a mantener las asignaciones / encasillamiento correctas).

Mis dos (!) Bits :-)