août
2009
Un article de Philippe Vialatte
Juste un petit coup de râlage face a une mauvaise pratique qui tends a se répandre ces derniers temps…
Pour ceux qui ne seraient pas encore au courant, le Framework 3.5 propose, entre autres fonctionnalités très sympathiques, une nouvelle notation, un peu plus « fonctionnelle », a savoir les expressions lambda.
Ces expressions permettent d’exprimer des idées en très peu de code, et ont l’avantage d’être très puissantes, et, en général, lisibles. elles permettent aussi, dans certains cas de rendre le code plus fortement types, et sont une des pierres angulaires de LINQ.
Le problème que je rencontre de plus en plus est le suivant : depuis que cette syntaxe est apparue, la quasi-totalité des exemples, que ce soit sur internet, dans des livre ou des magasines, promeut la syntaxe suivante :
Cote LINQ (exemple tires des 101 LINQ Samples):
where p.UnitsInStock == 0
select p;
Ou cote expressions (dans le C# programming Guide) :
Jusqu’ici, pas de gros problèmes, me direz-vous, on travaille sur un produit, alors on l’abrège en p, et sur un client, on l’abrège en c…sauf que c’est fondamentalement mal, si j’en crois :
- mon expérience
- la littérature (Code Complete, le wiki originel)
Un effet secondaire amusant est de voir ce que devient cette non-convention après deux ou trois itérations, entre le stagiaire bien intentionné qui fait un copier-coller, la classe qui change de nom, les requêtes complexes (jointures et autres), on obtient ce genre de choses :
where colids.Contains(l.ColumnId)
&& colvals.Contains(l.FieldValue)
&& l.InstitutionId == institutionId
orderby l.ID
select l.RecordGroupId).Distinct();
(pas un exemple de chez moi, j’avoue…)
Je considère que toutes les variables dans une expression lambda doivent être traitées au même titre que les autres variables, a savoir, avoir un nom descriptif, non-équivoque et sans abréviations (les seules variables ayant droit a un peu de sympathies étant i et j comme itérateurs, et x, y et z comme coordonnées).
2 Commentaires + Ajouter un commentaire
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
« Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live »
Dans mon cas, tant que je maintiens mon code, l’affirmation est automatiquement vérifiée
Moi il n’y a pas de stagiaire en développement et c’est moi qui code en grande partie les applis en .NET donc pas de risque de tomber sur ce genre de code mal propre