¿Utiliza artículos en sus nombres de variables?

Question

Editar: Parece haber al menos dos razones válidas por las que los Smalltalkers hacen esto (legibilidad durante el encadenamiento de mensajes y problemas de alcance) pero tal vez la pregunta puede permanecer abierta por más tiempo para abordar el uso general.

Original: Por razones que he olvidado hace tiempo, nunca uso artículos en mis nombres de variables. Por ejemplo:

aperson, thecar, unObjeto

supongo que me siento como artículos sucios los nombres con información sin sentido. Cuando veía el código de un compañero de trabajo usando esta convención, mi presión arterial se aceleraba ligeramente.

Recientemente comencé a aprender Smalltalk, sobre todo porque quiero aprender el idioma que Martin Fowler, Kent Beck y tantos otros grandes crecieron y amaron.

me di cuenta, sin embargo, que Smalltalkers parecen utilizar ampliamente indefinidos artículos (una, una) en sus nombres de variables. Un buen ejemplo sería el siguiente método de selección:

name: aName address: anAddress. 
    self name: aName. 
    self address: anAddress 

Esto me ha hecho reconsiderar mi posición. Si una comunidad tan respetada e influyente como Smalltalkers ha adoptado ampliamente artículos en nomenclatura variable, tal vez haya una buena razón para ello.

¿Lo usa? ¿Por qué o por qué no?

Answer 1

Esta convención de nomenclatura es uno de los patrones del libro de Kent Beck Smalltalk Best Practice Patterns. En mi humilde opinión, este libro es imprescindible incluso para los que no son pequeños, ya que realmente ayuda a nombrar cosas y a escribir códigos de auto-documentación. Además, es probable que sea uno de los pocos logotipos de patrones para mostrar Alexander's quality without a name.

Otro buen libro sobre patrones de código es Smalltalk con estilo, que es available as a free PDF.

En general, la convención es que las variables de instancia y descriptores de acceso utilizan el sustantivo desnudo, y parámetros de uso del artículo indefinido más o bien un papel o de un tipo, o una combinación. Las variables temporales pueden usar sustantivos desnudos porque rara vez duplican la variable de instancia; alternativamente, es bastante frecuente nombrarlos con más precisión que un artículo indefinido, para indicar su rol en el flujo de control: eachFoo, nextFoo, randomChild ...

Answer 2

Siempre he sentido que los artículos ensuciaban los nombres con información sin sentido.

Exactamente. Y esta es toda la razón necesaria para eliminar artículos: desordenan innecesariamente el código y no brindan información adicional.

No conozco a Smalltalk y no puedo hablar sobre las razones de "sus" convenciones, pero en todos lados, lo anterior es válido. Hay podría ser una razón técnica simple detrás de la convención Smalltalk (como ALL_CAPS en Ruby, que es una constante no solo por convención sino por la semántica del lenguaje).

Answer 3

nunca utilizado, tal vez porque en mi idioma principal no hay artículos: P

De todos modos, creo que el tiempo que el nombre de la variable es significativa no es importante si hay artículos o no, depende de la década de codificador propia preferencia.

Answer 4

Es de uso común en Smalltalk como un lenguaje sin tipo porque indica tipo de un argumento en la llamada a método. El artículo en sí indica que está tratando con una instancia de algún objeto de la clase especificada.

Pero recuerda que en Smalltalk los métodos se ven de manera diferente, nos utilizar los llamados mensajes de palabras clave y es este caso los artículos en realidad ayudan a la legibilidad:

anAddressBook add: aPerson fromTownNamed: aString 

Answer 5

Nop.Siento que es un desperdicio de espacio en los personajes y erosiona la legibilidad de tu código. Podría usar variaciones del sustantivo, por ejemplo, Persona vs Gente, dependiendo del contexto. Por ejemplo

ArrayList People = new ArrayList(); 
Person newPerson = new Person(); 
People.add(newPerson); 

Answer 6

No, yo no. No creo que agregue nada a la legibilidad o el mantenimiento de mi base de códigos y no distingue la variable de ninguna manera.

El otro inconveniente es que si fomenta artículos con nombres de variables, es solo cuestión de tiempo antes de que alguien haga esto en su código base.

var person = new Person(); 
var aPerson = GetSomeOtherPerson(); 

Answer 7

Creo que acabo de encontrar una respuesta . Como dijo Konrad Rudolph, que utilizan esta convención debido a una razón técnica:

... esto significa que [variables método] no puede duplicar el nombre de una variable de instancia, una variable temporal definido en la interfaz, u otra variable temporal. - IBM Smalltalk Tutorial

Básicamente una variable método local no puede ser el mismo nombre que una variable de objeto/clase. Viniendo de Java, asumí las variables de un método podría estar en el ámbito local, y es posible acceder a las variables de instancia usando algo como:

self address 

todavía tengo que aprender más sobre el método/de alcance local en Smalltalk, pero parece que no tienen otra opción; ellos deben usar un nombre de variable diferente al de la instancia, por lo que anAddress es probablemente el enfoque más simple. Utilizando sólo dirección resultados en:

Name is already defined ->address 

si tiene una instancia de variable dirección ya definido ...

Answer 8

Donde trabajo, la norma es que delante de todos los campos de instancia con "THE-" , variables locales con "my-" y parámetros de método con "a-". Creo que esto ocurrió porque muchos desarrolladores usaban editores de texto como vi en lugar de IDE que pueden mostrar diferentes colores por alcance.

En Java, que tendría que decir que prefiero por encima de los emisores de escritura en la que eliminar la referencia de este .

Compare

public void setName(String name) { 
    this.name = name; 
} 

frente

public void setName(String aName) { 
    theName = aName; 
} 

Lo más importante es tener una norma y para todo el mundo a que se adhieran a la misma.

Answer 9

Me tambaleo hacia adelante y hacia atrás al usar esto. Creo que depende de la relación de C++ al objetivo C en mis proyectos en un momento dado. En cuanto a la base y el razonamiento, Smalltalk popularizó la noción de que los objetos son "cosas". Creo que fue Yourdon y Coad lo que impulsó fuertemente la descripción de las clases en primera persona. En Python sería algo así como el siguiente fragmento. Realmente me gustaría poder recordar suficiente SmallTalk para armar un ejemplo "apropiado".

class Rectangle: 
    """I am a rectangle. In other words, I am a polygon 
    of four sides and 90 degree vertices.""" 
    def __init__(self, aPoint, anotherPoint): 
     """Call me to create a new rectangle with the opposite 
     vertices defined by aPoint and anotherPoint.""" 
     self.myFirstCorner = aPoint 
     self.myOtherCorner = anotherPoint 

En general, es un enfoque conversacional para la legibilidad del programa. El uso de artículos con nombres de variables era solo una parte del idioma completo. También hubo una expresión idiomática en torno a la denominación de parámetros y selectores de mensajes IIRC. Algo como:

aRect <- [Rectangle createFromPoint: startPoint 
        toPoint: otherPoint] 

Era simplemente otra moda pasajera que aún aparece cada cierto tiempo. Últimamente he notado que los nombres de los miembros como myHostName están apareciendo en código C++ como una alternativa a m_hostName. Estoy cada vez más enamorada de este uso, que creo que recuerda un poco a las expresiones idiomáticas de SmallTalk.