Si vous n’êtes pas convaincu, allez lire ça http://www.skorks.com/2010/05/why-i-love-reading-other-peoples-code-and-you-should-too/

A mes débuts, je “singeais” les autres, je copiais/collais du code trouvé sur le Net, sans forcement comprendre tout ce qu’il faisait.
En général, je trouvais ce code sur des forums comme developpez.com, codes-sources ou The code project.
J’avoue qu’aujourd’hui, je consulte rarement les forums (à part celui de Ubuntu-FR, si vraiment je ne trouve pas l’info sur leur merveilleux wiki)

Le Web a évolué en 2.0. Stackoverflow en est un pur produit: c’est un “forum” que je conseille vivement pour trouver des solutions à vos problèmes.

Mais la meilleur façon d’apprendre, c’est encore de lire du code, du vrai, du brut.
Il n’y a pas de honte à ne pas être un “Shakespeare” du C#… certaines personnes écrivent des romans et d’autres des articles de magazines… on ne fait pas tous  le même boulot.

Mon vrai premier "ordinateur" a été un Amstrad CPC 6128, et pour jouer à un jeux... il fallait le coder en recopiant le listing du bouquin!

Aujourd’hui, le Web 2.0 vous offre un outil magique pour lire du code: j’ai nommé http://www.google.com/codesearch !
C’est devenu un reflex pour moi: quand je ne comprend pas une fonction, au lieux d’aller consulter la MSDN, je cherche du code qui exploite cette dernière.

A noter que cette magie n’existerai pas sans l’émergence de l’OpenSource. S’il y avait principalement que Sourceforge au début, vous pouvez maintenant héberger vos projets OpenSource sur de nombreux sites comme Google Code, Github, Bitbucket, Codeplex, etc.

Bien sûr, les blogs restent une bonne source d’information. En ce moment vous pouvez y voir pas mal d’article sur les “CoRoutine” avec une utilisation astucieuse du mot clé “yield”: http://www.codinginstinct.com/2010/06/sequential-async-using-coroutines.html

Si j’ai réussie à vous donner envie de lire, je vous conseille de regarder ceci.
J’ai découvert ce code lors de mon apprentissage de CQRS (cf GoogleGroups d’ALT.Net) et je le trouve très élégant (pas étonnant qu’on le trouve sur http://elegantcode.com/ )

Lire du code provenant d’autres langages peut aussi vous apporter beaucoup: ne restez pas enfermé dans vos habitudes, et regardez les pratiques des autres. C’est en cherchant quelque chose sur Google Code Search que je suis tombé sur le code suivant: http://www.google.com/codesearch/p?hl=en#LH6NMiZyrsw/trunk/src/documentpresenter.vala

Ça ressemble à du C#? Mais c’est du Vala. Le projet est un IDE, avec une architecture MVP (Model Vue Presenter) avec de l’injection de dépendance etc. Je le trouve très lisible, clair et concis.
Pour ceux qui ne connaissent pas Vala, regarder ici:  http://live.gnome.org/Vala/QuickIntroForCSharpProgrammers

En parlant d’autres langages, je vous conseille quand même d’éviter de lire du Brainfuck  je ne veux pas être responsable de votre autisme.

Je n’ai plus qu’a vous souhaitez bonne lecture Mais allez bronzer un peu quand même :p

C#4 ?

Romain a trouvé une citation un peu abusive mais qui m’est pourtant tout de suite venu à l’esprit concernant C#4 :

The dynamic keyword is going be abused so much… C# is on its way to becoming PHP.

Pour la petite histoire, je viens de passer 2 jours à coder du Javascript… coder?? Débuguer surtout!
Je ne sais pas si suis allergique aux langages dynamiques, mais ça me frustre au plus au point de ne pas savoir quel sont les membres que possède un objet, et de devoir le vérifier au Runtime…
J’ai passé 2h car j’ai fait une faute de frappe sur le nom d’un membre, ce qui ne plante pas, mais comme cela créer dynamiquement un nouveau membre avec ce nouveau nom, j’ai passé beaucoup de temps à comprendre pourquoi sa valeur était “null”.

C’est pour ça que les aspects “dynamiques” me font peur pour la maintenance des futures programmes C#4.
Ceci dit, le mot clé “var” existe déjà en C#3, et je n’ai pas vu quelqu’un en abuser (d’ailleurs, est-ce que la nouvelle version de Resharper suggère toujours de remplacer les types par des var ??!!).
Toujours pour diluer mes propos, il est vrai que dans la réalité on a besoin d’utiliser différents langages pour différents besoin, alors pourquoi ne pas tout réunir en un seul…
Mais j’aimerai éviter ça :

Parfois je me dit aussi que “C# is on its way to becoming C++“. Je n’ai pas beaucoup d’expérience en C++, et de ce fait j’ai parfois du mal à comprendre certains codes.
Mais j’ai surtout l’impression que les possibilités du langage sont tellement nombreuses, qu’on a pas 2 codes source C++ “dans la même prose”, ce qui devient vite difficile à lire. Pouvoir faire 1 chose de 10 manières différentes, n’est en mon sens pas un bon truc.

Mais en pratique, les nouvelles fonctionnalités de C# ne sont utilisées que par une “élite” qui a un besoin très précis. Dans mon travail actuel, les gens ne savent pas encore faire du Linq, et j’ai l’impression que je suis le seul a avoir VRAIMENT migrer sur C#3. Donc, avant que quelqu’un découvre les nouveautés de C#4 et en abuse….

Ah, si, il y en a 1… et c’est le genre de personne à faire une chose d’une certaine façon “juste parce que c’est possible”, si vous voyez ce que  je veux dire… et là, ça devient vraiment dangereux, et on fini par avoir du code incompréhensible car il a détourné une fonctionnalité de son but initial.

Je dois être vieux jeux, mais je préfère parfois la méthode “classique et lisible” même si elle est plus verbeuse. Pourtant, je me laisse séduire, et je deviens vite fan des méthodes d’extension et des expressions lambda. C’est comme si mes 2 personnalités entraient en conflit quand je me dit :

return toto??tata;
// ou
return toto!=null?toto:tata;
// ou
if(toto != null)
return toto;
else
return tata;

Il est clair que je préfère la première solution, mais on m’a défait fait la remarque :

euh, tu peux l’écrire avec le “if”, je trouve ça plus lisible.

Et oui, il faut aussi s’adapter au niveau de lecture de l’équipe.

Mais là, je ne parle que du langage C#, pas des possibilité de la VM ou du Framework. S’il est possible d’interagir entre .Net et Javascript, alors je suis aux anges, mais il existe sans doute d’autres moyens “peut être plus contraignant” que d’ajouter de la dynamicité dans le langage C#. (On génère bien des “stub” pour communiquer en COM !)

Mais au finale, je me laisse prendre au jeux, et finalement je suis fan des expressions lamdba, Linq, les méthodes d’extensions, juste parce que ça s’écrit plus rapidement et que je suis fainéant.

Oxygene ?

Parce que je suis bavard, je voulais en profiter pour parler non pas de C#, mais de Oxygene.

Un peu d’histoire : le créateur de Delphi a aussi été le créateur de C# : Anders Hejlsberg
Petit lien car ça ne fait pas de mal : Anders qui parle du future de C# (je sais, tout le monde l’a déjà vu).

J’ai commencer à coder en Delphi au Lycée (je ne compte pas les années Basic sous AsmstradCPC6128 ).
Delphi était magique à l’époque : langage Pascal Objet, IDE avec un puissant Designer pour application Windows, framework riche…

Puis le monde a évolué : Anders Hejlsberg a quitté Borland pour aller chez Microsoft.
A l’époque, Microsoft a voulu faire leur propre “Java” : J++.
Anders a commencer par travailler la dessus, mais Microsoft est entré en conflit avec Sun concernant ce J++, et c’est comme ça que .Net naquis.
Anders inventa alors C# pour l’occasion, et J++ fut porté sous .Net sous le nom de J#.

Les années noirs pour Borland ont commencé, les entreprises se tournant vers Microsoft et .Net.
Mais je suis resté à coder en Delphi 7 dans mon ancienne société, alors que .Net en était déjà à sa V2. Période de ma vie (en tant que codeur) très frustrante: pas de “foreach”, pas de “generics”, programmation par interface difficile, etc.

Pour Borland, ce fut de pire en pire : ils ont fini par migrer Delphi en .Net, et ont alors inclue le SDK de Microsoft .Net dans leur IDE… comme si Delphi en tant que langage était mort, et que “Delphi 2008″ ne servait surtout qu’à développer en C#. Sans compter les frameworks tel que VCL.Net en conflit avec ceux de .Net comme Winforms.

Je n’ai pas travaillé avec Delphi 2008, mais je l’ai un peu testé. Malgré de gros problème de performance, cet IDE était déjà 1000 fois mieux que VisualStudio : refactoring poussé, historique “à la svn” à chaque sauvegarde/innactivité d’un source, Designer plus sympa, etc.

Mais finalement, Borland a laissé son IDE à Codegear et la mort de Delphi semblait proche. C’est pour cela que mon ancienne société a choisi de passer de Delphi7 à VisualStudio/C#.

Puis, récemment en surfant, j’ai découvert Oxygene.

Et je me suis dit : “haha, la résurrection de Delphi?”
Ce langage est dérivé de Delphi (comme une nouvelle version en quelque sorte), possède toutes (?) les fonctionnalités du langage C#3 comme Linq, etc.
Mais il ajoute aussi son lot de nouveauté que j’adore :

• éviter les tests de nullité inutile :

if(truc.parent != null && truc.parent.parent != null)
toto = truc.parent.parent;
// devient
toto = truc:parent:parent;

• ne pas choisir entre un “for” et un “foreach” car on a besoin d’un compteur

Combien de fois ais-je du ajouter un compteur dans un foreach (et risqué d’oublier le ++) et au final me résigner à utiliser le bon vieux “for”. En Oxygene, le foreach peut gérer l’index :

for each u in Users index i do begin
// et on se sert de i

Maintenant, Oxygene fait du buzz sur le net… enfin surtout “Delphi Prism“.

Finalement, l’IDE de Codegear est abandonné, et Delphi Prism s’intègre à VisualStudio (utilisé comme une application Eclipse RCP).
On retrouve le langage Oxygene, mais aussi un certains nombre de framework pour pouvoir faire des applications multi-plateform à l’aide de Mono.
Et pour faire plaisir aux ex-Delphi-istes, le package inclue une API d’interoperabilité entre .Net et les applications pure Delphi Win32.
Pour plus d’infos : http://www.delphi.org/2008/10/delphi-prism/

Il ne me reste plus qu’à tester tout ça Est-ce que ça veut dire que je vais abandonné C# pour revenir flirter avec Delphi?

Rentrons dans le vif du sujet: qu’est-ce que ça donne du coté de mon application C#:

// on démarre la JVM avec mes bons arguments
MathiasJniCpp.JVMWrapper.InitJvm(new String[] { "-Djava.class.path=Mathias.Jni.Java.jar" });

// on créer un objet .Net qui wrappe l'objet Java
// en C++/CLI, le destructeur des classes CLI sert de méthode "Dispose"
using (MathiasJniCpp.MyJavaWrapper javaObject = new MathiasJniCpp.MyJavaWrapper())
{
// faire mumuse avec...
javaObject.People = "Mathias";
Console.WriteLine(javaObject.SayHello());
}

// on libère la JVM
JVMWrapper.ReleaseJvm();

MathiasJniCpp c’est le namespace de mon assembly c++/cli, j’en reparlerai plus tard.
On voit que je manipule une classe JVMWrapper qui me permet de charger une JVM (et de la libérer). J’utilise aussi une classe .Net codé en C++/CLI. En fait, je l’utilise comme un classe C#, ou VB.net etc. C’est une classe “classique” .Net avec des méthodes et des propriétés.

Point intéressant à souligner: pourquoi utiliser using?
Pour rappelle, il y a des mots-clefs en C# très lié au Framework (comme foreach) et using en fait partie. Il prend les objets qui implémente IDisposable et fait appelle à la méthode Dispose() à la fin du bloque. Comme ça, je suis sûr de libérer la classe du coté JVM quand j’en ai plus besoin.

Je ne vais pas montrer tout le code, car trop long et disponible ici.
Mais voici un aperçu de la classe C++:

#include "jni.h"
public ref class MyJavaWrapper
{
private:
  static jmethodID initMethodId;
  static jclass clazz;
  jobject obj;
public:
  /* initialisation des métadata Java/JNI, à voir plus tard */
  static void initJavaMetadata()
  { ... }

  /* une méthode de notre classe Java que l'on wrappe, expliqué aussi plus tard */
  String^ SayHello(String^ people)
  { ... }

  /* constructeur */
  MyJavaWrapper(void)
  {
    // histoire de récupérer toutes les métadatas nécessaires du coté Java
    MyJavaWrapper::initJavaMetadata();

    // construction d'une instance avec le constructeur par défaut
    this->obj = JVMWrapper::env->NewObject(MyJavaWrapper::clazz, MyJavaWrapper::initMethodId);
  }

  /* "destructeur" */
  virtual ~MyJavaWrapper(void)
  {
    JVMWrapper::env->DeleteLocalRef(this->obj);
  }
};

Je manipule le membre this->obj qui est tout simplement un “pointeur” sur notre objet java. En fait, c’est un jobject qui est un type définie dans "jni.h".
J’utilise la classe JVMWrapper qui me permet de communiquer avec la JVM, et je lui demande de créer un nouvel objet d’une certaine classe jclass avec un certain constructeur jmethodID et j’obtiens ainsi mon jobject.
Étant donnée que la classe et la méthode ne change pas, j’ai rendu ces données static.

Voyons maintenant ce que fait MyJavaWrapper::initJavaMetadata();:

/* initialise les metadata du coté Java */
static void initJavaMetadata()
{
  // si les métadata ne sont pas déjà récupérées...
  if(MyJavaWrapper::clazz == NULL)
  {
    MyJavaWrapper::clazz = JVMWrapper::env->FindClass("mathias/jni/java/MyJavaClass");
    MyJavaWrapper::initMethodId = JVMWrapper::env->GetMethodID(MyJavaWrapper::clazz, "<init>", "()V");
  }
}

C’est la dedans que j’obtiens une fois pour toute la représentation de la classe Java mathias.jni.java.MyJavaClass et la représentation de la méthode <init> avec en paramètre ()V.
Pour comprend le lien avec la classe, il n’y a pas trop de problème: c’est le fully qualified name avec des ‘/’ au lieu des ‘.’.
Mais en ce qui concerne la recherche d’une méthode, ça devient du charabia!!
En fait, <init> est une méthode un peu spéciale: c’est un constructeur.
Ensuite, on spécifie les arguments du constructeur que l’on cherche, et la on tombe sur une syntaxe barbare. Dans notre cas, on cherche le constructeur par défaut c’est à dire qui ne prend pas d’argument.
Mais pour mieux comprendre la syntaxe barbare, voyons d’autres exemples de méthodes:

JVMWrapper::env->GetMethodID(MyJavaWrapper::clazz, "setPeople", "(Ljava/lang/String;)V");

JVMWrapper::env->GetMethodID(MyJavaWrapper::clazz, "sayHello", "([Ljava/lang/String;Z;)I");

On retrouve cette syntaxe à beaucoup d’endroits, comme sous Eclipse par exemple. Pour plus d’explication voir la documentation officielle.

Si l’on veut maintenant appeler une méthode Java, on récupère sa représentation tout comme on le fait avec le constructeur, puis on l’invoque sur notre instance:

public ref class MyJavaWrapper
{
private:
  static jmethodID initMethodId;
  static jclass clazz;

  // notre représentation JNI de la méthode "sayHello"
  static jmethodID sayHelloMethodId;

  jobject obj;
public:
  /* initialisation des métadata Java/JNI */
  static void initJavaMetadata()
  { 
    /* initialisation de la classe et du constructeur, comme vu précédemment 
    [...]  */

    // on récupère la représentation de "sayHello"
    JVMWrapper::env->GetMethodID(MyJavaWrapper::clazz, "sayHello", "(Ljava/lang/String;)Ljava/lang/String");
  }

  /* sur l'appelle de cette méthode .Net, on fait appelle à la méthode Java */
  String^ SayHello(String^ people)
  {
    // j'utilise une classe spéciale pour convertir ma String^ .net en natif ou Java
    StringConverter peopleStringConverter(people);
    jstring jPeople = peopleStringConvert.toJava();

    // appelle de la méthode Java, j'ai le droit de caster en jstring car c'est un sous-type de jobject
    jstring jResult = (jstring)JVMWrapper::env->CallObjectMethod(this->obj, sayHelloMethodId, jPeople);

    // conversion du type Java en .Net
    StringConverter resultStringConvert(jResult);
    return resultStringConvert.toDotnet();
  }
};

Voila, maintenant vous savez:

• obtenir la représentation d’une classe Java
• obtenir la représentation d’une méthode d’une classe
• créer une instance d’une classe Java
• invoker des méthodes sur une instance

En conclusion:
l’API JNI c’est un peux comme utiliser la réflection. Ça a donc des conséquences en termes de performance. Pour information, créer 10000 objet en java prend 625ms, en pure .net ça donne 46ms et en .Net->JNI->Java ça donne 2.687s.
L’API JNI peut sembler barbare au début, mais on s’y fait et puis il y a la doc, alors RTFM .

C++/CLI c’est de la bombe en termes d’interop. C’est le pont parfait entre le monde .Net et le natif.
L’inconvénient c’est que la syntaxe C++ est lourde. Et elle l’est d’autant plus en C++/CLI car il faut y ajouter les spécificités .Net, et il faut aussi distinguer une instance managée et non-managée, et tout ça passe par de nouveau symboles/mots-clefs.
Les conversions de types entre les deux mondes ne sont pas faites implicitement, et il faut souvent jongler pour avoir le bon type. J’ai par exemple eu des problèmes lors des conversions de String avec JNI: il faut convertir la String^ .net en char* natif pour enfin construire une jstring. Les conversions ont été le plus pénible dans l’histoire.

Enfin, voici le projet complet: Mathias.Jni.CSharp.zip
Un petit rappel des liens utiles:

• http://dotnet.developpez.com/faq/cppcli/
• http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/jniTOC.html