CheckStyle: Parameter Assignment

Haciendo una revisión de algunos incumplimientos de reglas detectados por Sonar, nos llamó mucho la atención a un proveedor y a mi un incumplimiento que se repetía en distintas partes del código de una aplicación Java basado en una regla de CheckStyle denominada «Parameter Assignment», ya que ninguno de los dos entendíamos por qué.

¿Cuándo se produce el incumplimiento de esta regla? Cuando dentro del cuerpo de un método se asigna un valor a un parámetro de entrada.

Para intentar entender los motivos acudí a Internet y al libro «Refactoring: improving the design of existing code» de Martin Fowler y Kent Beck y básicamente es el siguiente:

Mejorar la comprensibilidad de los métodos por la confusión que existe en muchos casos con el paso de parámetros a los métodos en Java. En Java siempre se realiza un paso de parámetros por valor, es decir, el método trabaja con una copia del parámetro enviado por el método llamante por lo que cualquier posible cambio en dicho parámetro dentro del mismo no afecta hacia fuera de él, no obstante la confusión la tenemos cuando el parámetro que se envía es un objeto en lugar de un tipo primitivo, en ese caso también existe un paso por valor, pero la copia en esta caso es una referencia a memoria por lo que los cambios en este caso si pueden tener su reflejo en el método llamante. Como pese a que el paso del parámetro es siempre por valor, pero el comportamiento varía en función de si lo que se pasa es un objeto o un tipo primitivo una forma de darle un tratamiento homogéneo es tratar el parámetro de entrada como una «constante» y que si hay que hacer operaciones se haga con variables u objetos temporales.

Además de tratarse de una regla de estilo (claridad, comprensión y homogeneización), en mi opinión (y es solo mi opinión) también es una forma de prevenir cambios no deseados en el valor de un objeto mediante al acceso a su contenido en los métodos donde se pasa el valor de su referencia en memoria.

1 comentario

Deja un comentario