Funny coding (I)

Te asignan una incidencia, abres un archivo fuente, y lees:

private static final String CADENA_CERO = "0";
(...)
BigDecimal cero = new BigDecimal(CADENA_CERO);

Ese es el espíritu de un buen programador precavido. ¡Nunca se sabe cuándo pueden decidir cambiar el valor del cero por 1,23!

Pero ese no es el único error en dos líneas de código...

Esto quizá sea un poco "Java 101", pero, ya que me pongo a criticar, por lo menos que queden claros los motivos...

El tema de las constantes (en Java, los campos static final) es bastante subjetivo. Hay quien piensa que merece la pena el esfuerzo de escribir como constante cualquier campo susceptible de ser modificado, hay quien lo hace por intentar optimizar el código, y hay quien (como un servidor) prefiere pasar bastante de definir constantes. Lo que no admite discusión es que definir la CADENA_CERO no tiene el más mínimo sentido: el cero lleva representándose con el símbolo 0 toda la vida de dios, es mucho más largo escribir CADENA_CERO que "0", y no existe ninguna ventaja respecto al rendimiento. Las cadenas de caracteres son tratadas de forma especial por el compilador de Java, algo así como la técnica de propagación de constantes. Cuando el compilador de Java encuentra una cadena tal como "0", la almacena en una caché de constantes y sustituye todas las referencias siguientes por ese objeto ya creado.

Sin embargo, la siguiente línea es más interesante, porque ilustra un fallo muy común en programadores que todavía no han leído los libros básicos de Java (Effective Java de Joshua Bloch) y/o los Javadoc de las librerías estándar: el operador new SIEMPRE crea un objeto nuevo, mientras que es habitual encontrar constantes en las librerías "bien hechas". En el caso de la clase BigDecimal, y para Java 5+, es BigDecimal.ZERO. Y para los casos en los que no haya constantes, es habitual encontrar en el API estándar métodos valueOf() que están diseñados para cachear valores frecuentes. Hay que mirar el API, que es gratis.

Class dismissed!