‘this.’ is the question

Desde mis comienzos siempre he ido utilizando la palabra clave “this”, desde C++ hasta ahora con C#. El por qué, es porque me ha resultado más comodo a la hora de escribir y me ha resultado más comprensible el código a la hora de entenderlo, de la misma forma que uso otra de las palabras clave de acceso como ‘base’, aunque ésta únicamente se utilice en clases derivadas.

Por otro lado, desde hace algo más de un año vengo utilizando Resharper de jetbrains, y pese que en la versión 4.0 noté ciertos problemas de rendimiento, ahora, con la versión 4.5 recién lanzada, la verdad es que me resulta una herramienta productiva y útil. Bien, la cuestión es que Resharper, por defecto, lanza un “warning” cuando encuentra un “this.” en el código e indica que se trata de una palabra redundante, y  ciertamente en muchas de las ocasiones lo es, de la misma forma que lo es “base” o el uso del constructor de un delegado o el método ToString(), en algunas ocasiones. Pese a las “advertencias” he seguido utilizandola principalmente, y como he dicho, por comodidad y percepción de entendimiento del código y creí que estaba dentro de las “pautas de buenas practicas” el no usar redundancias dentro del código. A mi me la repampinfla. El uso de “this” no afecta al rendimiento ni me aporta ningún inconveniente, ergo seguiré utilizándola.

resharper_warning

Sin embargo, de camino a casa, en el tren, he estado probando Microsoft StyleCop para la evaluación de sintaxis C# el cual he utilizado para comprobar el código de un servicio WCF, generado por el asistente de Visual Studio a partir de la plantilla de proyecto WCF Service Library. Esta plantilla implementa un DataContract (CompositeType) con un par de propiedades las cuales no hacen uso de la palabra clave “this” y StyleCop, al ejecutarlo, me ha dado un warning [SA1101]. Esto me ha echo pensar si realmente la supuesta doctrina de buenas practicas recomienda o no el uso de esta palabra clave, es decir si realmente existe como tal.

stylecorp_result

Más allá de lo trivial del asunto, he estado mirando por Internet y no he encontrado, o no he sabido encontrar, nada relativo a ello y es por ello que ahora, a parte de estar haciendo tiempo en el tren de caminito a casa, me pregunto, en modo de curiosidad, ¿vosostros utilizáis “this” en vuestros desarrollos?

this

   1: [DataContract]
   2: public class CompositeType
   3: {
   4:     bool boolValue = true;
   5:     string stringValue = "Hello ";
   6:  
   7:     [DataMember]
   8:     public bool BoolValue
   9:     {
  10:         get { return this.boolValue; }
  11:         set { this.boolValue = value; }
  12:     }
  13:  
  14:     [DataMember]
  15:     public string StringValue
  16:     {
  17:         get { return this.stringValue; }
  18:         set { this.stringValue = value; }
  19:     }
  20: }

not this

   1: [DataContract]
   2: public class CompositeType
   3: {
   4:     bool boolValue = true;
   5:     string stringValue = "Hello ";
   6:  
   7:     [DataMember]
   8:     public bool BoolValue
   9:     {
  10:         get { return this.boolValue; }
  11:         set { boolValue = value; }
  12:     }
  13:  
  14:     [DataMember]
  15:     public string StringValue
  16:     {
  17:         get { return stringValue; }
  18:         set { stringValue = value; }
  19:     }
  20: }

 

NOTA: Probablemente este código no describa el valor descriptivo del uso de this, pero es que no me ha dado tiempo de crear un código descritivo para tal fin.

14 comentarios sobre “‘this.’ is the question”

  1. No deberías de aferrarte a prácticas antiguas, todo programador debe de estar apto a adaptarse al cambio y a la evolución de los lenguajes, imagínate cuando nos toque pasarnos a lenguajes dinámicos, seguro queras regresar a Visual Basic 6.

  2. No suelo usarlo a no ser que sea imprescindible, ni en C++ y menos en C# que todavía lo es menos.

    Yo si veo mucho «this->» me pongo nervioso, cosas de la vida, je je.

  3. Yo siempre opto, en lo que al código se refiere, por ser lo más explicito posible. El código lo vas a leer muchas más veces que lo vas a escribir, y ver el this te deja claro que estás hablando de un miembro de la clase y no de un parámetro.

    Un saludo.

  4. Tampoco uso this, a menos que sea necesario, pero al utilizar StyleFxCop me saltaron los mismos warnings… por lo que opté por deshabilitar esta opción en StyleFxCop.

    A veces me resulta demasiado obvio el uso de this.

  5. Servidor viene de C++ y he ido cambiando a lo largo de los años…

    Empecé usando m_ para todos los campos privados de las clases y no usaba this->
    Luego en C# me adherí a la convención de que las variables privadas empezaran por _ y no usaba this en ningun caso.
    Ahora uso this. en todas las llamadas a miembros (sean públicos o privados) de mis clases (al menos cuado me acuerdo), aunque sigo teniendo cierta tendencia a que las variables privadas empiezen por _, aunque a StyleCop no le guste, jejeeee… 🙂

    Es cierto que el uso de this es redundante, pero también lo es lo que dice Rodrigo: de un simple vistazo uno sabe que aquello es una variable de clase y no un parámetro o variable local.

    Saludos!

  6. Al igual que Eduard, con los años uno va usando diversas metodologías…
    De modo que yo si uso actualmente ‘this’. Por los mismos motivos que él y Rodrigo, aunque también os digo que en el pasado no lo hice.
    Quién sabe? Que metodología usaré dentro de unos años (y el que me diga que no cambia su metodología con el tiempo es que miente como un bellaco).

  7. Yo tengo un problema con «this.», me da un error de compilación

    Pero si pongo «Me.» ese error se soluciona,

    no lo sé, serán cosas raras del Visual Studio

    Saludos

  8. A mi me pasa como a Rafael. Me gusta que el código sea conciso y sin redundancias porque así hay que leer menos y se lee más rápido. Por eso si hay muchos this también me ponen nervioso por que me estorban para la lectura y los borro.

    Yo solo uso this en los constructores para asignar las variables a partir de los parámetros.

    También elimino las clausulas private e internal redundantes por la misma razón.

    Pero todo esto son simples cuestiones de gustos personales, si a alguien le ayudan los this, pues que los ponga.

  9. A mí me parece bien usar this porque se me hace más fácil de leer el código, rápido veo que pertenece a la clase y dentro de un método sé que no es un parámetro.

    Salu2

  10. Yo se rápidamente que un parámetro es un parámetro por su nombre. A esto ayuda el no escribir métodos de muchas líneas para tener visible la totalidad del método en todo momento.

    También ayudan un monitor grande y una fuente pequeña. 1280×1024 es el mínimo mínimo para programar cómodamente.

    Saludos

  11. Yo soy un adicto al this desde mis tiempos de practicas en la carrera; se que muchas veces es redundante, pero no hace daño, y esoty seguro que en alguna ocasion me libro de algun bug por la declaración implicita.

    Por cierto, justo ahora estoy escuchando un tema de los Guns N’ Roses que se llama ‘This I Love’ 😉 Yeah!

  12. Yo lo uso por la poderosa razón de la vagancia y es que T H I S . sale de mis dedos a una velocidad endemoniada y luego el intellisense salta para evitar que agote los dedos demasiado…

    Lo uso por el intellisense. This punto, un par de letras y control intro. Y escribo realmente poco.

    Un saludo, J.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *