C#

You'd think it would be easy, but it turns out to be more complicated than you'd imagine.

Microsoft vient d'annoncer que Visual Basic sera bien supporté dans .NET 5.0, ce qui semble être une bonne chose pour les développeurs utilisant ce langage, mais en même temps ils annoncent que le langage n'évoluera plus.

Visual Basic continuera donc à fonctionner sur Windows et sur les autres plateformes via .NET Core mais il ne bénéficiera plus des futures nouvelles fonctionnalités qui nécessiteront une modification du langage.

Je viens de jeter un œil à du code qui a cette structure :

public static bool DoSomething()
{
  try {
    Foo();
    return true;
  }
  catch (Exception e) {
    return false;
  }
}

En gros au lieu de profiter du système d'exception qui permet d'avoir un maximum d'information sur le problème et le contexte dans lequel il survient (Stack trace), le développeur choisit de mettre toutes ces précieuses informations à la poubelle pour le remplacer par un booléen qui lui dit simplement que son appel de fonction a échoué...

On est en 2020 les gars, et C# ce n'est pas du C, même si ça commence pareil...

Dans mes projets Visual Studio j'aime bien utiliser "1.0.*" dans l'attribut AssemblyVersion pour que le numéro de build et de révision s'incrémentent automatiquement à chaque compilation. Mais dans les dernières versions, si on crée un projet et qu'on vient modifier la valeur par défaut ("1.0.0.0") pour la remplacer par "1.0.*", on a l'erreur suivante à la compilation :

I'm a big fan of the Sentry service which is used to send error reports.

Each time an unexpected error occurs in one of my applications, a certain amount of information is collected (exception type and message, call stack, operating system version, user name...) then sent to Sentry's servers.

La dernière version de ReSharper propose un nouveau assistant de frappe qui m'est particulièrement utile dans ma lutte à mort ;-) avec les références nulles. Il suffit d'appuyer sur ! ou ? juste derrière le nom d'un type ou d'un argument pour insérer un attribut [NotNull] et [CanBeNull].

Si on appuie une deuxième fois, un test et un déclenchement d'exception comme celui ci :

Les dictionnaires sont une structure de données bien pratique dans certaines situations, mais j'ai toujours trouvé qu'ils nuisaient un peu à la lisibilité du code.

Dans l'exemple suivant, dans la boucle on ne sait pas exactement ce que représente la clé et la valeur. Bien évidemment le code ici est très court donc on le comprend assez facilement mais sur du code réel, ça n'est pas toujours évident.

Aujourd'hui, en examinant un problème sur l'application d'un client, je suis tombé sur quelque chose de bien étrange.

L'application tente de se connecter à AutoCAD en utilisant Marshal.GetActiveObject de façon à récupérer le nom du document actif comme je l'avais expliqué dans cet article. Mais il semblerait que l'application ne fonctionne pas sur certaines machines.

Pour essayer de comprendre comment fonctionne le pilotage d'une imprimante, je me suis dit que ce serait bien d'examiner le code de Repetier-Host, qui était en Open Source jusqu'à sa version 0.84. Hot-World, la société allemande qui développe le logiciel, a décidé depuis de changer de licence et de ne plus partager son code.

En général, il est préférable d'éviter d'écrire une méthode avec des paramètres booléens car ce n'est pas très lisible. Supposons par exemple qu'on écrit une méthode qui recherche des entités, avec un paramètre qui permet d'exclure les cercles de la recherche :

IList<Entity> FindEntities(bool ignoreCircles)
{
  //...
}

Quand on appelle la méthode, ça donne ceci :