Tecnocracia.net

Lua: El poder de Brazil en la programación

Mientras revisaba en Barrapunto me encuentro con un link a un artículo de debug_mode=ON introductorio al lenguaje Lua. Este lenguaje ha sido utilizado en nmap y en juegos como WoW para la customización de la Interfaz.

Lo que más llama su atención es la procedencia de este lenguaje proveniente desde la Universidad católica de Río de Janeiro en Brasil, esto nos viene a demostrar el poder del Open Source que elimina las fronteras permitiendo que el software se mida por la calidad independientemente de su procedencia.

Link: [debug_mode=ON] Introducción a Lua.

Tags: brasil, links, lua, programación

Libros que leo - Steve McConnell

El estar titulado y el estar trabajando no significa que te sabes la última chupada del mate (que viejo dicho) ni que seas un megagurú ni nada por el estilo. Lo que si ayuda es la lectura de libros escritos por gente con mucha experiencia y mejor aún conocimiento y expertise (ya explicaré en otro post por qué lo último es más valorado).

Dentro de ellos, uno de los que estoy leyendo actualmente es Steve McConnell. Estoy terminando Code Complete en su segunda edición. Nunca tuve la oportunidad de leer la primera, pero es un libro muy ilustrativo que presenta muy buenas prácticas de desarrollo de software en diversos puntos de vista, pero enfocando principalmente a la construcción de software. Aún así es un libro recomendado no sólo para programadores, sino también para jefes de proyecto, líderes técnicos y gerentes asociado a las áreas tecnológicas.

Otro libro que recién llegó a mi hogar ha sido Rapid Development, el cual de lo poco que leido, está orientado a las buenas prácticas del desarrollo de software que ayudan a hacerlo de una forma más óptima. Pero sin fórmulas mágicas, siendo bien realista y estableciendo los distintos trade-off que pueden existir al tomar decisiones como velocidad de desarrollo v/s calidad del software. Ofrece varios casos de ejemplo para establecer el puente entre la filosofía y la práctica.

Steve McConnell tiene también un blog en el cual habla de los distintos aspectos relacionados con el desarrollo de software en todos los niveles

Tags: buenas prácticas, Code Complete, Desarrollo de Software, Ingeniería de Software, libros, programación, Rapid Development, Steve McConell

El problema de los estándares de códificación

No me malentiendan. ¡No estoy en contra de los estándares de codificación!. Pero hay que reconocer que son complicados de aplicar.

Donde estoy trabajando, estamos trabajando con un código compartido. Con distintas prácticas. Por un lado un veterano programador, adorador de Java y por otro lado uno no tan veterano, pero experto programador en C/C++. Ambos son Ingenieros muy secos, pero poseen formas de trabajo muy distintas. Y yo estoy al medio.

El primero, es tan adorador de Java que intenta aplicar la misma nomenclatura a C/C++. Esta bien, es una buena práctica, pero C/C++ ofrece ciertas facilidades que a veces imitar a Java no tiene sentido. Les doy un ejemplo, el escribir un archivo utilizando C estándar es bien simple. Solo hay que crear el puntero al archivo y luego para usar el archivo tenemos las siguientes funciones básicas:

• Abrir el archivo: fopen()
• Cerrar el archivo: fclose()
• Leer el archivo: fread(), fscanf(),fget(),fgets(), etc.
• Escribir el archivo: fwrite(), fprintf(), fput(), fputs(), etc.

Si quisieramos imitar el modelo Java en C/C++. Olvidando el tema de hacerlo solo con C, que se puede, pero su complejidad no lo justifica. En el caso de C++ tendríamos que implementar las clases similares a Java. Es decir: BufferedReader, InputStreamReader,  PrintWriter, BufferedWriter, FileWriter, etc. Además de la captura de excepciones. Cuando podría ser más fácil crear una sola clase que hiciera de Wrapper sobre las funciones estándar de C. Lo cual es similar a los objetos ifstream y ofstream de C++.

Por otra parte, el esquema de desarrollo de C/C++ hace que de repente aparezcan esos nombres de variables místicos. Como el clásico ejemplo del ciclo for que explica Kernighan y Ritchie:

int i, n = 10;
int a[10]:
for(i = 0; i<n; i++) a[i] = 3;

Ese tipo de código lo he visto muchas veces, nadie sabe que es i, ni n, ni mucho menos a (hasta son indistiguibles en prosa). i queda un poco claro, es un indice, pero ¿un indice de que? ¿bajo qué está normado?, n indica cantidad, pero ¿es la cantidad de elementos o el límite que se desea recorrer?, en el caso de a se pone más enredada la cosa, puede ser una lista de clientes, una lista de sueldos de empleados, una lista de valores asignados a un hardware específico. Sé que es rápido desarrollar así, pero diganme, ¿qué es más legible? ¿El código anterior o el siguiente?

int indiceEmpleado, numeroEmpleados = 5;
int sueldoEmpleados[numeroEmpleados];
int valorSueldoPorEmpleado = 3;

for(indiceEmpleado = 0; indiceEmpleado < numeroEmpleados; indiceEmpleado++)
{
sueldoEmpleados[i] = valorSueldoPorEmpleado;
}

Debo admitir que me tomó más tiempo escribir dicho loop, pero vale la pena, queda claro cuál es el objetivo, que valor es asignado. Podríamos seguir mejorando dicho loop, pero creo que captan la idea. No podemos basar una práctica de desarrollo guíandonos por estilos asociados a un lenguaje. Hay que ser un poco más prácticos y definir algún estándar general y luego tratar los temas específicos del lenguaje. Obviamente hay temas rescatables de cada lenguaje, tal como el uso de capitalización tipo Java o el agregar prefijos para distinguir los tipos de datos, las variables miembro de una clase del resto como se hace en Visual C++. Así entre otras, pero sin casarse con un determinado lenguaje.

Espero que donde estoy lleguen a un acuerdo. En otra ocasión hablaré de como los problemas de comunicación pueden contribuir a la duplicación de código y por consiguiente a la duplicación de código propenso a errores.

Tags: c, c/c++, estandarización, Ingeniería de Software, java, prácticas de codificación, programación, trabajo en equipo