language agnostic - ¿Soy inmoral por usar un nombre de variable que difiera de su tipo solo por caso?
language-agnostic coding-style (30)
¿Cuál es el razonamiento de quienes te dicen que esto es malo? Hago esto todo el tiempo. Es la manera más simple y expresiva de nombrar una sola variable de un tipo. Si necesitaras dos objetos Person entonces podrías ponerle a la person prefijo con adjetivos significativos como
fastPerson
slowPerson
de lo contrario solo
person
esta bien conmigo.
Por ejemplo, toma este pedazo de código:
var person = new Person();
o para ti Pythonistas:
person = Person()
Me dicen constantemente cuán malo 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 decir un nombre de tipo aparte de un nombre de variable. Diablos, es incluso fácil ver la diferencia aquí en SO.
¿O hay algo que me falta? Si es así, sería útil si pudiera proporcionar un ejemplo de código que causa problemas.
¿Cuáles son los argumentos exactos que usan esas personas?
Si no le permiten usar una persona como nombre de variable, puede agregar el prefijo ''a''.
aPerson = Person()
A menudo uso Person person = new Person() yo mismo. Comúnmente utilizado en Java / C #.
Aunque terminé preguntándome ayer por qué
private enum DataType {NEW, OLD}
no funciona en C # ...
Especialmente viendo cómo puedes usar String , string , Double , double , ... a voluntad en C #.
Absolutamente nada de malo en él sujeto a 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 el código deben leerse como simples oraciones en inglés.
Persona persona = nueva persona ();
Empleado empleado = person.getRole (EMPLOYEE);
Padre principal = person.getRole (PARENT);
person.getFullName ();
employee.getSalary ();
parent.getChildren ();
parent.getFullName (); // asumiendo el patrón decorador en juego
if (person.hasRole (EMPLOYEE)) {
...
}
Etcétera.
Si el alcance de la variable es limitado (el método de encapsulado es de 10-15 líneas, por ejemplo), incluso podría usar ''p'' en lugar de ''persona''. Los nombres de variable más cortos son menos una distracción cuando se trata de mantener el contexto en su cabeza. Evite los prefijos gratuitos como la notación húngara ''a'' o (temblor) y sus derivados. (Tenga en cuenta que no tengo nada en contra de tales prefijos cuando se utiliza en el contexto apropiado - C ++ / COM / ATL / Win32 código API, etc., donde ayuda a mantener las asignaciones / encasillamiento directo).
Mis dos (!) Bits :-)
Creo que la ''regla'' en la que puede estar pensando está destinada más a los tipos primitivos, y las clases donde el nombre de la clase tiene un nombre de variable pobre.
Por ejemplo, si se tratara de calcular el costo de un artículo en particular en una tienda en línea, el siguiente código no sería bueno:
Decimal _decimal = item.BaseCost + item.Tax;
En su lugar, se recomienda un nombre más descriptivo, como ''_total'' o ''_cost''.
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 veo 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 tenga sobre esto.
De hecho, mira la entrada de wikipedia (de http://en.wikipedia.org/wiki/CamelCase )
Programación y estilo de codificación
Algunas 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 el código fuente (p. Ej., El lenguaje de programación Mesa y el lenguaje de programación Java). Las recomendaciones contenidas en algunas de estas directrices 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 y lowerCamelCase, por lo general especificando qué variedad se debe usar para tipos específicos de entidades: variables, campos de registro, métodos, procedimientos, tipos, etc.
Un estilo de codificación Java ampliamente utilizado dicta que UpperCamelCase se use para clases, y lowerCamelCase se use para instancias y métodos. [19] Reconociendo este uso, algunos IDEs, como Eclipse, implementan atajos basados en CamelCase. Por ejemplo, en la función Ayuda de contenido de Eclipse, escribir solo las letras mayúsculas de una palabra de CamelCase sugerirá cualquier clase coincidente o nombre de método (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 tipo de datos) debe incluir todos los nombres de variables, con el resto del nombre en UpperCamelCase; como tal, es una forma de lowerCamelCase. CamelCase es la convención oficial para nombres de archivo 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 "Pascal Style") para otros tipos de identificadores. [20]
Python recomienda UpperCamelCase para nombres de clase. [21]
El registro NIEM requiere que los Elementos de Datos XML usen UpperCamelCase y los Atributos XML usen 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 la abreviatura completa en mayúscula (como en "useHTTPConnection") y dejar solo la primera letra en mayúscula (como en "useHttpConnection").
El caso Camel no es de ninguna manera universal en informática. Los usuarios de varios lenguajes de programación modernos, especialmente los de las familias Lisp y Forth, casi siempre usan guiones. Entre los motivos que a veces se dan es que no es necesario desplazarse en la mayoría de los teclados, las palabras son más legibles cuando están separadas, y ese caso de camello simplemente no se puede preservar de manera confiable en idiomas que no distinguen entre mayúsculas y minúsculas (como Common Lisp, que, aunque técnicamente es un lenguaje sensible a mayúsculas y minúsculas, canonicaliza (plega) identificadores a mayúsculas de forma predeterminada).
Depende.
Si tiene un estilo de mayúscula estricto, las variables comienzan en minúsculas (y usa under_scores o camelCase para palabras), y las clases comienzan con mayúsculas, entonces es obvio que la persona es una variable y Person es una clase, y cuando alguien entiende esto , no parecen 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, tiene dos nombres que pueden confundirse fácilmente y diferir solo por el caso. Eso es malo.
Digo el nombre de lo que es: si la variable representa a una persona con 2 perros, llámalo personWith2Dogs . Si la variable tiene un alcance corto (como un bucle var), entonces la persona está bien.
Diría que probablemente tengas algún uso específico en mente cada vez que crees un objeto. El tipo solo muy rara vez refleja ese uso.
Por lo tanto, si desea crear un nuevo contacto en la aplicación de la libreta de direcciones, puede llamar a la variable newContact .
Y si está probando unitariamente su código para verificar el comportamiento de los objetos Person sin ningún nombre establecido, es posible que desee llamarlos unnamedPerson sin unnamedPerson o algo similar.
Llamarlo simplemente person renuncia a una gran oportunidad de hacer que su código se auto-documente.
El único problema con este tipo de cosas que he encontrado es si desea el mismo nombre para un miembro privado y también para una propiedad pública.
Si estos difieren solo en el caso, funcionará bien en lenguajes que distingan 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 #, de modo 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 de leer mal, o de hecho, escribir incorrectamente palabras que difieren solo por caso.
Es posible hacer un argumento más fuerte de que los nombres de métodos de ese tipo no solo son inofensivos, sino que 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 propósito único y descriptivos, no necesita mucha información en nombres de variables. Si tiene métodos largos que hacen muchas cosas y necesitan realizar un seguimiento de una gran cantidad de contexto y estado, entonces sus nombres de variables deben ser más descriptivos.
Un indicador de cálculos de propósito general que se reducen a métodos de propósito general: si realiza una manipulación intermedia de estructuras de datos en un método empresarial, por ejemplo, se debe deduplicar una matriz de usuarios, deberá tener variables en el alcance con nombres como
users[]ydeduplicatedUsers[]. Si mueve la deduplicación a un método de utilidad, puede llamar al métodoUtils.dedup(array)y puede llamar a la matrizdeduplicatedArrayo solo a suresult.Los descompiladores de Java a menudo usan un esquema como este para nombrar variables locales (las variables de instancia y clase normalmente están disponibles en el bytecode, pero las variables locales no) y los resultados son más legibles de lo que cabría esperar, de hecho a menudo más legibles que fuente original.
Ver el principio de Larry Wall de "La ambigüedad local está bien" - http://www.wall.org/~larry/natural.html .
Hacer que la capitalización sea la única diferencia es peligroso ... siga haciendo esto para un gran proyecto y le garantizo que se encontrará con errores extraños que parece que no puede encontrar.
fastPerson / slowPerson como el anterior están bien ... son descriptivos y diferenciados del nombre del tipo de variable ... pero vamos hombre, llamar a un int "Int" sería simple vago.
Jason - No estoy seguro de quién te haya 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 porque me parece que la variable de cassette inferior realmente me comunica no solo que esta es 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 si necesita tener 2 Person''s en el futuro, luego puede terminar con un código similar.
Persona persona = nueva persona ();
Persona person2 = new Person ();
Eso estaría bordeando "Malo". Sin embargo, en ese caso, debes refactorizar a tu persona original para poder distinguir entre los dos.
En cuanto a su ejemplo, el nombre de la variable "persona" es un nombre perfectamente descriptivo para el objeto "Persona". Por lo tanto, no hay nada de malo en ello.
Lo hago también, y tampoco entiendo por qué debería ser ''inmoral''. Aunque puedo entender que a veces puede ser confuso, pero hoy tenemos IDE con intellisense y resaltado de sintaxis que asegurarán que (si comete un error y hace referencia a su variable en lugar de a su clase, y viceversa) lo hará mira tu error bastante rápido Y también tenemos el compilador. :)
Lo que se me ha expresado, aparte de no cumplir con nuestros estándares de codificación, es evitar agregar confusión cuando alguien más está leyendo mi código. Yo, personalmente, no veo ningún problema con eso, siempre que el significado sea claro.
En cuanto a los tipos de 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";
Lo uso mucho en mi código, y no creo que haya nada de malo en él. Dicho esto, yo (probablemente) no lo usaría en un método más largo que, por ejemplo, una pantalla, y si hay varias instancias de 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.
Lo uso todo el tiempo para referencias de objetos temporales. Lo evitaría como la peste de los tipos de datos primitivos.
Person person = new Person(); // okay
int Int = 42; // pure evil
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 una sola persona presumiblemente con muchas personas posibles), entonces alguien más lo elige hasta puede entender mejor.
No diría que es horrible. Usualmente prefijo el nombre de la variable con ''a'' en este tipo de cosas para mostrar que es una instancia única del tipo, así que lo haría
Person aPerson = new Person();
Hace que el código se lea más naturalmente, creo.
No es inmoral, pero si su mejor nombre para su variable es el nombre del tipo, algo está 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 comercial y no al lenguaje de programación. Será más difícil de entender el código.
No es inmoral, pero una búsqueda global encontrará Person y person si no se activa la sensibilidad de 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 ...
Person para la clase / tipo aPerson para una variable local thePerson para un parámetro de método myPerson para una variable de instancia ourPerson para una variable de clase
En raras ocasiones, podría usar p en un contexto local donde tengo MUCHAS referencias, pero eso solo se aplica a los índices de bucle y similares.
Si alguien dice que eso es malo, pregúntale si esto es mejor:
var abc = new Person();
Si la Persona es una Persona general en el contexto, entonces "persona" es realmente un buen nombre. Por supuesto, si la Persona tiene un rol específico en el código, entonces es mejor nombrarla usando el rol.
Solo si estás programando en VB6. En ese caso , lo que estás haciendo es ilegal, pero no inmoral.
Supongo que me votarán por eso, pero ...
Después de haber pasado un siglo presenciando el asesinato épico y la codicia, los programadores somos verdaderamente bendecidos si lo más inmoral que podemos hacer es nombrar una variable.
Tampoco veo ningún problema con esta práctica. Mientras haya una sola variable de esa clase, es fácil escribir y leer fácilmente. Imo, que incluso se aplica en un editor de texto básico. Personalmente no puedo recordar a nadie que lo llame así o incluso inmoral. Solo continúa haciendo esto :)
Uso mucho este patrón en las firmas de métodos. Si no puedo proporcionar un nombre descriptivo alternativo, entonces en mi humilde opinión, no hay nada de malo en esto.
Lo que está mal sería si tienes dos tipos de persona y persona, entonces eso está muy muy mal.
Yo diría que nunca es inmoral, realmente es solo el nombre de la variable de la línea base. Si no puede pensar en un nombre mejor, nombrándolo después de su tipo es un buen valor predeterminado. (Para tipos complejos solamente - para los tipos integrados es malo ) Y mucho tiempo realmente no hay un nombre mejor porque no lo hace Saber algo más sobre la variable. Como con este método
void SaveToDatabase(Person person) {...}
Acerca de la única cosa que razonablemente podría llamar persona es person_to_save o algo así que parece redundante.
Sin embargo, en muchos casos puede mejorar la legibilidad de su código reemplazando a la 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 coloque una ''a'' o una ''t'' delante del nombre del tipo. IE aPerson para ''una persona'' o tPerson para ''la persona''. Es demasiado complicado y no agrega mucho, si algún valor. Además, comienzas a contaminar tu alcance con un conjunto de variables que comienzan con a o t y que pueden minimizar el valor de intelli-sense.
Person person = new Person()
está bien en mi libro.
Cuando se vuelve horrible es cuando tienes:
string Person;
string person;
Muy fácil de mezclar el 2.