Comprobar condiciones de las que ya sabes el resultado. Ejemplo: comprobar que al convertir algo a string el resultado es el que nos interesa y posteriormente comprobar que ese algo no era null. Si hubiese sido null la conversión a string habría sido algo más problemática, ¿no?

if (!(Session["blabla"].ToString() == ""))
    if (!(Session["blabla"] == null))
        [...]

Hacer la comprobación en el orden inverso habría tenido un cierto sentido (aunque en este ejemplo concreto nunca iban a ser null). Un día de estos me voy a cortar las venas si sigo viendo estas cosas. ¿Y lo bonito que es el símbolo != que es más dificil de confundir? ¿Dónde ha quedado?

Además esta está directamente relacionada con mi última queja de cascarrabias. En otro de los proyectos con los que estaba trabajando, un método de una librería recibía una serie de parámetros y, si alguna no era lo que esperaba, devolvía una ArgumentException.

En el código desde el que se llamaba a las funciones de esta librería había una serie de llamadas dentro de un try-catch, por lo que el primero que fallaba impedía que se ejecutaran los demás. Dado que todas estas llamadas dependían directamente de datos introducidos por el usuario, las posibilidades de que alguna no pudiera terminar estaban prácticamente aseguradas.

Ahora los métodos de esa librería tratan de manejar la situación excepcional como buenamente pueden y, de no ser capaces de hacerlo, optan por terminar con un simple return (porque tampoco me voy a inventar los datos si el usuario no los ha metido). No es una solución muy elegante pero para este caso nos vale, ya que sólo afectaba a una base de datos de búsquedas internas.

Deberían prohibir usar excepciones a según que personas… De todas formas yo siempre he sido muy maniático con la programación utilizando excepciones, y siempre me ha gustado gestionarlas en la capa en la que son susceptibles de generarse, sin andar propagándolas hacia arriba en ningún caso. Pero para opiniones colores…

Aplicación de línea de comandos en C#, nada más abrir la solución veo esto:

static void Main(string[] args) {
    if (args.Length != 1) {
        throw new Exception("Parámetros de entrada incorrecto. Se esperaba 1 y se han recibido " + args.Length);
}
[...]

Si sales de la aplicación con una excepción lo único que consigues es un molesto “La aplicación ha detectado un problema y debe cerrarse. Sentimos los inconvenientes ocasionados” y el botoncito de “enviar informe de errores” y demás.

Las excepciones (aparte de que no están para estas cosas, esto es una condición de la aplicación perfectamente predecible y tratable) se deben tratar y resolver dentro de la aplicación, e incluso si no se saben resolver, se debería salir de la aplicación de un modo completamente controlado.

Sigo con el tema con el que estaba el otro día, cambiando código obsoleto por cosas más legibles y/o más rápidas (aunque lo cierto es que las expresiones regulares pueden llegar a ser bastante poco legibles, especialmente si no estás acostumbrado a utilizarlas (o, como yo, no te acuerdas)).

Para normalizar un montón de textos, aplicamos algunos patrones para eliminar los molestos símbolos en los que se transforman las Ñ’s en otros sistemas de software, por ejemplo almohadillas, diéresis, el símbolo del yen, etc.

// Sustituimos  símbolo raro + vocal
// por "Ñ" + vocal
// Simbolo raro = {blackslash, almohadilla, yen, dieresis}
salida = Regex.Replace(salida, @"[#\\¥¨](?<vocal>[AEIOU])", "Ñ${vocal}");

Una aparición de los símbolos (doble barra invertida para escapar el carácter), seguido de una vocal, lo cambiamos por una Ñ seguida de la misma vocal. La ‘memoria’ antes y después de la aplicación de la expresión regular se consigue con la utilización de ?<nombre> en el patrón de reconocimiento y ${nombre} en el patrón de salida.

Una cosa interesante es que realmente estamos escapando el símbolo de la barra invertida dos veces, una al duplicarla y otra al comenzar el string con una arroba. Así lo escapamos en el entorno de programación y lo volvemos a escapar cuando la cadena llega al motor de expresiones regulares. Esto es lo que me llevó algo más de tiempo para darme cuenta, el resto se solucionó con una rápida petición de ayuda por Messenger a S., que ya me ha estado echando una mano con un par de dudas relacionadas con los css de esta web.

Estoy reescribiendo una librería bastante desactualizada, en la que aparentemente han metido mano muchas personas diferentes. Se manejan una serie de strings que hay que “estandarizar” antes de comprobar si son válidos o no, y uno de los métodos que estaban implementados era:

/// <summary>
/// Función auxiliar que se le pasa una cadena y elimina todos los caracteres
/// blancos duplicados entre palabras.
/// </summary>
static public string EliminaBlancos(string cadena);

El código era un horrendo bucle que iba buscando sucesivas apariciones de dobles espacios y… en fin (y usando strings en lugar de StringBuilder, por si fuera poco). Obviamente este tipo de cosas pueden hacerse bastante rápido con expresiones regulares, pero como nunca suelo utilizarlas he tardado un rato en recordar cómo iban, así que aquí lo dejo apuntado por si es útil para alguien:

output = Regex.Replace(input, @"\s+", " ");

Y hemos cambiado trece líneas del código original por sólo una.

\s detecta espacios en blanco (dependiendo del motor de expresiones regulares, suele ser blancos, tabuladores y saltos de línea por ejemplo).

+ indica que hay una o más repeticiones del elemento precedente.

Recordad que la clase Regex está en:

using System.Text.RegularExpressions;

Más información en la wikipedia, claro.