Practicas de programacion: Nunca digas nunca

Recientemente Jan Bannister escribio este post Bool considerado dañino, donde escribe (traducido):

Nunca uses Bool, o mas especificamente nunca uses bool como parametro. Es el tipo de dato mas tonto y que provee la menos informacion posible.

Pues bien, podria debatir el post de varias maneras, pero lo que me llego fue eso de "nunca uses bool como parametro"; los problemas mas grandes con eso que veo son:

•  Tus proyectos terminarian con cientos de enums para reemplazar los parametros buleanos (asi se escribe booleans?).
• Donde pones todos esos enums?
• En algun punto del proyecto, tendrias tantos enums que tal vez algunos de ellos estarian duplicados, y se te haria un desorden para saber si debes aumentarle a un enum, o crear uno nuevo.

Entonces que hacemos? de alguna manera el tipo bool si es dañino, pero no siempre, yo creo que esa es la clave, puedo pensar rapidamente en al menos 3 escenarios donde no necesariamente necesitas reemplazar tus bools con enums:

• metodos privados: se supone que son usados solamente por clase misma... y que el metodo no es tan grande, y que la clase no es tan grande, y que tienes comentarios verdad?
• metodos con un solo parametro que solo es algo que prendes o apagas, por ejemplo PonerVisibilidad(true);
• Aun en metodos con varios parametros tambien se puede usar con variables con nombres claros que indiquen su proposito y no se presten a confusion, hay muchos ejemplos de esos, pero si eviten llamar sus variables, x, i, j, k, etc... porque entonces no importa si el parametro es bool o no, el codigo sera mas dificil de entender

y bien, ya no suena tan mal, a final de cuentas, nunca digas nunca, no abuses de ninguna tecnica.

C# trivia #1: overloads, strings, nullable types

esta entrada sirve a la vez para probar el mas reciente Windows Live Writer

Tenemos estas clase:

public class Foo {
public void Bar(string x) {
Console.WriteLine("string x was called");
}
public void Bar(int? x) {
Console.WriteLine("int? x was called");
}
}

cual sera la salida a la consola con el siguiente codigo:

Foo f = new Foo();
try {
f.Bar(null);
}
catch {
Console.WriteLine("no method was called");
}

Filemon salva el dia una vez mas

Estoy de regreso, me lastime la cabeza en un juego de futbol, me la pase muy mareado por mas de una semana, pero ya estoy bien

Esta vez fue un control ActiveX (todavia estamos peleando con controles ActiveX), pense que ya habia hecho todo para que funcionara, pero aun asi el #@$^ control simplemente no funcionaba, asi que corri Filemon para ver si el archivo era siquiera accesado, y encontre 2 referencias al archivo, una en el folder del GAC, y otra en program files\internet explorer, pero ninguna referencia a donde yo habia copiado el dll.

Asi que decidi copiar el archivo dll a donde IE lo estaba buscando, lo puse en
c:\program files\Internet Explorer\
y todo empezo a funcionar perfectamente

Talez pude haber registrado el control en el GAC, pero ya estaba muy frustrado (tenia varios dias con este problema) y creo que ya habia tratado antes eso mismo y no me habia funcionado.

pero bueno... pues ahi tienen otro truco mas que pueden intentar cuando ya hallan intentado todo lo demas, usa filemon para ver de que directorio esta tratando IE de cargar tu control, y copialo ahi

y si aun no sabes que es filemon, deberias bajarlo y jugar con el, es una herramienta mas que excelente, y te ahorrara muchos dolores de cabeza (y no precisamente de los causados en juegos de futbol J)

salu2