Leo this answer y sus comentarios y tengo curiosidad: ¿Hay alguna razón para no usar this/Self/Me?¿Hay alguna razón para no usar "esto" ("Self", "Me", ...)?
BTW: Lo siento si esto se ha preguntado antes, parece que es imposible buscar la palabra this en SO.
Advertencia: respuesta puramente subjetiva a continuación.
Creo que la mejor "razón" para no usar este/self/me es la brevedad. Si ya es una variable/función miembro, ¿por qué agregar el prefijo de forma redundante?
Personalmente evito el uso de este/self/me a menos que sea necesario para eliminar la ambigüedad de una expresión particular para el compilador. Muchas personas no están de acuerdo con esto, pero nunca lo he tenido como un verdadero punto de fricción en ningún grupo para el que haya trabajado.
Se preguntó antes de hecho, en el contexto "variable en java":
Do you prefix your instance variable with ‘this’ in java ?
La principal razón por la recurrente parece ser:
"Aumenta el ruido visual que necesita para examinar el significado del código ".
Legibilidad, en otras palabras ... que no compro, me parece muy útil this..
Eso me suena a tonterías. Usar 'esto' puede hacer que el código sea más agradable, y no veo problemas con él. Las políticas como esa son estúpidas (al menos cuando ni siquiera le dices a la gente por qué están en su lugar).
Creo que la mayoría de los escenarios comunes se han cubierto en las dos publicaciones ya citadas; principalmente la brevedad y la redundancia vs claridad - de una pequeña adición: en C#, se requiere utilizar "this" con el fin de acceder a un "método de extensión" para el tipo actual - es decir
this.Foo();
donde Foo() se declara externamente como :
public static void Foo(this SomeType obj) {...}
como para mí i uso this para llamar a métodos de un objeto instanciado mientras que self es para un método estático
¿En qué idioma? –
PHP, esto también es cierto para java, pero en lugar de self, el nombre de clase en sí es el prefijo – ken
Se aclara en algunos casos, como en este ejemplo en C#:
public class SomeClass
{
private string stringvar = "";
public SomeClass(string stringvar)
{
this.stringvar = stringvar;
}
}
¿Pero no sería esa una razón para usarlo? (Y no no usarlo?) –
Sería una razón para cambiar el nombre del parámetro;) – boutta
Estoy de acuerdo, el parámetro debería denominarse :) Pero todavía muestra como esta. ayuda a entender que es la variable privada de clase y no el parámetro al que se hace referencia. @daniel: Sí, ese era mi punto. En este ejemplo, tendría sentido usar esto. –
Creo que esto no es un problema, ya que solo agrega más legibilidad al código, lo cual es algo bueno.
Para algunos idiomas, como PHP, incluso es obligatorio prefijar con $ this-> si necesita utilizar campos o métodos de clase.
No me gusta el hecho de que hace que algunas líneas sean innecesariamente más largas de lo que podrían ser, si PHP tuviera alguna forma de hacer referencia a miembros de la clase sin ella.
Al final siempre es una cuestión de elección personal.En lo personal, yo uso esta convención de codificación:
public class Foo
{
public string Bar
{
get
{
return this.bar;
}
/*set
{
this.bar = value;
}*/
}
private readonly string bar;
public Foo(string bar)
{
this.bar = bar;
}
}
Así que para mí "este" es realmente necesario para mantener el constructor legible.
Editar: exactamente el mismo ejemplo ha sido publicado por "sinje" mientras escribía el código de arriba.
un setter para un campo "readonly" ... Uh oh. –
Gracias, comentó el colocador. No hago esto en la vida real, solo un pequeño error cerebral mientras pienso en un ejemplo ;-) Sin embargo, aquí no es realmente el problema; el ejemplo es sobre la línea "this.bar = bar". – user39603
Personalmente encuentro que this.whatever es menos legible. Puede que no note la diferencia en un método de 2 líneas, pero espere hasta obtener this.variable y this.othervariable en todas partes de una clase.
Además, creo que el uso de this. fue encontrado como un reemplazo de una parte de la notación húngara muy odiada. Algunas personas descubrieron que aún es más claro para el lector ver que una variable es un miembro de la clase, y this. hizo el truco. Pero, ¿por qué engañarnos a nosotros mismos y no usar el simple viejo "m_" o simplemente "_" para eso, si necesitamos la claridad adicional? Son 5 personajes contra 2 (o incluso 1). Menos tipeo, mismo resultado.
Habiendo dicho eso, la elección del estilo sigue siendo una cuestión de preferencia personal. Es difícil convencer a alguien que solía leer el código de cierta manera que es útil para cambiarlo.
los cuento "m_" como 5 yemas de los movimientos :) 1) 'm' 2)
Tienes razón sobre los movimientos de los dedos. Yo personalmente prefiero usar plain _, que es más corto. Hablando de eso: Recuerdo una bonita característica de Visual Assist desde los buenos viejos días de C++ - escribir 'm' y luego 'cambio' se insertará automáticamente 'm_'. –
bueno, eclipse hace campos de color, argumentos y variables locales en diferentes colores, por lo que al menos trabajar en un entorno de eclipse no es necesario distinguir sintácticamente campos para marcarlos especialmente como "campos" para usted y las generaciones venideras .
'this.' en el código siempre me sugiere que el codificador ha usado intellisense (u otros equivalentes IDE) para hacer su trabajo pesado.
Soy ciertamente culpable de esto, sin embargo lo hago, por razones puramente de vanidad, eliminarlos después.
Las únicas otras razones por las que ellos utilizan son para calificar una variable ambigua (mala práctica) o construir un método de extensión
una variable de clasificación
string name; //should use something like _name or m_name
public void SetName(string name)
{
this.name = name;
}
En VB.NET uno de la práctica común que use es el siguiente código:
Class Test
Private IntVar AS Integer
Public Function New(intVar As Integer)
Me.Intvar = intvar
End Function
End Class
No todo el tiempo, pero la mayoría de Me/this/self es bastante útil. Aclara el alcance del que está hablando.
Si usa StyleCop con todas las reglas puestas, hace que ponga el this.. Desde que comencé a usarlo, encuentro que mi código es más legible, pero esa es una preferencia personal.
En un método setter típica (tomado de la respuesta de lagerdalek):
string name;
public void SetName(string name)
{
this.name = name;
}
Si no lo usa, el compilador no sabría que se está refiriendo a la variable miembro.
El uso de this. es decirle al compilador que necesita acceder a una variable miembro, que está fuera del alcance inmediato del método. Crear una variable dentro de un método que es el mismo nombre que una variable miembro es perfectamente legal, al igual que anular un método en una clase que ha extendido otra clase es perfectamente legal.
Sin embargo, si usted todavía tiene que utilizar el método de la superclase, se utiliza super. En mi opinión el uso de este. no es peor que usar super. y le permite al programador más flexibilidad en su código.
Por lo que yo estoy preocupado legibilidad ni siquiera entrar en ella, es todo acerca de la accesibilidad de sus variables.
No sólo me utilizan con frecuencia "este". A veces uso "eso".
class Foo
{
private string bar;
public int Compare(Foo that)
{
if(this.bar == that.bar)
{
...
Y así sucesivamente. "Eso" en mi código usualmente significa otra instancia de la misma clase.
comentario subjetivo: Usando esta razón, no se eliminan también los saltos de línea en el código? Primero debe escribir el código para que sea legible por el ser humano y luego leerlo como una segunda prioridad. –
@ Torbjørn: ¿Y si encuentra que omitir este/self/me es más legible para los humanos? –
Lo encuentro más legible para humanos. Prefijo variables de miembro con m _/_ y encuentro que leer this.m_foo no es más legible que m_foo. m_ significa miembro, entonces, ¿por qué agregar el equipaje adicional? – JaredPar