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

Question

Incluso hoy en día, a menudo veo guiones bajos en variables y métodos Java; un ejemplo son las variables miembro (como "m_count" o "_count"). Por lo que recuerdo, el uso de guiones bajos en estos casos se llama mal estilo por Sun.

El único lugar donde deben usarse es en constantes (como en "static final static int IS_OKAY = 1;"), porque las constantes deben ser todas mayúsculas y no camel case. Aquí, el guión bajo debe hacer que el código sea más legible.

¿Cree que usar guiones bajos en Java es un mal estilo? Si es así (o no), ¿por qué?

Answer 1

Si no tiene código para usarlo ahora, le sugiero que continúe. Si su código base lo usa, continúe así.

Lo más importante acerca del estilo de codificación es consistencia. Si no tiene nada con que ser consecuente, entonces las recomendaciones del proveedor del idioma probablemente sean un buen lugar para comenzar.

Answer 2

usando 'm_' o '_' al frente de una variable hace que sea más fácil detectar las variables de los miembros en los métodos de un objeto.

Como beneficio adicional escribiendo 'm_' o '_' hará intellsense hacerlas explotar primero;)

Answer 3

Reglas:

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

Answer 4

Es una mezcla de estilos de codificación. Una escuela de pensamiento es preceder a los miembros privados con un guión bajo para distinguirlos.

setBar(int bar) 
{ 
    _bar = bar; 
} 

en lugar de

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

los demás pueden utilizar guiones para indicar una variable local temporal que irá fuera de alcance 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á CORRECTA, así que sé que está fuera de alcance) Editar: Dios no permita que un programador de esta escuela y un programador de la escuela MemberData colaboren ! Sería un infierno.

A veces, el código generado presentará variables con _ o __. La idea es que ningún ser humano haría esto alguna vez, por lo que es seguro.

Answer 5

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

Sin duda, el código que ha visto ha sido 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 ...

Answer 6

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

Para responder a su pregunta: uso un guion bajo para marcar las variables privadas. Lo encuentro claro y puedo escanear rápidamente el código y descubrir qué está pasando.

(casi nunca usan "este", aunque, excepto para evitar un conflicto de nombres.)

Answer 7

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

public class TestClass { 
    int var1; 

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

Si ha realizado la _var1 variable miembro o m_var1, no tendría la ambigüedad de la función.

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

Answer 8

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs(); 

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Answer 9

personalmente, creo que una lengua no debe hacer reglas sobre el estilo de codificación. Es una cuestión de preferencias, uso, conveniencia, concepto de legibilidad.
Ahora, un proyecto debe establecer las reglas de codificación, para la coherencia entre las listas. Puede que no esté de acuerdo con estas reglas, pero debe cumplirlas si quiere contribuir (o trabajar en equipo).

Al menos, entornos de desarrollo como son Eclispe agnóstico, lo que permite establecer reglas como prefijos o sufijos variables, varios estilos de colocación de corsé y la gestión del espacio, etc Por lo tanto se puede usar para cambiar el formato de código junto sus directrices.

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

Answer 10

Aquí hay un link a las recomendaciones de Sun para Java. No es que tenga que usar estos o incluso que su código de biblioteca los siga a todos, pero es un buen comienzo si va desde cero. Herramienta como Eclipse ha incorporado formateadores y herramientas de limpieza que pueden ayudarlo a cumplir con estas convenciones (u otras que defina).

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

Answer 11

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

Answer 12

• resulta que como líder de guiones para las variables de instancia (privada), parece más fácil de leer y distinguish.Of supuesto esto puede tener problemas con casos extremos (por ejemplo, variables de instancia públicas (no es común, lo sé) - de cualquier manera que las nombre que estés podría decirse que la fractura de su convención de nomenclatura:
• private int _my_int; public int myInt;? _my_int?)

-como mucho que me gusta el _style de esto y creo que es legible me parece que es sin duda más problemas de lo que vale la pena, ya que es poco común y es probable que no coincida con nada más en la base de código que está usando.

-generación de código automatizado (p. eclipses generan getters, setters) no es probable que entienda esto, así que tendrás que arreglarlo a mano o ensuciar con eclipse lo suficiente como para que lo reconozca.

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

Answer 13

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

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

Mi 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 alcance de variables. Entonces no puedes reutilizar _ para global o estático y en su lugar elijo g_ y s_ respectivamente.

Answer 14

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

Answer 15

Hay una razón por la cual el uso de caracteres de subrayado se consideraba un mal estilo en los viejos tiempos. Cuando un compilador en tiempo de ejecución era algo inaccesible y los monitores llegaban con una asombrosa resolución de 320x240 píxeles, a menudo no era fácil diferenciar entre _name y __name.