language-agnostic - programming - cuda tutorial

Cómo nombrar variables

Question

• ¿Qué reglas usas para nombrar tus variables?
• ¿Dónde están permitidos los vars de letra simple?
• ¿Cuánta información pone en el nombre?
• ¿qué tal, por ejemplo, el código?
• ¿Cuáles son tus nombres de variable sin sentido preferidos? (después de foo & bar)
• ¿Por qué se deletrean "foo" y "bar" en lugar de FUBAR?

Answer 1

¿Qué reglas usas para nombrar tus variables?

• Necesito ser capaz de entenderlo dentro de un año. También debería ajustarse al estilo preexistente.

¿Dónde están permitidos los vars de letra simple?

• cosas ultra obvias Por ejemplo, char c; c = getc (); Indicaciones de bucle (i, j, k).

¿Cuánta información pone en el nombre?

• Mucho y mucho.

¿qué tal, por ejemplo, el código?

• Lo mismo que arriba.

¿Cuáles son tus nombres de variable sin sentido preferidos? (después de foo & bar)

• No me gusta tener nombres de variables sin sentido. Si una variable no significa nada, ¿por qué está en mi código?

¿Por qué se deletrean "foo" y "bar" en lugar de FUBAR?

• Tradicion.

Answer 2

Aprendí a no volver a utilizar nombres de variables de una sola letra en mis días de VB3. El problema es que si desea buscar en todas partes donde se usa una variable, ¡es difícil buscar en una sola letra!

Las versiones más nuevas de Visual Studio tienen funciones inteligentes de búsqueda de variables que evitan este problema, pero los viejos hábitos y todo eso. De todos modos, prefiero errar del lado del ridículo.

for (int firstStageRocketEngineIndex = 0; firstStageRocketEngineIndex < firstStageRocketEngines.Length; firstStageRocketEngineIndex++)
{
  firstStageRocketEngines[firstStageRocketEngineIndex].Ignite();
  Thread.Sleep(100);  // Don''t start them all at once. That would be bad.
}

Answer 3

Prácticamente todos los lenguajes modernos que tenían un amplio uso tienen sus propios estándares de codificación. Estos son un gran punto de partida. Si todo lo demás falla, simplemente use lo que sea recomendado. Hay excepciones, por supuesto, pero estas son pautas generales. Si tu equipo prefiere ciertas variaciones, siempre y cuando estés de acuerdo con ellas, también está bien.

Pero al final del día no es necesariamente qué estándares usas, sino el hecho de que los tienes en primer lugar y de que se cumplan.

Answer 4

Una regla que siempre sigo es la siguiente: si una variable codifica un valor que está en algunas unidades particulares, esas unidades deben ser parte del nombre de la variable. Ejemplo:

int postalCodeDistanceMiles;
decimal reactorCoreTemperatureKelvin;
decimal altitudeMsl;
int userExperienceWongBakerPainScale

NO seré responsable de bloquear ningún aterrizador de Marte (o la falla equivalente en mis aburridas aplicaciones comerciales CRUD).

Answer 5

lugareños: fooBar; miembros / tipos / funciones Interfaces de FooBar: IFooBar

En cuanto a mí, las letras individuales solo son válidas si el nombre es clásico; i / j / k solo para los índices del bucle local, x, y, z para las partes del vector.

Los vars tienen nombres que transmiten significado pero son lo suficientemente cortos como para no formar líneas

foo, bar, baz . Pickle también es un favorito.

Answer 6

Hago mucho php hoy en día, aunque no siempre fue así y he aprendido un par de trucos cuando se trata de nombres variables.

// esta es mi variable de cadena $ strVar = "";

// esto representaría una matriz $ arrCards = array ();

// esto es para un entero $ intTotal = NULL:

// object $ objDB = new database_class ();

// boolean $ blValid = true;

Answer 7

function startEditing(){
   if (user.canEdit(currentDocument)){
      editorControl.setEditMode(true);
      setButtonDown(btnStartEditing);
   }
 }

Debe leerse como un trabajo narrativo.

Answer 8

En las DSL y otras interfaces fluidas a menudo las variables y el nombre del método juntos forman una entidad léxica. Por ejemplo, personalmente me gusta el patrón de nombres (ciertamente hereje) donde el verbo se coloca en el nombre de la variable en lugar del nombre del método. @see 6ta Regla de Nombramiento Variable

Además, me gusta el uso espartano de $ como nombre de variable para la variable principal de un fragmento de código. Por ejemplo, una clase que imprime bastante una estructura de árbol puede usar $ para StringBuffer inst var. @see Esto es Verbose!

De lo contrario, me refiero al libro de frases del programador de Einar Hoest. @ver http://www.nr.no/~einarwh/phrasebook/

Answer 9

Estas son todas las convenciones de C #.

Carcasa de nombre variable

El caso indica alcance Las variables de Pascal-cased son campos de la clase propietaria. Las variables de Camel-cased son locales para el método actual.

Tengo solo una convención de prefijo-personaje. Los campos de respaldo de las propiedades de clase tienen el formato Pascal y el prefijo con un guión bajo:

private int _Foo;
public int Foo { get { return _Foo; } set { _Foo = value; } }

Hay una convención de nomenclatura de C # que he visto por ahí, estoy bastante seguro de que era un documento de Microsoft, que critica el uso de un prefijo de subrayado. Eso parece una locura para mí. Si miro en mi código y veo algo así como

_Foo = GetResult();

Lo primero que me pregunto es: "¿Tengo una buena razón para no utilizar un acceso directo a la propiedad para actualizar ese campo?" La respuesta suele ser "Sí, y será mejor que sepas qué es eso antes de comenzar a jugar con este código".

Nombres de variables de una sola letra (y cortas)

Aunque tiendo a estar de acuerdo con el dictum de que los nombres de las variables deberían ser significativos, en la práctica hay muchas circunstancias en las que hacer que sus nombres tengan sentido no agrega nada a la legibilidad o capacidad de mantenimiento del código.

Los iteradores de bucle y los índices de matriz son los lugares obvios para usar nombres de variable cortos y arbitrarios. Menos obvio, pero no menos apropiado en mi libro, son los usos diferentes, por ejemplo:

XmlWriterSettings xws = new XmlWriterSettings();
xws.Indent = true;
XmlWriter xw = XmlWriter.Create(outputStream, xws);

Eso es del código C # 2.0; si lo escribiera hoy, por supuesto, no necesitaría la variable nonce:

XmlWriter xw = XmlWriter.Create(
   outputStream, 
   new XmlWriterSettings() { Indent=true; });

Pero todavía hay muchos lugares en el código C # donde tengo que crear un objeto que simplemente va a pasar a otra parte y luego tirarlo.

Muchos desarrolladores usarían un nombre como xwsTemp en esas circunstancias. Encuentro que el sufijo Temp es redundante. El hecho de que haya nombrado la variable xws en su declaración (y solo la estoy usando dentro del alcance visual de esa declaración, eso es importante) me dice que es una variable temporal.

Otro lugar en el que usaré nombres cortos de variables es en un método que hace un uso intensivo de un solo objeto. Aquí hay una pieza de código de producción:

    internal void WriteXml(XmlWriter xw)
    {
        if (!Active)
        {
            return;
        }
        xw.WriteStartElement(Row.Table.TableName);

        xw.WriteAttributeString("ID", Row["ID"].ToString());
        xw.WriteAttributeString("RowState", Row.RowState.ToString());

        for (int i = 0; i < ColumnManagers.Length; i++)
        {
            ColumnManagers[i].Value = Row.ItemArray[i];
            xw.WriteElementString(ColumnManagers[i].ColumnName, ColumnManagers[i].ToXmlString());
        }
        ...

No hay manera en el mundo de que el código sea más fácil de leer (o más seguro modificar) si le doy a XmlWriter un nombre más largo.

Oh, ¿cómo sé que xw no es una variable temporal? Porque no puedo ver su declaración. Solo uso variables temporales dentro de 4 o 5 líneas de su declaración. Si voy a necesitar uno por más código que eso, le doy un nombre con sentido o refactorizo ​​el código utilizándolo en un método que - hey, qué coincidencia - toma la variable corta como argumento.

¿Cuánta información pone en el nombre?

Suficiente.

Eso resulta ser algo así como un arte negro. Hay mucha información que no tengo que poner en el nombre. Sé cuándo una variable es el campo de respaldo de un elemento de acceso a la propiedad, o temporal, o un argumento para el método actual, porque mis convenciones de nombres me lo dicen. Entonces mis nombres no.

He aquí por qué no es tan importante.

En la práctica, no necesito gastar mucha energía averiguando nombres de variables. Puse todo ese esfuerzo cognitivo en nombrar tipos, propiedades y métodos. Este es un trato mucho más grande que nombrar variables, porque estos nombres a menudo son de alcance público (o al menos visibles en todo el espacio de nombres). Los nombres dentro de un espacio de nombres deben transmitir el significado de la misma manera .

Solo hay una variable en este bloque de código:

        RowManager r = (RowManager)sender;

        // if the settings allow adding a new row, add one if the context row
        // is the last sibling, and it is now active.
        if (Settings.AllowAdds && r.IsLastSibling && r.Active)
        {
            r.ParentRowManager.AddNewChildRow(r.RecordTypeRow, false);
        }

Los nombres de propiedad casi hacen que el comentario sea redundante. (Casi. De hecho, hay una razón por la cual la propiedad se llama AllowAdds y no AllowAddingNewRows que se pensó mucho, pero no se aplica a esta pieza de código en particular, por lo que hay un comentario). ¿El nombre de la variable? ¿A quien le importa?

Answer 10

Las reglas a las que me adhiero son;

¿El nombre describe completa y exactamente lo que representa la variable?

¿El nombre se refiere al problema del mundo real más que a la solución del lenguaje de programación?

¿El nombre es lo suficientemente largo para que no tengas que descifrarlo?

¿Se calificaron los valores de calificación, si los hay, al final del nombre?

¿Están específicamente instanciados solo en el punto requerido una vez?

Answer 11

Me gusta prefijar mis variables con lo que van a ser: str = String, int = Integer, bool = Boolean, etc.

Usar una sola letra es rápido y fácil en Loops: para i = 0 a 4 ... Loop

Las variables están hechas para ser un sustituto corto pero descriptivo de lo que estás usando. Si la variable es demasiado corta, es posible que no comprenda para qué sirve. Si es demasiado largo, escribirás para siempre para una variable que represente 5.

Foo & Bar se utilizan, por ejemplo, como código para mostrar cómo funciona el código. En su lugar, puede usar casi cualquier carácter sin sentido diferente para usar. Usualmente solo uso i, x, y y.

Mi opinión personal sobre foo bar vs. fu bar es que es demasiado obvio y a nadie le gustan las variables de 2 caracteres, ¡3 es mucho mejor!

Answer 12

No tiene importancia cómo nombras las variables. Realmente no necesita ninguna regla, aparte de las especificadas por el idioma, o como mínimo, aquellas impuestas por su compilador.

Se considera cortés elegir nombres que creas que tus compañeros de equipo pueden descifrar, pero las reglas de estilo realmente no ayudan con eso tanto como la gente piensa.

Answer 13

Siempre utilizo variables de una sola letra en los bucles for, es más agradable y más fácil de leer.

Mucho depende del lenguaje en el que estás programando, no nombro las variables de la misma manera en C ++ que en Java (Java se presta mejor a los nombres de variables excesivamente largos, pero esto podría ser solo una preferencia personal . O puede tener algo que ver con la forma en que los complementos Java se nombran ...).

Answer 14

Yo diría que trato de nombrarlos lo más claramente posible. Nunca utilice variables de una sola letra y solo use ''foo'' y ''bar'' si solo está probando algo (por ejemplo, en modo interactivo) y no lo usará en producción.

Answer 15

¿Qué reglas usas para nombrar tus variables? Cambié entre guiones bajos entre las palabras (load_vars), camel case (loadVars) y sin espacios (loadvars). Las clases son siempre CamelCase, en mayúscula.

¿Dónde están permitidos los vars de letra simple? Bucles, en su mayoría. Vars temporales en código desechable.

¿Cuánta información pone en el nombre? Suficiente para recordarme qué es mientras estoy codificando. (Sí, esto puede conducir a problemas más adelante!)

¿Cuáles son tus nombres de variable sin sentido preferidos? (después de foo & bar) temp, res, r. De hecho, no uso foo y barra una buena cantidad.

Answer 16

¿Qué reglas usas para nombrar tus variables?

Normalmente, como soy desarrollador de C #, sigo las convenciones de nomenclatura variable especificadas por el estándar de codificación IDesign C # por dos razones

1) Me gusta, y me resulta fácil de leer. 2) Es el valor por defecto que viene con Code Style Enforcer AddIn para Visual Studio 2005/2008 que utilizo ampliamente estos días.

¿Dónde están permitidos los vars de letra simple?

Hay algunos lugares donde permitiré las variables de una sola letra. Por lo general, estos son simples indexadores de bucle, O conceptos matemáticos como las coordenadas X, Y, Z. Aparte de eso, nunca! (En cualquier otro lugar que los haya usado, generalmente he sido mordido por ellos al volver a leer el código).

¿Cuánta información pone en el nombre?

Suficiente para saber PRECISAMENTE para qué se usa la variable. Como dice Robert Martin:

El nombre de una variable, función o clase debe responder a todas las preguntas importantes. Debería decirle por qué existe, qué hace y cómo se usa. Si un nombre requiere un comentario, entonces el nombre no revela su intención. Desde Clean Code: un manual de software artesanal ágil

Answer 17

• Solo uso variables de un solo carácter para control de bucle o funciones muy cortas.

for(int i = 0; i< endPoint; i++) {...}

int max( int a, int b) {
    if (a > b)
       return a;
    return b;
}

• La cantidad de información depende del alcance de la variable, cuantos más lugares se pueda usar, más información quiero que tenga el nombre para hacer un seguimiento de su propósito.
• Cuando escribo código de ejemplo, trato de usar nombres de variables como lo haría en código real (aunque las funciones pueden tener nombres inútiles como foo o bar).
• Ver la etimología de "Foo"

Answer 18

Como trabajo como contratista, me muevo entre diferentes compañías y proyectos, prefiero evitar las convenciones de nombres personalizados. Hacen que sea más difícil para un desarrollador nuevo, o un desarrollador de mantenimiento, conocer (y seguir) el estándar que se utiliza.

Por lo tanto, aunque uno puede encontrar puntos en los que no está de acuerdo, consulto las pautas oficiales de Microsoft Net para obtener un conjunto coherente de convenciones de nombres.

Con algunas excepciones (notación húngara), creo que el uso constante puede ser más útil que cualquier conjunto arbitrario de reglas. Es decir, hazlo de la misma manera todo el tiempo.

.

Answer 19

¿Qué reglas usas para nombrar tus variables? camelCase para todas las variables importantes, CamelCase para todas las clases

¿Dónde están permitidos los vars de letra simple? En construcciones de bucle y en funktions matemáticos donde el nombre var de una sola letra es consistente con la definición matemática.

¿Cuánta información pone en el nombre? Deberías poder leer el código como un libro. Los nombres de las funciones deberían indicarle lo que hace la función (scalarProd (), addCustomer (), etc.)

¿Qué tal, por ejemplo, el código?

¿Cuáles son tus nombres de variable sin sentido preferidos? (después de foo & bar) temp, tmp, input, realmente nunca uso foo y bar.

Answer 20

Nunca uso nombres de variables sin sentido como foo o bar, a menos que, por supuesto, el código sea verdaderamente descartable.

Para las variables de bucle, doblo la letra para que sea más fácil buscar la variable dentro del archivo. Por ejemplo,

for (int ii=0; ii < array.length; ii++)
{
    int element = array[ii];
    printf("%d", element);
}

Answer 21

Bueno, todo depende del idioma en el que estés desarrollando. Como actualmente estoy usando C #, suelo utilizar lo siguiente.

camelCase para variables.

camelCase para los parámetros.

PascalCase para propiedades.

m_PascalCase para las variables miembro

¿Dónde están permitidos los vars de letra simple? Tiendo a hacer esto en bucles, pero me siento un poco culpable cada vez que lo hago. Pero con expresiones foreach y lambda para bucles no son realmente tan comunes ahora.

¿Cuánta información pone en el nombre? Si el código es un poco difícil de entender, escriba un comentario. No convierta un nombre de variable en un comentario, es decir. int theTotalAccountValueIsStoredHere no es obligatorio.

¿Cuáles son tus nombres de variable sin sentido preferidos? (después de foo & bar) i o x. foo y bar son un ejemplo de libro de texto universitario para mí.

¿Por qué se deletrean "foo" y "bar" en lugar de FUBAR? Tradicion

Answer 22

Actualizado

En primer lugar, nombrar depende de las convenciones existentes, ya sea del lenguaje, el marco, la biblioteca o el proyecto. (Cuando esté en Roma ...) Ejemplo: utilice el estilo jQuery para los complementos jQuery, use el estilo Apple para las aplicaciones iOS. El primer ejemplo requiere más vigilancia (ya que JavaScript puede desordenarse y no se verifica automáticamente), mientras que el último ejemplo es más simple ya que el estándar se ha aplicado y seguido correctamente. YMMV depende de los líderes, la comunidad y especialmente las herramientas.

Dejaré de lado todos mis hábitos de nombre para seguir cualquier convención existente.

En general, sigo estos principios, que se centran en que la programación es otra forma de comunicación interpersonal a través del lenguaje escrito .

• Legibilidad : las partes importantes deben tener nombres sólidos; pero estos nombres no deberían ser un reemplazo de la documentación adecuada de la intención . La prueba para la legibilidad del código es si puede volver a ella meses después y aún así ser lo suficientemente comprensivo como para no arrojar todo en la primera impresión. Esto significa evitar abreviatura; ver el caso contra la notación húngara .

• Capacidad de escritura : las áreas comunes y las repeticiones deben mantenerse simples (especialmente si no hay IDE), de modo que el código es más fácil y más divertido de escribir. Esto está un poco inspirado por el estilo de Rob Pyke .

• arrItems mantenimiento : si agrego el tipo a mi nombre como arrItems , entonces sería arrItems si cambiara esa propiedad para que sea una instancia de una clase CustomSet que extienda Array . Las notas de tipo deben mantenerse en la documentación, y solo si corresponde (para las API y demás).

• ProperCase estándar y comunes : para entornos tontos (editores de texto): las clases deben estar en ProperCase , las variables deben ser cortas y, si es necesario, deben estar en snake_case y las funciones deben estar en camelCase .

Para JavaScript, es un caso clásico de las restricciones del lenguaje y las herramientas que afectan a los nombres. Ayuda a distinguir las variables de las funciones a través de diferentes nombres, ya que no hay un IDE para sostener su mano, mientras que this y otro prototype y otra repetición oscurecen su visión y confunden sus habilidades de diferenciación. Tampoco es raro ver todos los vars sin importancia o derivadas globalmente en un alcance abreviado. El idioma no tiene import [path] as [alias]; , entonces los vars locales se convierten en alias. Y luego está el montón de diferentes convenciones de espacios en blanco. La única solución aquí (y en cualquier lugar, realmente) es la documentación adecuada de la intención (y la identidad).

Además, el lenguaje en sí se basa en el alcance y los cierres del nivel de función, por lo que la flexibilidad puede hacer que los bloques con variables en niveles de 2+ ámbitos se sientan muy desordenados, así que he visto nombrar dónde _ se antepone para cada nivel en la cadena de alcance a los vars en ese alcance.

Answer 23

1. Usa variables que describan claramente lo que contiene. Si la clase va a crecer, o si está en el ámbito público, el nombre de la variable debe describirse con mayor precisión. Por supuesto, un buen nombre hace que usted y otras personas entiendan mejor el código.
   • por ejemplo: use "employeeNumber" en lugar de solo "number".
   • use Btn o Button al final del nombre de las variables que se refieren a los botones.
2. Comience las variables con minúsculas, comience las clases con mayúsculas.
   • ejemplo de la clase "MyBigClass", ejemplo de la variable "myStringVariable"
3. Use mayúsculas para indicar una nueva palabra para una mejor legibilidad. No use "_", porque se ve más feo y tarda más tiempo en escribir.
   • por ejemplo: use "employeeName".
4. Solo use variables de un solo carácter en bucles.

Answer 24

Trabajo en MathCAD y estoy contento porque MathCAD me ofrece posibilidades de nombrar increíbles y los uso mucho. Y no puedo entender cómo programar sin esto. Para diferenciar una var de otra, tengo que incluir mucha información en el nombre, por ejemplo:

1.En primer lugar, eso es -N para cantidad, F para fuerza y ​​así sucesivamente

2. En el segundo - índices adicionales - para la dirección de la fuerza, por ejemplo

3.En el tercero - indexación dentro del vector o var matriz, para conveniencia pongo var nombre en corchetes {} o [] para mostrar sus dimensiones.

Entonces, como conclusión, mi var nombre es como N.dirs / Fx i.row / {F} .w. (I, jk) / {F} .w. (K, ij). A veces tengo que agregar el nombre del sistema de coordenadas para los valores vectoriales {F}. {GCS} .w. (I, jk) / {F}. {LCS} .w. (I, jk)

Y como paso final, agrego el nombre del módulo externo en negrita al final de la función externa o var como Row.MTX.f ([M]) porque MathCAD no tiene cadena de ayuda para la función.