Archives mensuelles : janvier 2016

Les liens de la semaine – Édition #168

Développement

.NET

Technologie

Web

Science et autres

Pensée du jour

Advertisements

J’utilise la variable « p » dans mes expressions Lambda. Et vous?

C’est un collègue qui m’a fait remarquer aujourd’hui. Lorsque j’écris des expressions Lambda en C#, j’ai tendance à utiliser la variable p pour représenter mes expressions.

Voici un gist que j’ai créé il y a plus de 7 mois déjà.

Il s’agit de la meilleure façon de représenter la façon que je développe mes opérations LINQ. Certes, la variable p est mon choix par défaut pour la majorité des opérations. Il y a quand même quelques exceptions à cela. Une règle ne peut pas être une règle sans avoir d’exceptions, n’est-ce pas?

Un bon exemple est la méthode GroupBy. La signature la plus fréquemment utilisée requiert de spécifier un sélecteur pour la clé ainsi que pour les éléments à regrouper. Dans un cas comme celui-ci, j’ai tendance à représenter les deux paramètres en fonction de leur nature. Comme ceci:

Pour le Group By, il s’agit d’utiliser k pour la clé (key) et e pour les éléments regroupés. Encore là, à chaque fois que je regarde cet exemple, je me dis que la règle est vraiment arbitraire et n’est pas ancrée sur des règles solides. Uniquement mon goût personnel et mon humeur du jour.

Depuis que mon attention a été portée sur ce détail, je crois débuter à en faire une obsession. Étant donné ma préoccupation constante pour la qualité du code.

Alors, comment nommer une variable dans une expression Lambda?

Il s’avère que les avis à ce sujet sont assez partagés. Certains vont dire que, vu que le temps de vie d’une variable dans une expression lambda est court, il est admissible d’y aller avec une variable à une seule lettre. En revanche, d’autres vont affirmer que la variable dans l’expression lambda doit donner du contexte sur l’élément de collection en cours de manipulation.

Personnellement, je suis dans le camp de ceux qui utilisent de petits noms de variable dans mes expressions lambda. Je trouve que, dans la majorité des cas, le nom de cette variable a très peu d’impact pour améliorer la compréhension de l’opération LINQ.

Dans un cas comme le premier exemple de ce billet, c’est simple et concis. Il n’y a pas de chichis avec la compréhension de ce code ou même sur la compréhension de ce qui est accompli.

Si votre code est complexe, la variable, peu importe son apparence (un mot ou une lettre), ne fera rien pour régler le vrai problème. Ce problème étant que la complexité de votre solution requiert plus qu’une utilisation des fonctions LINQ.

Et toi, lecteur? As-tu un nom de variable préféré pour tes expressions LINQ?

Les liens de la semaine – Édition #167

Développement

.NET

Technologie

Web

Science et autres

Réflexion comique de la semaine

Développeurs .NET, êtes-vous du type String ou string?

Il y a un aspect du langage C# qui n’est pas assez discuté entre programmeurs. Pour chacun des types natifs du framework .NET, il y a un alias qui le représente. Par exemple, System.Double est alliacé par double. Ce mécanisme permet d’imiter le fonctionnement de certains langages comme C++ où il y a la notion de types primitifs.

Alors, pour le compilateur, il n’y a pas de différence entre System.Int32 et int. C’est voulu ainsi. Ce mécanisme est tellement à la base de .NET que j’apprends même quelque chose à certains d’entre vous. Il n’y a pas de mal à cela.

Du moins, je crois que c’est un détail qui est, en soi, très mineur. Cependant, si vous avez un souci du détail comme le mien, vous vous êtes déjà posé la question. Je ne suis pas le seul!

Si je vous demande si vous êtes du type (ha!) utiliser le mot clé ou l’alias de type, vous dites quoi? Concrètement, est-ce que vous écrivez string.IsNullOrEmpty() ou String.IsNullOrEmpty()?

Je vous l’ai dit, c’est vraiment mineur comme point. D’un point de vue du code, ce n’est pas un problème. Toutefois, je sais que c’est un irritant visuel pour une majorité d’entre vous, peu importe votre camp. J’en suis certain.

Les opinions suivent trois courants:

  • Le type concret ou rien (Double, Int32, String, etc.)
  • Alias sauf pour les extensions (double, String.IsNullOrEmpty(), Float.Parse(), etc.)
  • Alias ou rien du tout (double, int, string, etc.)

Pour ma part, je suis dans la troisième option. Je n’ai pas vraiment d’argument qu’autre que j’ai toujours codé ainsi en C#. C’est assez faible comme argument, n’est-ce pas? Mon deuxième argument serait que d’utiliser l’alias permet de déclarer l’intention de faire référence aux méthodes et fonctionnalités de ce qui serait le type primitif en question.

Alternativement, j’ai le réflexe de me tourner vers les standards de nomenclature du Framework .NET tel que documenté dans la MSDN. Je dois dire qu’il y a place à de l’interprétation selon le contexte. Voici l’état des choses.

Dans General Naming Conventions, il est mentionné la chose suivante: « ✓ DO use a generic CLR type name, rather than a language-specific name, in the rare cases when an identifier has no semantic meaning beyond its type. » Cela veut donc dire qu’une méthode devrait se nommer ToInt64 et non pas ToLong pour éviter de la confusion.

Ça, c’est pour un cas de nom de méthode. En particulier dans le cas du framework .NET où des développeurs utilisant différents langages seront amenés à consommer l’API. Si vous augmentez une fonctionnalité du Framework, c’est une bonne idée de rester en ligne avec cette recommandation.

Cependant, dans les exemples de la même section, il y a des extraits de code utilisant des alias à profusion. Alors, même au niveau de .NET c’est flou. De plus, comme Phil Haack le mentionne, l’équipe de développement de CoreFX a exprimé clairement une préférence envers l’utilisation des alias dans son guide de style de développement.

Avec cette information en main, quoi penser? Je pense vraiment qu’il y a une tendance à utiliser les alias qui sont associés aux différents types déclarés sous le namespace System.

L’essentiel à retenir à ce sujet est qu’il s’agit principalement d’un exercice de style. Dans tous les cas, il s’agit d’un point à discuter en équipe si ce n’est pas déjà fait. Par exemple, dans mon cas, il s’agit d’une règle de reformatage qui est automatiquement appliquée par ReSharper.

Tous les membres de l’équipe l’utilisent, alors tout va bien.

Les liens de la semaine – Édition #166

Développement

.NET

Technologie

Web

Science et autres

 

En guise de finale, une annotation qui va vous faire rire à propos du JavaScript moderne.