c++ - textos - tipos de subrayado pdf

¿Es beneficioso usar el sufijo de subrayado para los miembros?

Question

class C {
 private:
  int member_; // here is the underscore I refer to.
}

Este guión bajo es recomendado por la Guía de estilo de Google y la Guía de estilo C ++ de Geosoft .

Entiendo que hay diferentes opiniones y gustos.

Quiero preguntar a las personas que lo usaron o se vieron obligados a usarlo si lo encontraron beneficioso, neutral o perjudicial para ellos. ¿Y por qué?

Aquí está mi respuesta:

Entiendo que pido motivación detrás de eso, pero no me convence. Lo intenté y todo lo que obtuve fue un poco de desorden en toda la clase, pero una inicialización más simple de los miembros en el constructor. No he encontrado una situación en la que el guión bajo ayude a diferir entre la variable miembro privada y otra variable (excepto en la inicialización mencionada).

En ese sentido considero que este estilo es perjudicial.

Answer 1

Bueno, ya que nadie lo mencionó: agregar un guión bajo a la variable miembro le permite nombrar a su captador y definidor con el nombre ''conceptual'' de la variable.

ex:

class MyClass
{
   int someMember_;

public:
   int someMember() const { return someMember_; }
   void someMember( int newValue ) { someMember_ = newValue; }
};

Aunque no uso este estilo.

Answer 2

Creo que es importante distinguir entre variables de clase y variables locales (y globales si es realmente necesario). Cómo lo hagas, no es importante, solo sé consistente.

class Foo
{
  int mMember;
  int member_;
  int _member;
  int m_Member;
};

Todos los estilos te dan la información que necesitas. Mientras te mantengas con el mismo estilo todo el tiempo, no hay problema. A veces otras personas necesitan trabajar con su código (por ejemplo, cuando crea una biblioteca o trabaja con una comunidad). Entonces podría ser una buena idea seguir con el estilo más utilizado en la comunidad de C ++.

Lo siento, no puedo responder qué estilo es.

Answer 3

Este es básicamente un argumento religioso, por lo que nunca vas a llegar a un consenso sobre este estilo. FWIW, utilizo este estilo para mis variables de miembro por razones que ya han indicado otros, por ejemplo:

class Foo
{
public:
  Foo(std::string name, int age) :
    name_(name),
    age_(age)
  {
  }

  std::string name() const { return name_; }
  void name(const std::string& name) { name_ = name; }

  int age() const { return age_; }
  void age(int age) { age_ = age; }
private:
  std::string name_;
  int age_;
};

Simplemente adopta algo con lo que estés contento y apégate a él.

Answer 4

Esto surgió en la discusión que tuvimos donde trabajo pero con la programación de Java. Pero creo que esto también se aplica a C ++. Mi respuesta es que los IDE tienen una función útil de colorear variables de miembros de clase. En Eclipse se vuelven azules. El guión bajo es superfluo. Como dice otro cartel, "EW, verrugas húngaras !!". 1980 llamó y quiere que le devuelvan la notación húngara.

Answer 5

Estoy de acuerdo con Tobias en que hay un beneficio para alguna convención, cualquiera que sea, para resaltar las variables de clase. Por otro lado, invariablemente encuentro que tales convenciones hacen que el código "fluya" menos bien. Simplemente es más fácil leer "totalPrice = productPrice + salesTax" que "m_totalPrice = l_productPrice + l_salesTax" o lo que sea.

Al final, prefiero dejar todos los nombres de campo sin decorar, y tener pocas variables de clase suficientes para mantenerlos al tanto no es un problema. En constructores y definidores, coloco un prefijo o sufijo en el parámetro, o en Java, por lo general, distingo la variable de clase con "esto", como:

public Foo(int bar)
{
  this.bar=bar;
}

(¿Puedes hacer eso en C ++? Ha pasado tanto tiempo que no lo recuerdo).

Answer 6

Estoy de acuerdo con usted en que el sufijo de la variable de subrayado no es el estilo de codificación ideal, y que agregar un poco de complejidad al constructor es mejor que agregar más complejidad a toda la clase.

El otro día, eché un vistazo a uno de mis antiguos proyectos Java en los que había aplicado el sufijo de subrayado a los nombres de variables, y descubrí que hacía más difícil la lectura del código. No fue demasiado difícil acostumbrarme, pero me pareció que me distraía un poco sin agregar ningún beneficio real.

Answer 7

Hay un "estilo" más que sugiere declarar miembros de la clase como se muestra a continuación:

class Foo{
    int m_value;
public:
     //...
};

Lo encontré utilizable. Pero es solo mi punto de vista.

Answer 8

Para mí, el beneficio de este estilo de decoración de variables miembro es que funciona bien con la funcionalidad de autocompletado de los editores de texto. Tener una decoración de prefijo requiere que escriba más caracteres antes de poder hacer una conjetura sólida sobre lo que quiere decir.

Answer 9

Se me ocurrió este estilo de forma independiente al principio de mis días de codificación en C ++ (finales de los 80 y principios de los 90) porque encontré varias situaciones confusas en las que tenía que volver al encabezado de la clase para averiguar qué variable era realmente una variable miembro.

Una vez que comencé a ver el código C ++ de otras personas que hizo lo mismo, me sentí bastante satisfecho de haber notado un problema que otras personas tenían y que la solución que adopté para mí era algo en lo que otras personas también pensaron.

No suele ser útil, pero es bastante inocuo y cuando es útil, es muy útil.

Esta es también la razón por la que realmente odio el estilo m_. No es inocuo, y creo que la fealdad añadida no vale la pena.

Utilizo un prefijo S_ para variables estáticas de alcance de archivo y variables estáticas de clase que no son constantes. Son una especie de variables globales, y creo que su uso debería ser señalizado en voz alta.

Answer 10

Seguimos el estándar de codificación C ++ de posibilidad.com , que dice prefijar las variables miembro con una ''m'', pero también he trabajado en la guía de estilo de Google.

Como usted dice, no es estrictamente necesario, especialmente si tiene un IDE que asigna diferentes resaltados de sintaxis a las variables miembro. Sin embargo, creo que vale la pena algún tipo de esquema de nomenclatura coherente, para permitirle saber de un vistazo si una variable es una variable miembro o no,

• Un nombre simplificado de parámetros , como en la respuesta de sbi, es una ventaja.
• Un estilo de codificación consistente es importante, independientemente del estilo que elija. Idealmente, todos los miembros del equipo usarían el mismo estilo de codificación, de modo que no se puede saber de un vistazo quién escribió una determinada sección de código. Esto ayuda a la hora de incorporar nuevos desarrolladores al equipo y con prácticas ágiles, como la falta de propiedad del código, y es aún más importante con proyectos de código abierto que pueden atraer una variedad de contribuciones.
• Lo más importante es que la legibilidad puede beneficiarse enormemente de que todo el código siga un estilo bastante estricto que aclare los tipos de identificadores como este. La diferencia entre poder decir de un vistazo que una variable es un miembro y saber decir las declaraciones de las variables locales puede ser pequeña, pero seguir un buen estándar de codificación generará numerosas pequeñas diferencias como esta en todo el cuerpo del código. , y puede hacer una gran diferencia en lo fácil que es seguir el código y lo fácil que es comenzar en una sección desconocida de código.

(Usted mencionó que probó este estilo, pero si fue solo para una parte del código y solo para el código con el que ya estaba familiarizado, entonces es más difícil ver el beneficio de legibilidad que seguir un estilo de codificación como este para toda la codebase puede traer.)

Todo esto está en mi experiencia, su kilometraje puede variar, etc.

Answer 11

Si necesita este guión bajo para poder indicar a los miembros de la clase de otras variables, es probable que tenga funciones de miembro demasiado grandes para ver instantáneamente qué es una variable / parámetro.

Todavía me gusta porque a menudo simplifica la denominación de parámetros de función miembro:

class person
{
public:
  person(const std::string& first_name, const std::string& last_name)
    : first_name_(first_name), last_name_(last_name) {}

  // .......

private:
  std::string first_name_;
  std::string last_name_;
};

Answer 12

Siempre quiero distinguir los miembros de la clase de las variables. Utilizo el _ como prefijo para los miembros y, personalmente, esto mantiene el código limpio y legible. Los prefijos funcionan bien con la inteligencia del editor. Prefijar con m_ o s_ es útil pero me parece feo.

Answer 13

Uso "m_" como prefijo para las variables miembro normales y "s_" para las variables miembro estáticas. Así que el alcance es directamente visible.