notation Lambda et les comparaisons logiques

Question

La notation lambda

x => x.MyProperty 

est facilement confus par certains humains, avec une plus grande ou égale à. Ie

if (x => y) ... 

la question est: Est-ce que le compilateur peut les confondre? -À-dire, si l'un d'adopter une convention par laquelle supérieure ou égale à est toujours codifiés comme:

if (x >= y) ... 

Je suppose que le compilateur peut distinguer entre les deux en fonction du contexte, mais quelle serait la « meilleure pratique »?

Une question sur le SO

ASP.NET MVC2 Checkboxes in a table

sorte de montré qu'il est facile de se tromper.

EDIT:

À la lumière du petit tempête qui a brassé au-dessus de celui-ci, ce qui suit peut préciser.

J'ai posé la question parce que j'ai répondu à une question où le gars avait mal saisi la notation lambda. J'ai signalé sa faute de frappe et il a accepté ma réponse. Il y a un lien vers la question ci-dessus.

La question m'a alors ébranlé. J'ai toujours utilisé> = pour une très bonne raison, mais j'étais convaincu que j'avais vu du code qui utilisait l'autre notation. Parfois, vous avez des suppositions que vous ne pensez pas à des questions. Cela peut très bien être de mes jours VBA ou non, mais la conviction reste que j'ai vu du code qui compile, s'exécute et qui utilise => pour la comparaison supérieure. Ainsi soit-il. Toutes mes excuses pour ne pas avoir "enflammé VS", mais j'avais travaillé toute la journée avec Sitefinity dans un bureau sans installation de VS. Aucune excuse, je t'accorde.

Mais notez que les expressions lambda en C# sont seulement aussi anciennes que ... .NET 2? ou était-ce .NET 3.5. Étant donné que j'ai utilisé C# depuis la version 1.0, la question est fausse, mais pas absurde.

Je pense aussi que les règles rigides de SO sont géniales dans la mesure où elles produisent des images vierges Q & A. Mais il existe différentes façons d'appliquer les règles. Je n'utilise que SO sérieusement depuis la mi-septembre, donc je pense qu'il est préférable de tirer un avertissement sur les mauvaises questions plutôt que de secouer la casquette à la première occasion. C'est ce que SO encourage: laisser un commentaire plutôt que de simplement déclencher un marquage positif. Vous donnez au demandeur l'occasion de réaliser son erreur et de supprimer une question inutile du système. Parce qu'une fois que les réponses et les votes arrivent, la question ne peut pas être supprimée par le demandeur.

Fin de la diatribe.

Answer 1

if (x => y) est code invalide.

Les opérateurs de comparaison (x >= y et x <= y) doivent avoir le <> avant le signe =.

Ainsi, il n'est pas possible pour le compilateur (ou un humain orienté détail) de les confondre.

Answer 2

=> est l'opérateur lambda

râpe ou égal est> =

Je ne pense pas qu'il puisse être confus, car ils ne sont pas interchangeables

Answer 3

Le compilateur peut-il les confondre?

Non. En C# (je regarde l'étiquette) >= est toujours comparaison; => est toujours une expression lambda. Il y a no => comparison operator in C#.

Je suppose que le compilateur peut distinguer entre les deux en fonction du contexte

Le compilateur n'a pas besoin de contexte pour distinguer les deux; voir au dessus.

Ie, doit-on adopter une convention par laquelle supérieure ou égale à est toujours codé comme:

if (x> = y) ...

Oui, parce que est la seule façon dont le compilateur l'acceptera. :-)

En ce qui concerne l'erreur humaine, je pense que l'aide mnémoniques suivante:

• Nous disons presque toujours « supérieur ou égal à » par opposition à « égal ou supérieur à ».
• Les symboles mathématiques placent le «plus grand que» ou «plus petit» au-dessus de la ligne qui symbolise «ou est égal». Cela peut se traduire par un ordre de gauche à droite assez naturellement.
• Le symbole utilisé pour une expression lambda en C# ressemble à une flèche, pointant vers l'expression de la valeur renvoyée. Cela peut être considéré comme des «rendements».