BASES GENERALES

Bueno, lamento tener que comunicarte que todavía no podemos empezar con el lenguaje C# propiamente dicho (ya me gustaría, ya). Antes quiero comentarte un poco cómo funciona todo esto, más que nada para que te hagas una idea clara de cómo funcionará un programa hecho en C#.

EL MUNDO .NET

Realmente, el concepto de .NET es demasiado amplio, así que trataré de resumirlo en unas pocas palabras. Vamos a ver; hasta ahora, lo que conocemos de Internet y la informática es que cada uno de los dispositivos, cada uno de los programas y cada una de las páginas Web están completamente separadas del resto desde el punto de vista funcional. Sí, sí, hay vínculos de unas páginas a otras y cosas de estas, pero eso, para que me entiendas, es como leer un libro y mirar las notas al pie de página; para acceder a la fuente de esas notas tienes que ver otro libro. El objetivo de la plataforma .NET es que todos estos dispositivos y todas estas páginas trabajen de un modo conjunto, ofreciendo así una información mucho más útil a los usuarios. Sería como si un libro en lugar de tener notas a pie de página tuviera dentro de él todos los otros libros a los que hace referencia y el lector pudiera extraer de todos ellos cualquier cosa que necesitara, sin necesidad de tener que buscar manualmente cada uno de ellos. Fascinante, ¿no?

.NET está formado por cuatro componentes principales, pero lo que nos interesa aquí es una parte de la infraestructura .NET, en la que están encuadrados tanto Visual Studio.NET como el .NET Framework.

El .NET Framework está compuesto por el CLR (Common Language Runtime) y la biblioteca de clases del .NET Famework. El CLR es un entorno de ejecución en el que aplicaciones escritas en diferentes lenguajes pueden trabajar juntas, es decir, puedes crear una clase en C#, derivar de ella otra en C++ e instanciar un objeto de esta en Visual Basic. No, no me digáis que venga ya. Es cierto. Esto se consigue a través de lo que se denomina código gestionado, es decir, el código que se ejecuta bajo el CLR está siendo gestionado por éste, independientemente del lenguaje en el que se haya escrito. No, no se trata de un intérprete, ni de un intermediario. Se trata de que el código gestionado asegura que se cumplen una serie de reglas para que todas las aplicaciones se comporten de un modo uniforme. ¿Y se pueden crear compiladores de código gestionado por el CLR para otros lenguajes? Sí, de hecho ya hay varios o, al menos, se tenía la intención de hacerlos, además de los que se incluyen con Visual Studio .NET. Todo lo que tienen que hacer estos compiladores es ajustarse a las reglas del CLS (Common Language Specification), pero eso es para los que diseñan compiladores, o sea que, de momento, tú y yo podemos olvidarnos del tema.

La biblioteca de clases del .NET Framework es, como su propio nombre indica, una biblioteca de clases... (Vaya descubrimiento, ¿eh?) Vaaaale... me explicaré mejor. Si has programado en C++ conocerás la MFC (Microsoft Foundation Classes), o la OWL de Borland (Object Windows Library). Si no eres programador de C++ y/o no las conoces, pues me has hecho la puñeta... A volver a empezar. Veamos, la biblioteca de clases del .NET Framework te ofrece un conjunto de clases base común para todos los lenguajes de código gestionado. O sea, si, por ejemplo, quieres escribir algo en la pantalla, en Visual Basic sería así:

Console.WriteLine(“Algo”)

En C# sería así:

Console.WriteLine(“Algo”);

En C++ gestionado sería así:

Console::WriteLine(“Algo”)

Como ves, es igual (o casi igual) en todos los lenguajes. En C++ hay que poner :: en lugar de un punto por una cuestión meramente sintáctica propia de este lenguaje para separar el nombre de una clase de uno de sus miembros. Ojo, no quiero decir que todos los lenguajes sean iguales, no, sino que todos usan la misma biblioteca de clases o, dicho de otro modo, todos usan las mismas clases de base. Ya sé, ya sé: ahora estaréis pensando que, si esto es así, todos los lenguajes tienen la misma capacidad. Bueno, pues es cierto, aunque sólo relativamente, pues no todos los lenguajes implementan toda la biblioteca de clases completa, ya que basta con que el compilador se ajuste a los mínimos que exige el CLS.

Por otro lado, la compilación de un programa gestionado por el CLR no se hace directamente a código nativo, sino a un lenguaje, más o menos como el ensamblador, llamado MSIL (Microsoft Intermediate Language). Después es el CLR el que va compilando el código MSIL a código nativo usando lo que se llaman los compiladores JIT (Just In Time). Ojo, no se compila todo el programa de golpe, sino que se van compilando los métodos según estos se van invocando, y los métodos compilados quedan en la caché del ordenador para no tener que compilarlos de nuevo si se vuelven a usar. Hay tres tipos de JIT, pero ya los trataremos más adelante, pues creo que será más oportuno. ¿Se trata entonces de lenguajes compilados o interpretados? Pues me has “pillao”, porque no sabría qué decirte. No es interpretado porque no se enlaza línea por línea, y no es compilado porque no se enlaza todo completo en el momento de ejecutar. Llámalo x.

BASES SINTÁCTICAS DE C#

Ahora sí, ahora por fin empezamos a ver algo de C#. Agárrate bien, que despegamos.

Si vienes de programar en otros lenguajes basados en el C, como C++ o Java, o incluso en el propio C, te sentirás cómodo enseguida con C#, ya que la sintaxis es muy parecida. Si vienes de programar en otros lenguajes de alto nivel, como Visual Basic, Delphi, PASCAL o COBOL, por ejemplo, o incluso si no conoces ningún lenguaje de programación, no te dejes asustar. Leer y entender programas escritos en alguno de estos últimos lenguajes es algo bastante fácil, incluso si no habías programado nunca. Sin embargo, leer programas hechos en C, C++, Java o C# puede resultar muy intimidatorio al principio. Encontrarás llaves por todas partes, corchetes, paréntesis, operadores extraños que nunca viste en otros lenguajes, como |, ||, &, &&, !, !=, = =, <<, >>, interrogantes, dos puntos, punto y coma y cosas así. Incluso verás que algunas veces la misma instrucción parece hacer cosas completamente distintas (aunque en realidad no es así). Ya no te quiero contar cuando escribas tu primer programa en C#: posiblemente tengas más errores que líneas de programa. Sin embargo, repito, no te dejes asustar. Aunque es un poco confuso al principio verás cómo te acostumbras pronto. Además, el editor de Visual Studio.NET te ayuda mucho a la hora de escribir código, ya que cuando detecta que falta algo o hay alguna incoherencia te subraya la parte errónea en rojo o en azul, tal y como hace el MS-Word, por ejemplo, cuando escribes una palabra que no tiene en el diccionario ortográfico, o cuando lo escrito es incorrecto gramaticalmente.

Como decía, la sintaxis de C# es muy parecida a la de C, C++ y, sobre todo, Java. Para diseñar este lenguaje, Microsoft ha decidido que todo lo que se pudiera escribir como se escribe en C era mejor no tocarlo, y modificar o añadir únicamente aquellas cosas que en C no tienen una relativa equivalencia. Así, por ejemplo, declarar una variable o un puntero en C# se escribe igual que en C:

int a;

int* pA;

No obstante, hay que prestar atención especial a que, aunque un código sea sintácticamente idéntico, semánticamente puede ser muy distinto, es decir: mientras en C la una variable de tipo int es eso y nada más, en C# una variable de tipo int es en realidad un objeto de la clase System.Int32 (ya dijimos en la introducción que en C# todo es un objeto salvo los punteros). En resumen, las diferencias más importantes entre C y C# no suelen ser sintácticas sino sobre todo semánticas.

Bien, una vez aclarado todo esto, podemos seguir adelante. Primera premisa: en C# todas las instrucciones y declaraciones deben terminar con ; (punto y coma), salvo que haya que abrir un bloque de código. Si programas en Pascal o Modula2 dirás: “Hombre, claro”, pero si programas en Visual Basic no te olvides del punto y coma, pecadorrrrrr. ¿Por qué? Porque, al contrario que en Visual Basic, aquí puedes poner una instrucción que sea muy larga en varias líneas sin poner ningún tipo de signo especial al final de cada una. Es cuestión de cambiar el chip. Fíjate en esta simulación:

A = Metodo(argumento1, argumento2, argumento3, argumento4

       argumento5, argumento6, argumento7, argumento8);

El compilador entiende que todo forma parte de la misma instrucción hasta que encuentre un punto y coma.

¿Y qué es un bloque de código? Pues vamos con ello. Un bloque de código es una parte del mismo que está "encerrado" dentro de algún contexto específico, como una clase, un método, un bucle... Veamos un ejemplo muy significativo. El siguiente fragmento de código es una función escrita en Visual Basic:

Public Function EsMayorQueCero(numero as Integer) as Boolean

    If numero > 0 Then

    EsMayorQueCero = True

    End If

End Function

En esta función podemos encontrar dos bloques de código: el primero de ellos es todo el que está dentro del contexto de la función, es decir, entre la línea donde se declara la función (Public Function EsMayorQueCero...) y la línea donde termina dicha función (End Function). El otro bloque está dentro del contexto del If, y está compuesto por la única línea que hay entre el principio de dicho contexto (If numero > 0 Then) y la que indica el final del mismo (End If). Por lo tanto, como puedes ver, en Visual Basic cada bloque empieza y termina de un modo distinto, dependiendo de qué tipo de bloque sea, lo cual hace que su legibilidad sea muy alta y sencilla. Veamos ahora su equivalente en C# (y no te preocupes si no entiendes el código, que todo llegará):

public bool EsMayorQueCero(int numero)

{

    if (numero>0)

    {

        return true;

    }

    return false;

}

En este caso, los bloques de código están muy claramente delimitados por las llaves, pero como puedes apreciar, ambos bloques están delimitados del mismo modo, es decir, ambos se delimitan con llaves. Además, fíjate en que detrás de la línea en que se declara el método no está escrito el punto y coma, igual que en el if, lo cual quiere decir que la llave de apertura del bloque correspondiente se podía haber escrito a continuación, y no en la línea siguiente. Según está escrito, es fácil determinar cuáles son las llaves de apertura y cierre de un bloque y cuáles las del otro. Sin embargo, si hubiésemos quitado las tabulaciones y colocado la llave de apertura en la misma línea, esto se habría complicado algo:

bool EsMayorQueCero(int numero) {

if (numero>0) {

return true;

}

return false;

}

Si, además, dentro de este método hubiera tres bucles for anidados, un switch, dos bucles While y cuatro o cinco if, unos dentro de otros, con algún que otro else y else if, pues la cosa se puede convertir en un galimatías de dimensiones olímpicas. De ahí la importancia de tabular correctamente el código en todos los lenguajes, pero especialmente en los lenguajes basados en C, como el propio C, C++, Java y C#, ya que así será fácil ver dónde empieza y dónde termina un bloque de código. Digo esto porque, a pesar de que Visual Studio.NET pone todas las tabulaciones de modo automático, siempre puede haber alguno que las quite porque no le parezcan útiles. ¡NO QUITES LAS TABULACIONES! ¿Cómo? ¿Que podría haber abreviado mucho el código en este ejemplo? Sí, ya lo sé. Pero entonces no habríamos visto bien lo de los bloques. Un poco de paciencia, hombre...

Los programas escritos en C# se organizan en clases y estructuras, de modo que todo el código que escribas debe ir siempre dentro de una clase o bien de una estructura, salvo la directiva using. Por eso las funciones ahora se llaman métodos, porque serán métodos de la clase donde las pongas, y las variables y constantes (dependiendo de dónde se declaren) pueden ser propiedades de la clase. Los que no sepáis qué es una función, una variable o una constante no os preocupéis, que lo veremos a su debido tiempo.

En cada aplicación que escribas en C# debes poner un método llamado Main, que además ha de ser public y static (veremos estos modificadores más adelante). No importa en qué clase de tu aplicación escribas el método Main, pero quédate con la copla: en todo programa escrito en C# debe haber un método Main, pues será el que busque el CLR para ejecutar tu aplicación. A partir de aquí, lo más aconsejable es escribir el método Main en una clase que se llame igual que el programa más las letras App. Por ejemplo, si es una calculadora, lo más recomendable es situar el método Main en una clase que se llame CalculadoraApp. Ahora bien, recuerda que esto no te lo exige el compilador, así que si pones el método Main en cualquier otra clase el programa funcionará.

Otra cosa importante a tener en cuenta es que C# distingue las mayúsculas de las minúsculas, de modo que una variable que se llame “Nombre” es distinta de otra que se llame “nombre”, y un método que se llame “Abrir” será distinto de otro que se llame “abrir”. Adaptarte a esto será lo que más te cueste si eres programador de Visual Basic. No obstante, verás que tiene algunas ventajas.

C# soporta la sobrecarga de métodos, es decir, que puedes escribir varios métodos en la misma clase que se llamen exactamente igual, pero recuerda que la lista de argumentos ha de ser diferente en cada uno de ellos, ya se diferencien en el número de argumentos o bien en el tipo de dato de dichos argumentos. Esto es algo que Visual Basic.NET también soporta (por fin), pero no sucedía así en las versiones anteriores de dicho lenguaje.

También soporta la sobrecarga de operadores y conversiones definidas por el usuario. Esto quiere decir que cuando diseñes una clase puedes modificar el comportamiento de varios de los operadores del lenguaje para que hagan cosas distintas de las que se esperan, y quiere decir también que si usas una clase diseñada por otro programador, uno o varios operadores pueden estar sobrecargados, por lo que es conveniente revisar la documentación de dicha clase antes de empezar a usarla, no sea que le intentes sumar algo, por ejemplo, y te haga cualquier cosa que no te esperas. De todos modos, cuando lleguemos al tema de la sobrecarga de operadores te daré algunos consejos sobre cuándo es apropiado usar esta técnica y cuándo puede ser contraproducente.

En C# no existen archivos de cabecera ni módulos de definición, así que, si programabas en C o C++, puedes olvidarte de la directiva #include cuando cuente tres: uno...dos...tres ¡YA! Si programabas en MODULA 2, puedes aplicarte el cuento con el FROM ... IMPORT, aunque esta vez no voy a contar. Si programabas en otro lenguaje no me preguntes, que no tengo ni idea. Si no sabías programar en ningún lenguaje, mejor que no te olvides de nada, que si no la liamos. En lugar de esto tenemos algo mucho más fácil y manejable: los espacios de nombres, de los cuales hablaremos en la próxima entrega.

Para terminar, puedes poner los comentarios a tu código de dos formas: // indica que es un comentario de una sola línea. /* ... comentario ... */ es un comentario de una o varias líneas. Observa el ejemplo:

// Esto es un comentario de una única línea

/* Esto es un comentario que consta de

varias líneas */

Para esta entrega no hay ejemplos... Lo siento,