DEV Community

Cover image for C#: IDE, por favor, no me "ayudes" más...
Baltasar García Perez-Schofield
Baltasar García Perez-Schofield

Posted on • Updated on

C#: IDE, por favor, no me "ayudes" más...

A lo largo del tiempo, me he especializado como profesor de programación, y por lo tanto me fijo mucho en cómo los alumnos interaccionan con las herramientas que utilizamos en el aula. Aunque los propios lenguajes de programación han mejorado muchísimo en cuanto a expresividad y detección de errores, la herramienta que mñas ha avanzado es sin duda el IDE (Integrated Development Environment), o Entorno Integrado de Desarrollo.

Y no, este no es uno de esos textos en el que el profesor se queja de que los alumnos le llaman aduciendo que "no funciona", sin siquiera leer el mensaje de error que proporciona el IDE o incluso el propio lenguaje de programación. (Por cierto, en estos casos lo mejor es continuar el diálogo con "Eso es porque está mal.", copiando el estilo de mensaje conciso y desprovisto de toda información... Y a partir de ahí, guiarle hacia la lectura del mensaje de error.)

Mi queja se refiere más bien a esos subrayados en rojo. Seguramente, si este fuera un artículo en inglés lo habría tenido que titular más bien como: "IDE syntax hints considered harmful". Según parece, todos los escritores en habla inglesa deben aspirar a emular a Dijkstra...

Bueno, ¿cuál es el problema? Que cuando el alumno se encuentra con un subrayado en rojo, en lugar de posar el cursor del ratón encima y leer (y entender ), el mensaje de error, entran en un modo frenético-ansioso de manera que la única forma de volver a la normalidad sea hacer que el subrayado desaparezca. Como sea.

Supongamos, por ejemplo, que tenemos una clase Calificacion.

public class Asignatura {
    public Asignatura(string nombre)
    {
        this.Nombre = nombre;
    }

    public string Nombre { get; }
}

public class Calificacion {
    public Calificacion(Asignatura asigantura, decimal nota)
    {
        this.Asignatura = asigantura;
        this.Nota = nota;
    }

    public decimal Nota { get; }
    public Asignatura Asignatura { get; }
}
Enter fullscreen mode Exit fullscreen mode

Esta clase puede utilizarse de esta manera:

var asig = new Asignatura( "Matracas" );
var nota = new Calificacion( asig, 7.8m );

Console.WriteLine( $"{nota.Asignatura.Nombre}: {nota.Nota}" );
Enter fullscreen mode Exit fullscreen mode

Supongamos ahora que queremos darle a la clase Calificacion el método Calificacion.CompareTo(c2). Esto implica que la clase Calificacion implemente la interfaz IComparable, de una forma similar a lo siguiente:

public class Calificacion: IComparable<Calificacion> {

¿Cuál es el problema? Pues que en cuanto tecleemos el último '>', la declaración de la clase Calificacion será subrayada en rojo. Lo hace porque a la clase le falta el método CompareTo(c2). Y le falta porque... la clase implementa la interfaz IComparable<>. Esto es una pescadilla que se muerde la cola: no "puedo" hacer una cosa sin hacer la otra... pero seguro que no puedo hacer las dos cosas a la vez.

La única solución que se me ocurre es crear el método antes que la declaración:

class Calificacion {
    // ...
    public int CompareTo(Calificacion? otra)
    {
        int toret = -1;

        if ( otra != null ) {
            if ( this.Nota == otra.Nota ) {
                toret = 0;
            }
            else
            if ( this.Nota < otra.Nota ) {
                toret = 1;
            }
        }

        return toret;
    }
}
Enter fullscreen mode Exit fullscreen mode

Y después indicar que implementa IComparable<>. Muy incómodo e improbable acordarse.

Continua...

Top comments (0)