En múltiples ocasiones, personas que empiezan en el mundo de la programación me han preguntado que hace falta para ser un buen programador. La respuesta dista mucho de ser fácil y simple, pues como en todas las profesiones, son múltiples las aptitudes y actitudes que hacen falta, pero si tuviera que elegir un resumen, a riesgo de dejarme muchas cosas, me quedaría con las tres virtudes del programador que indicó Larry Wall (creador del lenguaje Perl) en su libro Programming Perl. Estas son:

  1. Pereza. Es la cualidad que te hace realizar un gran esfuerzo para reducir el total del gasto energético. Te hace escribir programas que ahorran trabajo y que otras personas encuentran útiles, y documentar lo que escribes para no tener que responder muchas preguntas sobre él.
  2. Impaciencia. La ira que se siente cuando el ordenador se está volviendo perezoso te hace escribir programas que, no solo reaccionan a tus necesidades, sino que se anticipan a ellas, o al menos lo pretenden.
  3. Hibris. El orgullo excesivo es la cualidad que te hace escribir (y mantener) programas de los cuales otras personas no puedan decir cosas desagradables.

Si no tienes experiencia en el mundo de la programación quizás te llamen la atención estas cualidades, pero te aseguro que son de una realidad aplastante.

Pero, ¿Cómo llevarlo a la práctica? En este artículo te voy a dejar unos consejos y buenas prácticas sobre el estilo de programación, independientemente del lenguaje que uses. Por supuesto, “cada maestrillo tiene su librillo” y en este mundo lleno de frikis, cada programador es un maestro pero, salvando algunos matices, todos compartimos las líneas generales. Vamos a ello.

Keep It Simple, Stupid

El estilo de la codificación está directamente ligado con la calidad del software. Ten en cuenta que la mayor parte del coste del software (aproximadamente el 80%) se encuentra en el mantenimiento del mismo y que, generalmente, nunca es mantenido por quien lo creó.

Mantener un código higiénico te ayudará a:

  • Mejorar la legibilidad del software
  • Minimizar errores
  • Disminuir el tiempo de resolución de fallos
  • Facilitar la escalabilidad del código
  • Estandarizar el desarrollo
  • Garantizar la portabilidad

Siempre que puedas, utiliza herramientas para el control de versiones de software. Hay muchas, de muy buenos y algunas gratuitas como Subversion o Git.

Keep it simple, stupid

Pero sobre todo recuerda el principio KISS (Keep It Simple, Stupid – Mantenlo sencillo, ¡Estúpido!) el cual establece que la mayoría de sistemas funcionan mejor si se mantienen simples que si se hacen complejos; por ello, la simplicidad debe ser mantenida como un objetivo clave del diseño, y cualquier complejidad innecesaria debe ser evitada.

 

Organización

Cada archivo debería contener las variables y métodos específicos de la funcionalidad que implementa. Con ello ganaremos en claridad, modularidad y escalabilidad del código. Si estás programando en un lenguaje orientado a objetos, entonces deberías definir un archivo por clase.

Un archivo que contenga varias secciones debe contener líneas en blanco y comentarios que identifiquen cada una de las secciones.

Los archivos no deberían tener más de 2000 líneas. Si se da el caso, plantéate la posibilidad de separarlo.

Todos los archivos deben empezar con un comentario que indique su propósito, el autor, la fecha de creación/modificación, etc. (consulta el apartado comentarios.)

A partir de aquí, deberás respetar la estructura de la siguiente figura:

Estructura de un programa

Evita las líneas excesivamente largas. Aunque hoy en día se ha evolucionado muchísimo en las resoluciones de pantalla, no se recomiendan líneas de más de 80 caracteres.

No incrustes números o cadenas de caracteres en el código. Utiliza constantes.

Usa enumeraciones siempre que puedas. No uses números o cadenas para indicar valores discretos.

Evita usar variables globales. Declara variables locales siempre que sea necesario y pásalas a otros métodos en vez de compartir una variable global entre métodos. Si compartes una variable global entre métodos, te será difícil rastrear qué método cambia el valor y cuando. Si utilizas clases, no definas las variables miembro como públicas. Utiliza propiedades o métodos para acceder a ellas.

Evita escribir funciones muy largas. Una función no debería tener más de 25 líneas de código. Si se da el caso, estudia la posibilidad de dividirla en dos funciones separadas.

El nombre de las funciones debe indicar claramente qué hacen y a poder ser, utilizaremos verbos ya que éstas, normalmente, están vinculadas a una acción.

Una función debe realizar una única tarea.

Evita pasar muchos parámetros a una función. Si tienes más de 4 ó 5 parámetros, plantéate definir una estructura.

Acuérdate de liberar los recursos adecuadamente.

Nunca asumas que tu código se ejecutará desde la unidad “C:”. No puedes saber si algunos usuarios lo ejecutan desde la red o desde “Z:”

Los mensajes de error deben ayudar al usuario a resolver el problema. Nunca muestres mensajes de error como “Error en la Aplicación”, “Hay un error…” etc. En vez de ello da mensajes específicos como “Fallo al actualizar la base de datos”, y sugiere lo que el usuario debe realizar: “Fallo al actualizar la base de datos. Por favor asegúrate de que la cuenta y la contraseña sean correctos”.

Muestra mensajes cortos y amigables al usuario pero registra el error actual con toda la información posible. Esto te ayudará mucho a diagnosticar problemas. Asegúrate de tener una buena función de registro (logging) la cual puede ser configurada para registrar errores, advertencias o trazar acciones. Si configuras para registrar errores, deben ser sólo errores. Pero si la configuras para registrar las acciones, debe registrar todo (errores, advertencias y acciones).

Antes de acceder a un elemento de una matriz, asegúrate que dicha matriz tiene, al menos, el número de elementos que necesitas.

Siempre verifica los valores de variables y parámetros antes de usarlos. Nunca asumas que si no es el valor esperado, entonces es el otro valor posible.

Bien

if (tipoMiembro == "Registrado") 
{ 
    // Usuario registrado: haz algo… 
}
else if (tipoMiembro == "Invitado")
{
    // Usuario invitado: haz algo… 
}
else
{
    // Usuario inesperado
}

Mal

if (tipoMiembro == "Registrado")
{
    // Usuario registrado: haz algo…
}
else
{
    // Usuario invitado: haz algo…
}

Designar Identificadores

Disponer de un estándar consistente y sólido a la hora de designar el nombre para variables y funciones, nos permitirá ahorrar mucho tiempo durante la fase de desarrollo, así como en la fase posterior de mantenimiento, ya que ganaremos en claridad y facilidad de seguimiento del código.

Estilos de Capitalización y su Uso

Existen básicamente tres tipos de capitalización ampliamente utilizadas por los programadores.

  • Pascal. La primera letra de cada palabra que compone el identificador se escribe en mayúsculas (BackColor)
  • Camel. La primera letra de la primera palabra se escribe en minúsculas y la primera palabra del resto que componen el identificador se escribe en mayúsculas. (backColor)
  • Mayúsculas. Todas las letras que componen el identificador se escriben en mayúsculas. Esta opción se utilizará especialmente para identificadores compuestos por 1 o 2 letras (PI)
Tipo de Identificador Notación Recomendación Ejemplo
Nombre de la Enumeración Pascal Utilizar sustantivos en singular ErrorLevel
Valores de la Enumeración Pascal Utilizar sustantivos en singular FatalError
Función Pascal Utilizar verbos SendCode
Parámetro Camel Utilizar un nombre descriptivo de lo que es. colorValue
Estructura Pascal Utilizar sustantivos en singular MyStruct
Variables Locales Camel Utilizar sustantivos startDate

 

Sensibilidad a Mayúsculas y Minúsculas

Con el objeto de evitar confusiones y garantizar el seguimiento de los programas, no deberás crear dos identificadores diferentes que difieran únicamente en el uso de mayúsculas y minúsculas. Ejemplos:

int Color int COLOR
void calculate() void Calculate()
void MyFunction(string a, string A)

Abreviaturas

Para garantizar la legibilidad y evitar confusiones, deberías seguir las siguientes reglas:

  1. No utilices abreviaturas en los nombres de los identificadores
  2. Utiliza acrónimos cuando estos sean ampliamente conocidos
  3. En el uso de acrónimos, aplica las nomenclaturas Pascal o Camel según las propuestas indicadas anteriormente.

Prefijos de Tipo

A mediados-finales de los 90 se puso de moda el incluir un prefijo a los identificadores que indicara el tipo de éste (nomenclatura Húngara). Esta práctica ha sido erradicada y se desaconseja totalmente su uso.

Idioma de Programación

Por norma general se evitará mezclar diferentes idiomas a la hora de definir los nombres de los identificadores y las funciones. Deberías determinar el idioma a utilizar y mantenerlo a lo largo de todo el programa.

GetFecha GetDate ObtieneFecha

Sangría y Espaciado

La sangría y el espaciado son fundamentales para obtener un código claro, higiénico y legible. A este respecto, estas son mis recomendaciones:

  1. La sangría estará constituida tabuladores de 4 espacios cada uno.
  2. Las llaves ({}) deben estar en el mismo nivel que el código que las genera.
    if () 
     { 
         //Haz algo 
         // … 
         return false; 
     }
  3. Usa una línea en blanco para separar un grupo lógico de código.
    bool Decode(char *frame)
    {
         if (frame == NULL)
             return false;
     
         if (strlen(frame) != HeaderFrameLength)
             return false;
     
         length = frame[0];
         commandCode = frame[1];
     
         DecodeCommandCode();
     
         return true;
    }
  4. Usa un espacio simple antes y después de los operadores.
    for (int i = 0; i < 10; i++)
  5. Los comentarios deben estar al mismo nivel de sangría que el código comentado.
    // Get bytes until the postamble DLE ETX is reached
      while (bytesReceived < (bytesToReceive + 2))
      {
         // do something
      }
  6. Evita poner más de una instrucción por línea
    for(int i = ValueMin; i < ValueMax; i++)
         iterator = i;
  7. Cuando una expresión no te quepa en una única línea, pártela siguiendo estos principios:
    1. Después de una coma.
    2. Antes de un operador.
    3. Alinea la nueva línea con el principio de la expresión del mismo nivel de la línea anterior.
function(longExpression1, longExpression2, longExpression3,
         longExpression4, longExpression5);

Comentarios

“Comentar el código es como limpiar el cuarto de baño; nadie quiere hacerlo, pero el resultado es siempre una experiencia más agradable para uno mismo y sus invitados” Ryan Campbell

Los comentarios buenos y entendibles hacen el código más fácil de mantener.

Escribe comentarios siempre que sea necesario, pero recuerda que un buen código requerirá muchos menos comentarios. Si todos los nombres de variables y métodos son entendibles, el código será muy legible y no necesitará tantos comentarios. Ten en cuenta que los comentarios también están sujetos a mantenimiento, ya que se modificamos el código, deberemos modificar su comentario.

Los comentarios no dejan de estar sujetos a las normas gramaticales y sintácticas. Evitas las faltas de ortografía.
¡Nuevamente el idioma! Determina cual será el idioma utilizado para comentar el código y evita la mezcla lingüística. Ello solo aporta caos al código.

A continuación te presento mis recomendaciones sobre aquellos comentarios que siempre deberían estar presentes.

Información Sobre El Archivo

Deberá ser lo primero que nos encontremos al abrir archivo. Lo normal es encontrar una descripción sobre lo que implementa, el autor, la fecha de creación y un histórico de las revisiones.

/*-----------------------------------------------------------------------------
* Fichero: ODBCMgr.h
*
* Descripción: Conjunto de funciones que permiten la manipulación por código de
* las conexiones OBDC definidas en el PC
*
* Autor: Esther Claravalls
*
* Fecha Creacion: 24/8/2000
*
* Proyecto: 
* ------------------------------------------------------------------------------
* REGISTRO DE MODIFICACIONES
* Versión     Fecha     Autor    Modificacion
*   1.0     24/8/2000    ECL     Version Incial
*
------------------------------------------------------------------------------*/

Información Sobre Funciones.

Cada una de las funciones implementadas debería incluir una cabecera a modo de comentario, que nos informe de los parámetros de entrada, del valor de retorno y de cuál es su misión.

/*------------------------------------------------------------------------------
* SwabString
* ------------------------------------------------------------------------------
* Descripción: Intercambia los caracteres de una cadena de caracteres.
* Ej.: A1B2C3 >> 1A2B3C
*
* Parametros: datos – cadena de caracteres a modificar
*             numerOfChars - Numero de caracteres a manipular
*
* Retorna: Nada
*
* Condiciones: El número de caracteres debe ser par, sino se añade un espacio
* en blanco
*
* Efectos: Modifica la variable de origen pasada a través del parámetro datos
------------------------------------------------------------------------------*/

Información Sobre Modificaciones en Código en Producción

Una vez ya tenemos un código en su versión RTM, es decir, en producción, es especialmente importante registrar las modificaciones que realizamos, la causa de éstas, quien la realiza y cuando.

//--------[ECL 13/09/13] START -----------------------------------
// Only launch RunTransferForm when the transfer is automatic
//----------------------------------------------------------------
if (!frm.NewTransfer.IsAutomatic)
    return true;
//--------[ECL 13/09/13] END -------------------------------------

 

Bueno, esto es todo (que no es poco). Si estás interesado en seguir profundizando en este tema, te recomiendo que busques cuales son las buenas prácticas utilizadas por los profesionales de tu lenguaje de programación habitual. Suelen ser documentos gratuitos y de descarga pública como el escrito por Submain para .NET o el de Oracle para Java.

Esther Claravalls
Sígueme en

Esther Claravalls

Ingeniera. Profesionalmente vinculada a la informática industrial y a la creación de proyectos web. Buscadora incansable de conocimiento por el puro placer de aprender.
Esther Claravalls
Sígueme en

Latest posts by Esther Claravalls (see all)

Uso de cookies

Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando estas dando tu consentimiento para la aceptación de las mencionadas cookies y la aceptación de lapolítica de cookies, pincha el enlace para mayor información.

ACEPTAR

Pin It on Pinterest

Share This