3 innovations que j’aimerais voir dans C#38
Your Content Goes Here
27/01/2023
5min

Bonne année 2038 ! Cette année marquera à jamais les esprits des Insiders avec l’arrivée récente de .NET 25, dernière mouture du framework.
Une nouvelle version avec des fonctionnalités inédites comme la prise en charge native des berlines Tesla, ou bien la classe SatelliteClient
qui permet de se connecter directement à un satellite orbital.
Comment ça, vous ne me croyez pas ? Bon d’accord. Certes. Nous sommes encore en 2023. Cependant, notre imagination, elle, est résolument tournée vers le futur!
C’est cette même imagination qui permet de stimuler l’innovation que vous buildez chaque jour au sein de vos missions respectives.
Ainsi, afin d’alimenter cette dynamique, je vous propose 3 innovations que j’aimerais beaucoup voir dans C# 38, une version hypothétique et futuriste de C#.
C#38 : La fin du point-virgule
Combien de fois avez-vous rencontré cette erreur ?
Compilation error (line 7, col 35): ; expected
Probablement un nombre incalculable de fois. Étudiants, Développeurs Confirmés, Lead Devs, Architectes… On rencontre cette erreur à chaque étape de sa carrière, que ce soit sur notre PC ou celui d’un(e) acolyte.
Je pense qu’en 2023, les points-virgule sont dépassés. À l’origine introduits pour marquer la fin d’une instruction impérative, ils n’ont plus tant d’utilité aujourd’hui.
Bon nombre de langages impératifs ont démontré leur popularité et leur efficacité tout en se passant du point-virgule: Python, Swift, TypeScript…
Pourquoi pas C#? Les deux derniers ont d’ailleurs une syntaxe et des concepts inspirés de C et de C#. De plus, avec l’avènement des top-level statements, le code C# pourrait être amené vers un nouveau monde: celui des scripts.
Un terrain conquis par Python et autres Perl. Il ferait donc sens, afin de garantir sa pérennité et sa compétitivité, de retirer le point-virgule.
Voici un exemple de ce à quoi ça pourrait ressembler:
app.MapGet("/radio", () => new { Nom = "RTL" })
var radio = radioProvider.GetById(1)
if (radio.Nom is "BFM")
return 2
Une vision qui a fait couler beaucoup d’encre sur GitHub.
Pouvoir exécuter directement un fichier .cs
sans csproj
Quel développeur n’a pas rêvé de pouvoir exécuter un fichier .cs
directement depuis la ligne de commande ?
Ou directement depuis son usine d’intégration continue ? Via un dotnet run
, en somme, mais sans csproj
.
Moi, en tout cas, j’en rêve.
Aujourd’hui, certains cas d’usage de C# ne nécessitent pas réellement de créer un projet, ou même de passer par une moulinette de compilation.
Aujourd’hui, nous avons le Just-In-Time Compiling, voire même le Just-In-Time Debugging. Pourquoi pas le Just-In-Time Running ?
Imaginez pouvoir exécuter ce bout de code directement, sans passer par un csproj
:
using Git2Sharp
var sha = new Repository("path/to/repo").Head.Tip.Sha
var json = File.ReadAllText("appsettings.json")
var appsettings = JsonConvert.DeserializeObject<dynamic>(json)
appsettings.LastCommitSha = sha
json = JsonConvert.SerializeObject(appsettings, Formatting.Indented)
File.WriteAllText("appsettings.json", json)
Ce bout de code peut se retrouver, selon moi, dans une pipeline d’intégration continue. Il permet d’ajouter le dernier SHA1 du commit dans une variable des appSettings
.
Cela peut être utile pour afficher ce SHA1 dans un SwaggerUI lors de l’exécution d’une API!
Il est vrai qu’il est possible d’utiliser un script bash avec sed pour ce genre de choses, mais un développeur .NET sera toujours tenté de pouvoir le faire en C# ! Cela rendrait ceci possible.
C#38 : Les paramètres à deux noms
En Swift, tous les paramètres de fonction peuvent avoir deux noms. Le nom externe, et le nom interne. Le nom externe est le nom du paramètre tel qu’il sera appelé lors de l’appel à la fonction, ainsi:
makeDog(withName: "Kangaji", andAge: 12)
Ci-dessus, withName
est un nom exposé. andAge
aussi.
On peut remarquer que l’appel de la fonction ressemble à une phrase.
Extrêmement lisible. C’est tout l’intérêt des paramètres externes.
Le nom interne est le nom réel du paramètre. Il ne peut être utilisé que par le code se situant à l’intérieur de la fonction.
func makeDog(withName name: String, andAge age: Int) -> Dog {
return Dog(name: name, age: age)
}
Ici, name
et age
sont les deux paramètres aux noms internes de la méthode.
Leur nom correspond plus à un usage interne à la méthode. Ils sont ne sont ainsi pas préfixés d’un mot comme with
ou and
.
En C#, des noms de paramètre spécifiques pour l’appelant permettraient d’améliorer la lisibilité de beaucoup de bases de code.
Les named parameters existent déjà, nous pourrions ainsi les faire évoluer pour y ajouter cette notion, bien pratique pour la lisibilité du code !
Voyez par vous-même, avec ce code C#38 :
public static Dog MakeDog(string withName name, int andAge age)
{
return new Dog(name, age)
}
var dog = MakeDog(withName: "Kangaji", andAge: 12)
Conclusion
Selon ma vision, C# peut changer drastiquement.
Afin de rester compétitif devant des langages comme Python ou Swift, il se doit d’évoluer vers un langage orienté scripting encore plus facile à prendre en main, et plus lisible.
Mais bon, ce n’est que mon avis. Toute remarque est la bienvenue dans les commentaires ! 😉
PS: Si vous venez de 2038 et que vous lisez ce message, commentez et faites-moi savoir comment C# a évolué ! 😉