style standard guides guide google español coding codification code java coding-style

standard - En Java, ¿por qué la gente antepone campos con `this`?



java standard coding rules (16)

  1. Programación defensiva (en caso de que alguien edite el código más tarde agrega un parámetro o local con un nombre conflictivo
  2. Haga que el código sea "autodocumentado", más obvio

Al hacer referencia a las variables de clase, ¿por qué la gente lo antepone a this ? No estoy hablando del caso cuando this se usa para eliminar la ambigüedad de los parámetros del método, sino cuando parece innecesario.

Ejemplo:

public class Person { private String name; public String toString() { return this.name; } }

En toString , ¿por qué no solo el name referencia como name ?

return name;

¿ this.name compra this.name ?

Aquí hay una pregunta de stackoverflow cuyo código tiene this pre-pendiente.


"esto" evita la confusión con las variables de instancia con el mismo nombre en la clase padre / es.

Es más o menos el complemento de anteponer con "super".


A menudo veo que la gente hace esto porque desencadena el intellisense. Yo personalmente prefiero dejar el "esto". porque crea más código sin ningún valor.


A veces es necesario desambiguar:

public void setFoo(Bar foo) { this.foo = foo; }

En otras ocasiones, es solo una cuestión de estilo. En general, trato de evitar this.blah siempre que sea posible, ya que es más detallado. En caso de que se lo pregunte, el bytecode resultante es exactamente el mismo.


Además de la desambiguación con los parámetros del método, no te compra nada. Tal vez claridad / legibilidad, pero eso realmente depende de tu estilo.


Creo que no hay nada de malo si pones esto antes del nombre de la propiedad. Esto ayuda a eliminar la ambigüedad de la propiedad de las variables locales si tiene alguna declarada con el mismo nombre (lo que puede suceder en un constructor cuando inicializa las propiedades).

No afecta el rendimiento, no crea ningún problema para la legibilidad (si es que facilita la lectura).

Entonces no creo que tengamos que preocuparnos por esto. Permita que los programadores tomen su propia decisión.


El único lugar donde uso esto es en constructores en clases donde algunos / la mayoría de los campos de la clase pueden ser suministrados por el constructor. Utilizo esto en lugar de usar nombres cortos para la firma del método, simplemente parece más consistente que abreviar.

Por ejemplo, en una clase "Racional"

En lugar de hacer

class Rational { int denominator; int numerator; public Rational(int d, int n) { denominator = d; numerator = n; } }

Hago esto.

class Rational { int denominator; int numerator; public Rational(int denominator, int numerator) { this.denominator = denominator; this.numerator = numerator; } }

De esta forma, las personas que llaman saben más sobre para qué son los parámetros de los constructores.


El código es más simple de leer. Otra buena práctica, en mi opinión, es llamar a getXXX() en toString() también (en lugar de this.XXX ), porque el getXXX() puede tener una lógica importante.

Creo que usar el nombre de atributo sin esto no es una buena idea para el mantenimiento de la aplicación.


En .NET world, la herramienta Microsoft StyleCop también tiene una regla llamada "Prefijo de llamadas locales con esto":

Una violación de esta regla ocurre cuando el código contiene una llamada a un miembro de instancia de la clase local o una clase base que no tiene el prefijo ''this.''. Se produce una excepción a esta regla cuando hay una anulación local de un miembro de la clase base, y el código intenta llamar al miembro de la clase base directamente, evitando la anulación local. En este caso, la llamada puede tener el prefijo ''base''. En vez de esto.''.

De forma predeterminada, StyleCop no permite el uso de guiones bajos o m_ para marcar campos de clases locales, a favor del ''esto''. prefijo. La ventaja de usar ''esto''. es que se aplica por igual a todos los tipos de elementos, incluidos los métodos, propiedades, etc., y no solo a los campos, haciendo que todas las llamadas a los miembros de la clase sean reconocibles al instante, independientemente del editor que se use para ver el código. Otra ventaja es que crea una diferenciación rápida y reconocible entre los miembros de la instancia y los miembros estáticos, que no tienen prefijo.

Una ventaja final de usar el ''esto''. prefijo es eso escribiendo esto. hará que Visual Studio muestre la ventana emergente de IntelliSense, haciendo que el desarrollador pueda elegir de forma rápida y sencilla al miembro de la clase a quien llamar.

Mi sugerencia es elegir una convención (use esto o no) y quédese con eso.


Intento usar ''this.whatever'' al escribir grandes fragmentos de código, porque era más fácil averiguar a qué se refería. Al leer grandes porciones de código escrito por otras personas, en ciertos puntos a menudo me confundía si estaban haciendo referencia a variables de instancia o variables locales.


La misma razón por la cual a algunas personas les gusta anteponer a los miembros de datos privados con "m_" o con las interfaces de nombre "IFoo". Creen que aumenta la legibilidad y la claridad. Si está de acuerdo o no con convenciones como estas es una cuestión de gusto.


Le ayuda a identificar las variables miembro de un vistazo ...
el ToString () de arriba es demasiado pequeño para ilustrar esto.
Supongamos que tiene un método de tamaño de pantalla. Calcula, asigna, intercambia una combinación de variables locales y de instancia. this.memberVar o this.PropertyName ayuda a realizar un seguimiento de dónde está modificando el estado de la instancia a través de asignaciones de campo o definidores de propiedades.


No hace nada en el nivel del idioma. Pero da una indicación inmediata a alguien que lee el código sobre el alcance de la variable, lo que mejora la comprensión del código.


Otra cosa a tener en cuenta es el lenguaje en sí. No mencionaste específicamente Java (aunque supongo que realmente no tienes nada más en mente, así que este comentario es más FYI), pero como los anteriores han mencionado ya es una forma excelente de hacer código propio. documentando para evitar confusiones en el camino cuando alguien más comienza a modificar su código base.

Sin embargo, si usa PHP, el uso de $this es típicamente necesario al hacer referencia a variables de clase. Con diferentes reglas entre idiomas, a menudo es más fácil seguir con el patrón que es común entre ellos, un patrón que resulta ser un estilo de codificación muy sólido. Es más fácil para mí simplemente anexar this a todo que tratar de recordar qué idioma lo requiere y qué lenguaje simplemente "lo prefiere".


Son quizás un programador de Python y se torturan / pierden / confunden sin un esto explícito.


Un pequeño aparte, pero puede valer la pena señalar que la herramienta "Limpiar" en Eclipse se puede configurar para agregar / eliminar esto automáticamente. a los accesos de los miembros según la preferencia.

"Java / Code Style / Clean Up" en el diálogo de preferencias.