Una vez más me encuentro utilizando mi blog para hacer catarsis, una vez más a causa de los horrores con los que me topo cada vez que se me ocurre examinar un fuente. Con lo cual puedo agregar otro capítulo a mi libro de crónicas de un sysadmin. En este caso, podría titularse "aberraciones que he visto auditando código fuente", o más bien "cómo implementar la burocracia en PHP". Pasen y vean...



Esta vez no se trata de un problema de seguridad o una mala implementación. Pero simplemente viendo este pequeño trozo de código PHP uno puede darse cuenta de que el desarrollador no tiene la más remota idea de lo qué está haciendo:


  Luego de mucho código PHP...

*/

function funcionInutil() {

  if (funcionUtil()) {
    return true;
  }
  else {
    return false;
  }
}

/*

  Más código PHP..
  

¡Una obra de arte!

Ahora bien, analicemos las diferentes alternativas posibles para tratar de dilucidar qué estaba "pensando" este desarrollador al escribir semejante aberración.

Lo primero que se me ocurre es que su empleador le paga el sueldo de acuerdo a la cantidad de líneas de código que escribe, situación que tal vez lo haya empujado a agregar algunas líneas de código "extra" a su proyecto (sin importar que éstas hagan trabajo útil).

Desde el punto de vista del diseño, inmediatamente me surge la pregunta: "¿por qué haría eso?". Es decir, ¿para qué quiere/necesita una función que sólo retorne lo que hace otra? ¿Por qué no simplemente llamar a la primera? De aquí se desprenden dos teorías.

Tratando de buscarle algo de lógica al asunto podría pensar que dicha función es parte de una librería, que en una versión nueva se le ha modificado su nombre, y que, por cuestiones de compatibilidad hacia atrás, se necesita mantener también el nombre anterior. De esta forma, dicha función sería una especie de alias. Pero si es éste el caso, por qué no simplemente escribió:

function funcionInutil() {
  return funcionUtil();
}

Esto me lleva a pensar en la siguiente teoría: el desarrollador no tiene idea cómo se convierten los valores booleanos en PHP. Lo que sucede es que la primera función no retorna un valor booleano sino un entero, string u otro tipo de variable. Recordemos que PHP, además del valor booleano FALSE, evalúa como falso al entero 0, al real 0.0, a la cadena vacía o a la cadena "0", y a un arreglo sin elementos, entre otros. Entonces lo que este desarrollador necesita, tal vez, es una función que retorne un booleano a partir de otra que retorna un valor no booleano. Pero, si PHP convierte correctamente a booleano en la expresión dentro del if, ¿por qué no lo haría en cualquier otro if? Y una vez más, si se necesita una función que retorne estrictamente un booleano (por cuestiones de almacenamiento o lo que sea), ¿por qué no directamente usar un cast (implícito o explícito)?

// cast explícito
(boolean) funcionUtil()
// cast implícito
(funcionUtil() == true)

Para colmo, este tipo de funciones se repiten una y otra vez a lo largo del código, lo cual refuerza aún más la idea de esta teoría.

Si piensan que soy un amargado, sepan que ésta es la clase de código que tengo corriendo en mis servidores, robando recursos y consumiendo valiosos ciclos de mis CPUs.

Para finalizar el artículo con un poco de humor, dejo un breve cuento que hace referencia a un capítulo de Los Simpsons:

    ...Estos son mil monos con mil MacBooks.
    Pronto habrán terminado la versión de Wordpress más lenta de la historia
    Veamos...
    "retorna vooleano".
    ¡¿Booleano con ve chica?! ¡Mono tonto, estúpido!

Tal vez algún desarrollador PHP con experiencia puede aportar su idea, o echar algo de luz, acerca de por qué este individuo implementó este pedazo de código de esta forma.

Si se divirtieron leyéndome despotricando contra los desarrolladores, los invito a leer los otros episodios de la saga:

Crónicas de un Sysadmin

Cómo "piensa" un desarrollador de software

Lo más difícil del mundo

Monitoreo en tiempo real y detención de procesos en MySQL (el de los 23 JOIN)


Tal vez pueda interesarte


Compartí este artículo