Ir al contenido principal

Pleonasmos booleanos


A veces es bueno escribir más código del necesario para que sea fácil de leer. Para que la persona que le de mantenimiento pueda entender de forma clara y rápida lo que hace el código. Esa persona en el futuro puedes ser tú mismo. Hay otras veces que el código redúndate no ayuda, al contrario es ruido que no dejar ver lo que realmente está pasando. Puede esconder bugs difícil de ver a simple vista.

Al escribir código debemos tomar en cuenta que no solo escribimos para la maquina. A la computadora no el importa como escribamos las cosas, para ella es lo mismo el nombre de las variables, el estilo de programación, el lenguaje, paradigma, etc. El código fuente que escribimos debemos pensar que es para las personas que van a leerlo. Escribimos para personas, no para maquinas. Por lo tanto debemos de ser claros con lo que tratamos de expresar en el código. Tampoco es una novela a la que le debemos dar suspenso o drama. Deben ser una serie de instrucciones concretas sin palabras de más.

Los pleonasmos en el código son esas palabras que no es necesario escribir, que están de más. He visto que pasa con los booleanos.

Tomemos por ejemplo algo en JavasScript: supongamos que tenemos un formulario en una página web y necesitamos que el usuario verifique una casilla antes de continuar (¿suena raro eso en español? el usuario necesitar hacer check en un checkbox).

var approveCheckbox = document.GetElementById("approve");
var continueButton = document.GetElementById("continue");

if (approveCheckbox.checked == true)
  continueButton.disabled = false;
else
  continueButton.disabled = true;

El fragmento de código tiene pleonasmos, palabras de más. En una condición donde esperas un valor booleano, verificar la igualdad a true siempre está de más. Ese es el trabajo de la sentencia condicional (el if). Por lo tanto siempre que veamos == true en un if lo podemos quitar y el código hace lo mismo.

var approveCheckbox = document.GetElementById("approve");
var continueButton = document.GetElementById("continue");

if (approveCheckbox.checked)
  continueButton.disabled = false;
else
  continueButton.disabled = true;


Otra cosa que podemos notar es que el código en el then y en else ambos son asignaciones. Cuando tenemos una asignación en ambos casos y solo cambia según la condición podemos usar el operador ternario "?". Esto es un cambio opcional que a veces ayuda a reducir el ruido en el código. Es importante no abusar de esto.

var approveCheckbox = document.GetElementById("approve");
var continueButton = document.GetElementById("continue");

continueButton.disabled =
    approveCheckbox.checked ? false : true;


Ahora es fácil ver que cuando tenemos una asignación a un booleano que depende de otro booleano (condición) podemos simplemente asignar la condición a la variable

var approveCheckbox = document.GetElementById("approve");var continueButton = document.GetElementById("continue");

continueButton.disabled = !approveCheckbox.checked;


Tenemos menos código y es más fácil comprenderlo, darse cuenta que: la propiedad disabled del botón depende de la propiedad checked del checkbox.

Entonces en resumen, lo que podemos hacer para reducir algunos de los pleonasmos en el código son:
  1. Piensa que escribir "== true" es como escribir "subir para arriba". Simplemente bórralo, no es necesario.
  2. Si asignas un valor en el then y otro en el else puedes usar el operador ternario, con moderación.
  3. Si lo que asignas es un booleano que depende de la condición, asigna directamente la condición a la variable. Esto también aplica si comparas valores, algo como: var enable = list.lenght > 0;
Hay otros ejemplos de redundancias en el código o pleonasmos, estos son algunos comunes y "fáciles" de evitar.



Comentarios

  1. Algo que me molesta mucho es el uso de else y de los operadores ternarios cuando no son necesarios, muy buen post.

    ResponderBorrar
    Respuestas
    1. A mi también me molesta... he visto cosas como: "var enabled = isActive == true ? true : false;" en proyectos reales y aún no entiendo cómo no lo ven.

      Gracias por decir por comentar.

      Borrar
  2. Me parece bastante interesante y estoy de acuerdo con tus recomendaciones. Tengo una duda en el uso del operador ternario con moderación. Es decir, en cierta medida es muy limitado dicho operador, pero ¿podrías enfatizar un caso en donde no se recomiende su uso?

    ResponderBorrar
    Respuestas
    1. No recomiendo usarlo cuando se lee mejor el código si usas otra cosa. Un ejemplo es cuando tenemos operador ternarios anidados. Por ejemplo:

      var message = user ? (user.age && user.age > 13 ? 'Sorry, Trix are for kids' : 'Enjoy!' ) : 'user not found';

      Es algo subjetivo, la regla es usar lo que permita mantener el código fácil de entender.

      Borrar
    2. Correcto, muchas gracias Mario. Creí que iba por una cuestión de costo computacional.

      Borrar
  3. todo lo que enseñaron en la escuela se ha derrumbado lol!....
    este tipo de cosas se van aprendiendo conforme se toma experiencia, me recuerda al desarrollo de una ecuacion donde quitas operaciones porque son obvias, aunque habrá quienes lo hagan paso a paso.

    ResponderBorrar
    Respuestas
    1. Hola Diana, estoy de acuerdo contigo. Son cosas que se aprenden con la experiencia. También ayuda leer código de otras personas. Puede ser revisando el repo en github de algún proyecto grande o viendo screencasts.

      Ver estilos de otras personas enriquece tu forma de programar.

      Gracias por tu comentario.

      Borrar
  4. No todo el código que parece redundante lo es y en ocasiones podríamos estar introduciendo vulnerabilidades al refactorizar.

    Entrar en detalles requiere algo de espacio así que contesté en un post en mi blog.

    http://blog.alvarezp.org/2017/01/06/codificacion-defensiva-era-re-pleonasmos-booleanos/

    ResponderBorrar
    Respuestas
    1. Gracias insistir, los comentarios han estado fallando. Me pareció una interesante lectura tu respuesta. Si (yo) hubiera elegido un lenguaje estático como C# para los ejemplos (en lugar de JS) quizás no tendríamos que preocuparnos por esos detalles. Me gustó que lo comentaras para tomarlo en cuenta y no refactorizar sin revisar esas posibilidades.

      Borrar

Publicar un comentario

Entradas más populares de este blog

Bloqueos

Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto.

He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea.

En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto pro…

Firebird 2.1 UPDATE OR INSERT

Another great feature that I like in Firebird 2.1 is the UPDATE OR INSERT statement. It's a really time saver and it makes the SQL cleaner.

For example suppose I have a products table like the one I use in my last post and an inventory table to store the product stock. Before Firebird 2.1 if I want to set the stock for a product I needed to check if a record for that product_id already exists; if the product_id already exists then I write an update. If not then I write an insert statement. So I ended up with something like this:


IF EXISTS(SELECT * FROM inventory WHERE product_id = :product_id ) THEN
UPDATE
inventory
SET
stock = :stock
WHERE
product_id = :product_id;
ELSE
INSERT INTO inventory
(product_id, stock)
VALUES
(:product_id, :stock);

In this example I only update one field but when I have to update a big table I ended up with a big chunk of code and thinking: "there should be another (better) way to do this".

Fortunately now with Firebird 2.1 there…

Database Mail en MS SQL Server 2005

Configuración de Database Mail en MS SQL Server 2005

Primero se debe de habilitar, ya que por omisión el componente esta deshabilitado, Utilizando el SSMS (SQL Server Management Studio)


Si no esta habilitado aparecerá un mensaje preguntado si lo habilita, después aparece esta ventana donde se pregunta al usuario que es lo desea hacer.


Seleccionamos la primera opción para crear un perfil.


Configuramos el perfil y le agregamos por lo menos una cuenta.


Seleccionamos el perfil como public y default.


Para mandar correo se utiliza el procedimiento msdb.sp_send_dbmail por lo tanto el usuario que intente mandar correo debe de tener permiso para la base de datos msdb.

Referencias:
http://www.sqlservercentral.com/columnists/cBunch/introtodatabasemailinsql2005.asp