SOFTWARE CRAFTMANSHIP - 003

Hacer Distinciones Significativas

Los programadores crean problemas para si mismos cuando escriben código de tal forma que solo satisfaga las reglas de un compilador o interprete.  

Por ejemplo, como no se puede usar el mismo nombre para hacer referencia a la misma cosa dentro del mismo alcance del código (scope), podrías estar tentado a cambiar los nombres de forma arbitraria, como volar una letra o escribirla en mayúsculas o minúsculas (persona, Persona, person, pErson) por mas simple que parezca ninguno de los nombres anteriores son lo mismo para un compilador como C#, Java o C++, esto nos llevaría a la sorpresiva situación de que nuestro código no compile si por error cambiamos tan solo una de las letras anteriores.

Tampoco es suficiente el agregar una serie de números o palabras que causan ruido, el compilador no va  quejarse de eso.  Si debemos usar nombres diferentes se entiende entonces que significan cosas diferentes.

Otra forma de desinformar lo que significa un nombre es emplearlo de forma repetitiva con prefijos que también significan lo mismo:  ProductoInfo o ProductoData (Que acaso no es lo mismo?), a este concepto le llamaremos "Palabras de Ruido", otro ejemplo de esto seria en métodos de alguna clase como: 
  getCuentaActiva();
  getCuentasActivas();
  getInfoCuentasActivas();

Como podría un programador del grupo de trabajo saber a cual de estos métodos llamar?

Usa Nombres Pronunciables

Los humanos somos buenos con las palabras.  Una significativa parte de nuestro cerebro esta dedicado al concepto de palabras.  Y las palabras son, por definición, pronunciables.

Una compañía que conozco utiliza GEFAMDHMS (Generación de Fecha, año, mes, día, hora, minuto y segundo).   Al caminar por sus pasillos notas como resuenan las letras "ge fa eme de ache eme ese" que para alguien que no es del entorno resulta hasta chistoso ya que es utilizado por algunos para hacer burlas sobre el mal nombramiento de métodos en sus sistemas.

Para los programadores nuevos es imposible saber su significado hasta que no se los explican.  Veamos un ejemplo:
class DtaRcrd102 {
  private Date gefamdhms;
  private Date moamdhms;
  private final String pszqint = "102";
  /* --- */
}
ó
class Cliente {
  private Date timeStampGenerado;
  private Date timeStampModificado;
  private final String idRegistro = "102";
  /* --- */
}
Una conversación inteligente es ahora posible:
"Hey, Miguel, mira este registro! La generación del TimeStamp esta puesta para mañana! Como puede ser posible?"

Usa Nombres Encontrables

Nombres de solo una letra o constantes numéricas tienen un particular problema y es que no son fáciles de localizar dentro del texto.

El buscar variables como MAX_CLASES_POR_ESTUDIANTE o 7 puede resultar en un dolor de cabeza o el simple hecho de que nunca puedan ser encontradas mientras su intrincada composición evade la búsqueda del programador.

Veamos un ejemplo de una variable fácilmente localizable partiendo de lo no deseado:
  
  for (int j=0; j < 34; j++) {
    s += (t[j] * 4) / 5;
a
  
  int diasRealesPorDiaIdeal = 4;
  const int DIAS_TRABAJABLES_POR_SEMANA = 5;
  int suma = 0;
  for (int j=0; j < NUMERO_DE_TAREAS; j++) { 
    int diasRealesTrabajo = tareasEstimadas[j] * diasRealesPorDiaIdeal;
    int semanasRealesTrabajo = (diasReales / DIAS_TRABAJABLES_POR_SEMANA);
    suma += semanasRealesTrabajo
  }

Nótece que suma al final no es particularmente un nombre útil pero por lo menos es adecuado para búsquedas.

Evita Nombres Codificados

Que acaso no es suficiente con las codificaciones que deben ser dominadas en cuanto al Framework que se utilice como para agregar mas complicación con los nombres que tenemos la capacidad de crear.

En muchas compañías es de uso común algún tipo de codificación para el nombramiento de campos o entidades, llevando el código a los extremos de no comprender lo que hace o lo que maneja a simple vista.

La Notación Húngara

Fue considerada como muy importante en los tiempos del Windows C API, donde todo era un manejador de enteros un largo puntero o un puntero invalido (void), o quizás una de las tantas implementaciones de cadenas (string, con diferentes usos y atributos).  El compilador no verificaba los tipos de datos en esos días, así que el programador necesitaba una muleta para recordarlos.

En los lenguajes modernos tenemos un sistema mas rico de tipos y el compilador recuerda y asegura los tipos.  Mas aun, hay una tendencia hacia clases mas pequeñas y métodos mas cortos de forma que las personas puedan percatarse de la declaración en cada variable que utilicen.

Los Prefijos Miembros

Ya no es necesario utilizar prefijos en los miembros variables con "m_".  Tus clases y funciones deberían ser lo suficientemente pequeñas como para no necesitarlas.  Recordemos que estos prefijos eran utilizados para denotar variables internas privadas de la clase y que su valor solo era modificado o leído por un método.  Por ejemplo:
public class Pieza {
  private String m_dsc; // Descripcion contextual
  void setNombre (String nombre) {
  m_dsc = nombre;
  }
}
Lo recomendado seria:
public class Pieza {
  String descripcion;
  void setDescripcion (String descripcion) {
  this.descripcion = descripcion;
  }
}

Comentarios

  1. Veo que has pasado trabajo con estas cosas, solo asi se aprende las cosas que escribiste, ya lo pase tambien. Muy buen aporte para los que empiezan ... Muy bien!!!

    ResponderEliminar
    Respuestas
    1. Gracias Edwin, pero quiero dejar constancia de que esto es una traduccion del libro SOFTWARE CRAFTMANSHIP que detalle en el 1er. post.... jejejej, he pasado algunas de las que menciona el libro pero debo darle el credito al autor. Espero poder completar mi meta de resumir y traducir el libro por completo para los que no saben ingles.... un abrazo

      Eliminar

Publicar un comentario

Entradas populares