Doit-on placer les directives ‘using’ en haut ou en bas du namespace?

Dans le monde de la programmation, les choses évoluent assez rapidement pour apprendre de nouvelles choses sur une base régulière. Par le passé, j’ai déjà abordé le sujet des qualités à posséder en tant que développeur. J’en aurais une nouvelle à ajouter dans cette liste. L’ouverture d’esprit face aux nouvelles idées est probablement la suivante.

Dernièrement, j’ai découvert une nouvelle façon d’écrire une classe C#. Cette pratique vise à mettre les directives using après la déclaration du namespace. Dans le passé, j’avais uniquement eu à travailler avec du code où les directives étaient placées avant le namespace.

Le placement du using

Le gabarit d’une classe C#, tel que livré dans Visual Studio depuis la nuit des temps, prend la forme suivante:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
namespace FrenchCoding.Blog.Tests
{
public class Class1
{
}
}

view raw
class1.cs
hosted with ❤ by GitHub

Pour moi, il s’agit de la façon que j’ai appris à écrire une classe C#. Les instructions using en premier, le namespace qui suit et la classe qui vient par la suite.

Or, il y a une alternative à cette façon de coder une classe. Voici comment elle prend forme:

namespace FrenchCoding.Blog.Tests
{
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
public class Class2
{
}
}

view raw
class2.cs
hosted with ❤ by GitHub

En guise de rappel, la directive using est utilisée afin de laisser savoir au compilateur C# que nous allons référencer les types sous un certain namespace sans devoir avoir recours à utiliser leur nom complet à chaque fois que vous désirez l’utiliser. C’est un raccourci, en quelque sorte.

Pour quelle raison?

D’emblée, nous allons aussi convenir qu’il s’agit d’un changement assez mineur vis-à-vis la façon traditionnelle d’écrire du C#. Il s’agit d’un changement qui est principalement d’ordre syntaxique et de préférence de développeurs, car il n’introduit aucune modification de comportement lors de vos applications .NET.

Ceci étant dit, même s’il n’y a pas d’impact fonctionnel, cela ne veut pas dire qu’il n’y a pas d’effets à cette façon de faire. À mon avis, il y a deux impacts à utiliser cette technique.

Tripoter le compilateur

Il s’agit plus d’une micro-optimisation qu’autre chose. Le principe qui guide la résolution de namespace est bien simple. Le compilateur C# va toujours y aller en fonction de la proximité en fonction du namespace de la classe en cours de compilation.

Par exemple, si vous avez développé une classe qui porte le nom « Math », vous pouvez référencer votre classe en faisant en sorte que votre using ait préséance sur celle dans System.Math.

Si ce n’est pas une mauvaise pratique de développement, je ne sais pas comment cela peut être nommé. Calquer le nom d’une classe du framework .NET doit être un geste très réfléchi, car il peut y avoir un impact sur la maintenabilité à long terme de votre application. À la limite, je préfère faire usage à un alias dans cette situation.

Esthétisme

C’est simple. Le compilateur n’aime pas se répéter. Les bouts de namespace redondants peuvent être retranchés.

namespace FrenchCoding.Web
{
using Data;
public class Startup
{
public void GetData()
{
var x = new Repository();
}
}
}

view raw
namespace.cs
hosted with ❤ by GitHub

La classe Startup fait référence à une classe sous FrenchCoding.Data. La partie de Namespace « FrenchCoding » peut donc être retranchée.

Établir une convention et une conversation

L’origine de cette pratique vient d’une directive qui est émise par l’outil de validation de code StyleCop. Il s’agit de la règle SA1200. Allez la lire, c’est intéressant.

Le but de cette règle et de StyleCop est d’avoir un code qui est uniforme afin de minimiser les risques d’erreurs liés à l’interprétation du code. Ceci étant dit, si vous utilisez StyleCop, il y a de fortes chances que vous avez décidé de vous conformer à cette règle plutôt que le contraire.

Là où cela devient réellement intéressant, c’est que livre Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries spécifie explicitement le contraire (à la toute fin du billet).

Ce qui est encore plus important c’est d’avoir une conversation en équipe sur les différentes façons d’écrire du code. Il s’agit d’un sujet que beaucoup refusent aborder car il est sensible et peut facilement laisser place à l’émotivité. Néanmoins, il faut quand même avoir cette conversation, car c’est en échangeant que vous allez grandir comme équipe.

De plus, il ne faut pas automatiquement croire ce qu’un outil automatisé peut vous dire. Soyez indépendant d’esprit et questionnez ce qui vous est présenté.

 

Source: Should ‘using’ statements be inside or outside the namespace?

Les liens de la semaine – Édition #135

Développement

.NET

Web

Technologie

Science et autres

Petite astuce de dépannage : utiliser PowerShell pour manipuler du JSON

Dans les Liens de la semaine #130, le lien vers un défi visant à manipuler un fichier CSV a été mentionné. En quelques mots, ce défi consiste à trouver une façon de transformer une source de données sous le format JSON en un fichier CSV ayant un format prédéfini.

Le but de l’exercice était de voir et comparer les solutions qu’auraient prises certains développeurs. Si vous allez lire les commentaires en réponse, vous verrez que ça va dans tous les sens. Pratiquement chacun des langages populaires a sa solution. Certaines étant plus originales que d’autres.

Ce qui m’intéresse dans ce genre de défis est de pouvoir en apprendre plus sur les langages de programmation que j’utilise. C’est toujours dans ces situations-là qu’on en apprend le plus. Cette fois-ci, je n’ai pas été particulièrement impressionné par la solution C#. En .NET, il n’y a pas vraiment de tour de magie possible pour lire un fichier CSV et de l’écrire sur disque.

Là où j’ai été surpris est la solution écrite en PowerShell. Je savais que PowerShell a tout en place pour permettre, par exemple, un administrateur réseau d’avoir un plein contrôle de votre poste de travail. Dans ce contexte, PowerShell est comme le ciment qui fait en sorte que les briques des versions récentes de Windows puissent tenir ensemble.

Pour scripter sous Windows, c’est avec PowerShell que ça se passe. Le langage est établi au point qu’il fait partie intégrante de la prochaine version d’ASP.NET.

Ce qui m’a impressionné c’est d’apprendre que PowerShell a tout en place pour manipuler du JSON et des fichiers CSV. J’ai trouvé cela sincèrement cool!

L’essayer c’est super simple. Il suffit d’utiliser la commande suivante:

(Invoke-WebRequest -Uri http://jsonplaceholder.typicode.com/posts | ConvertFrom-Json) | ? title | select id,title | epcsv csv.csv -not

C’est aussi simple que cela!

Il y a même plus que la manipulation de fichiers JSON et CSV dans PowerShell. Il suffit d’aller jeter un coup d’oeil à la liste des Cmdlets sous le module Microsoft.PowerShell.Utility. En guise de conclusion et de vous inspirer, voici quelques exemples:

  • ConvertTo-Html: permets la conversion en HTML d’un objet. La même chose est possible avec ConvertTo-Xml
  • Get-FileHash: retourne le hash d’un fichier
  • Get-UICulture: donne de l’information sur la culture courante
  • Tee-Object: permets de rediriger le résultat d’une commande vers un fichier et une autre commande

Bon scripting!

Les liens de la semaine – Édition #134

Développement

.NET

Technologie

Web

Science et autres