Uso de guiones bajos en variables Java y nombres de métodos [cerrado]

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Reglas:

1. Haz lo que hace el código que estás editando
2. Si no se aplica #1, use camelCase, sin guiones bajos

No creo que usar _ o m_ para indicar variables miembro sea malo en Java o cualquier otro lenguaje. En mi opinión, mejora la legibilidad de su código porque le permite mirar un fragmento e identificar rápidamente todas las variables de los miembros de los locales.

También puede lograr esto forzando a los usuarios a anteponer las variables de instancia con "esto", pero esto me parece ligeramente draconiano. En muchos sentidos viola DRY porque es una variable de instancia, por qué calificarlo dos veces.

Mi el propio estilo personal es usar m_ en lugar de _. La razón es que también hay variables globales y estáticas. La ventaja de m_/ _ es que distingue un ámbito de variables. Así que no puedes reutilizar _ para global o estático y en su lugar elijo g_ y s_ respectivamente.

"Mal estilo" es muy subjetivo. Si ciertas convenciones funcionan para usted y su equipo, creo que calificará un estilo malo/bueno.

Para responder a tu pregunta: Utilizo un subrayado inicial para marcar variables privadas. Lo encuentro claro y puedo escanear el código rápidamente y averiguar qué está pasando.

(Aunque casi nunca uso "esto", excepto para evitar un choque de nombres.)

El uso de 'm_' o '_' en el frente de una variable hace que sea más fácil detectar variables miembro en métodos a través de un objeto.

Como beneficio secundario, escribir ' m_ ' o ' _ ' hará que intellsense los muestre primero;)

• Resulta que me gustan los guiones bajos iniciales para las variables de instancia (privadas), parece más fácil de leer y distinguir.Por supuesto, esto puede meterte en problemas con los casos extremos (por ejemplo, las variables de instancia públicas (no son comunes, lo sé) - de cualquier manera que los nombre que se podría decir que está rompiendo su convención de nomenclatura:
• private int _my_int; public int myInt;? _my_int? )

- por mucho que me guste el _style de esto y creo que es legible, creo que es posiblemente más problemático de lo que vale, ya que es poco común y probablemente no para que coincida con cualquier otra cosa en el código base que está utilizando.

-la generación automatizada de código (por ejemplo, los getters de generación de eclipse, los setters) no es probable que entiendan esto, por lo que tendrá que arreglarlo a mano o muck con eclipse lo suficiente como para que lo reconozca.

En última instancia, vas en contra del resto de las preferencias del mundo (java) y es probable que tengas algunas molestias de eso. Y como los pósters anteriores han mencionado, la consistencia en el código base supera todos los problemas anteriores.

Es bueno tener algo para distinguir las variables privadas vs.públicas, pero no me gusta '_' en la codificación general. Si puedo ayudar en el nuevo código, evito su uso.

Hay una razón por la que usar guiones bajos se consideraba un mal estilo en los viejos tiempos. Cuando un compilador de tiempo de ejecución era algo inasequible y los monitores venían con una asombrosa resolución de 320x240 píxeles, a menudo no era fácil diferenciar entre _name y __name.

Es una mezcla de estilos de codificación. Una escuela de pensamiento es el prefacio de los miembros privados con un subrayado para distinguirlos.

setBar( int bar)
{
   _bar = bar;
}

En lugar de

setBar( int bar)
{
   this.bar = bar;
}

Otros usarán guiones bajos para indicar una variable local temporal que saldrá del ámbito al final de la llamada al método. (Me parece bastante inútil - un buen método no debería ser tan largo, y la declaración está AHÍ! así que sé que va fuera de alcance) Editar: Dios no permita que un programador de esta escuela y un programador desde la escuela memberData colaboramos! Sería un infierno.

A veces, el código generado precede a las variables con _ o __. La idea es que ningún humano haría esto, así que es seguro.

Aquí hay un enlace a las recomendaciones de Sun para Java. No es que tengas que usar estos o incluso que su código de biblioteca siga a todos ellos, pero es un buen comienzo si vas desde cero. Herramientas como Eclipse han incorporado formateadores y herramientas de limpieza que pueden ayudarlo a ajustarse a estas convenciones (u otras que defina).

Para mí, ' _ ' son demasiado difíciles de escribir:)

Creo que cualquier estilo que rompa las pautas de estilo propias de un lenguaje (sin la debida razón) es feo y, por lo tanto, "malo".

Sin duda el código que has visto fue escrito por alguien que solía trabajar en un lenguaje donde los guiones bajos eran aceptables.

Algunas personas simplemente no pueden adaptarse a nuevos estilos de codificación...

La razón por la que la gente lo hace (en mi experiencia) es para diferenciar entre variables miembro y parámetros de función. En Java puedes tener una clase como esta:

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

Si hicieras la variable miembro _var1 o m_var1, no tendrías la ambigüedad en la función.

Así que es un estilo, y yo no lo llamaría malo.

Personalmente, creo que un lenguaje no debería hacer reglas sobre el estilo de codificación. Es una cuestión de preferencias, uso, conveniencia, concepto sobre legibilidad.
Ahora, un proyecto debe establecer reglas de codificación, para la coherencia entre los listados. Es posible que no estés de acuerdo con estas reglas, pero debes atenerte a ellas si quieres contribuir (o trabajar en equipo).

Al menos, los IDEs como Eclispe son agnósticos, lo que permite establecer reglas como prefijos o sufijos variables, varios estilos de colocación de la abrazadera y administración del espacio, etc. Así que puedes usarlo para reformatear código a lo largo de tus pautas.

Nota: Estoy entre los que mantienen sus viejos hábitos de C/C++, codificando Java con prefijos m_ para las variables miembro (y s_ para las estáticas), prefijando booleanos con una b inicial, usando una letra mayúscula inicial para los nombres de funciones y alineando llaves... ¡El horror para los fundamentalistas de Java! ;-)
Curiosamente, esas son las convenciones utilizadas donde trabajo... probablemente porque el principal desarrollador inicial viene de MFC world! :- D

Es solo tu propio estilo,nada es un código de estilo malo,y nada es un buen código de estilo,solo diferencia nuestro código con los demás.