El sufrimiento de los lenguajes interpretados...
Un lenguaje interpretado es un lenguaje de programación que está diseñado para ser ejecutado por medio de un intérprete, en contraste con los lenguajes compilados. Teóricamente, cualquier lenguaje puede ser compilado o ser interpretado, así que esta designación es aplicada puramente debido a la práctica de implementación común y no a alguna característica subyacente de un lenguaje en particular.
Por todos es sabido que el Fox era un lenguaje interpretado hasta el punto de que nuestros programas podían generar código y compilarlo al vuelo. Así como la macrosustitución. El problema era el elevado consumo de recursos de la máquina y por tanto la lentitud de ciertas partes de nuestras aplicaciones.
Por todos es sabido que el Fox era un lenguaje interpretado hasta el punto de que nuestros programas podían generar código y compilarlo al vuelo. Así como la macrosustitución. El problema era el elevado consumo de recursos de la máquina y por tanto la lentitud de ciertas partes de nuestras aplicaciones.
A C Sharp le sucede exactamente lo mismo, y por lo tanto tenemos que invertir tiempo en la optimización de nuestro código si queremos que nuestras aplicaciones no desesperen a la gran mayoría de usuarios que tienen máquinas obsoletas pero funcionales.
La principal ventaja de un lenguaje interpretado es que es independiente de la máquina y del sistema operativo ya que no contiene instrucciones propias de un procesador sino que contiene llamadas a funciones que el interprete deberá reconocer. Basta que exista un interprete de un lenguaje para dicho sistema y todos los programas escrito en ese lenguaje funcionarán.
La principal ventaja de un lenguaje interpretado es que es independiente de la máquina y del sistema operativo ya que no contiene instrucciones propias de un procesador sino que contiene llamadas a funciones que el interprete deberá reconocer. Basta que exista un interprete de un lenguaje para dicho sistema y todos los programas escrito en ese lenguaje funcionarán.
Aquí os marco algunas reglas del juego para que vuestro código esté optimizado y sea estéticamente bello:
- Al igual que en Fox en C# debemos usar string.Empty en lugar de "", mucho mejor (Nombre == string.Empty) que (Nombre = "").
- Si queremos obtener del switch toda la potencia del DO CASE de foxpro debemos utilizar enumeraciones. (A esto le dedicaré un capítulo entero para explicarlo.)
- No introducir código en los eventos, hacedlo en un método a parte y llamarlo desde el método asociado al evento. Esto lo veremos en otro capítulo.
- No gestionar la apertura y cierre de los formularios desde el mismo formulario, hay que hacerlo desde una clase externa.
- Usa ficheros de recursos para todos los literales de la aplicación, ya sabéis los de tipo .resx, el que no entienda que no se preocupe que lo iré detallando todo.
- Evita tener archivos de más de 1000 líneas, si sucede refactoriza. Divididlos en varias clases.
- Evita métodos y propiedades públicas en las clases si no es necesario. Usa internal si son únicas del mismo ensamblado.
- No crees métodos con más de 5 parámetros, para ello crea una clase o estructura. Los parámetros destrozan la memoria, crean la posibilidad de que los datos se corrompan, y crean más ciclos de microprocesador.
- No utilices null como retorno de un método. Por ejemplo si tenemos una lista es preferible retornarla vacía.
- Usa el archivo AssemblyInfo para documentar tu aplicativo.
- Cuando abras conexiones (bases de datos, flujos de archivo, sockets, etc.), gestionalas con un try/catch y ciérralas en el bloque finally.
- Igual que antes hemos mencionado como evitar los string con enumeradores, cuandos tengas que gestionar varios string utiliza la clase StringBuilder .
- Usa en tus aplicaciones siempre una arquitectura multicapa, esto lo veremos en capítulos posteriores.
- Si apuestas por Microsoft no utilices tecnologías de terceros, ya que estos terceros nunca van a conocer la estratégia de Microsoft.
- Separa todas la clases no principales o de apoyo (validaciones, archivos de recursos, constantes, logger, etc.) en otros ensamblados, librerías.
- No abuses de los web services, son un modelo que consume mucho. No hay que utilizarlos para conectar procesos internos.
- No dudes a la hora de hacer uso de las herramientas del Visual studio, están ahí para hacernos la vida más fácil.
- No escribas rutinas try/catch en todos tus métodos, ni dejes que los bloques introducidos en el try sean muy grandes.
