Bien que cela fonctionne, je suis assez certain qu'il existe un moyen plus concis (et approprié?) d'écrire cette expression.
double currentPopulation = 0.0; if (detailmetrics.FirstOrDefault(dm => dm.MetricScopeID == 2 && dm.MetricTypeID == 1 && dm.Timeframe.Equals("C")) != null) { currentPopulation = Convert.ToDouble( detailmetrics.FirstOrDefault(dm => dm.MetricScopeID == 2 && dm.MetricTypeID == 1 && dm.Timeframe.Equals("C") ).MetricValue ); }
4 Réponses :
Attribuer le résultat de la requête à une variable temporaire pour éviter d'évaluer deux fois l'évaluation deux fois.
currentPopulation = Convert.ToDouble(dm?.MetricValue ?? "0");
Vous pouvez le raccourcir à: De cette façon, vous n'ayez évalué que la FirstArdefault une fois. p> p>
Je pense que vous voulez dire convert.todouble (dm.metricValue) code>
beaucoup de façons de cuire un chat, y compris (votre prédicat omis pour la brièveté): ce qui précède signifie que le Si vous ne voulez pas faire cette hypothèse, vous pouvez écrire votre propre méthode de conversion "sûre" qui gère les nulls et invalide Valeurs, par exemple: p> métricvalue code> est une chaîne qui est null ou un double valide, et que vous voulez un résultat 0 s'il est null. p>
Tout simplement
Upvoted. Définit Courrovectivepopulation code> à
0.0 code> si aucun élément satisfait le
où code> prédicat. Je sais que c'est exprès, mais il est différent du code d'origine qui n'attribuait pas à
CoururalPopulation code> dans ce cas.
Merci @bahrom pour votre commentaire. J'ai édité le message original pour montrer que j'initialise la variable avant la condition.
@MBrianDunson Après cette modification, cette réponse est plus équivalente au code (édité) de la question et, en fait, Bahrom peut réintroduire le var code> ils avaient une fois depuis qu'il est approprié maintenant.
Si le type de compilage de
dm.timeframe code> est simplement
string code>, je préfère
dm.timeframe == "C" code> sur
DM .TimeFrame.equals ("c") code>.
Merci ... Le type d'heure de compilation de DM.TimeFrame est en effet une chaîne. Par curiosité (et j'espère apprendre quelque chose), pourquoi préférez-vous '==' sur des plats?
Parce qu'il est plus facile de lire (opinion personnelle). C'est pour la même raison que je ne fais pas
dm.metricscopeid.equals (2) code> même si je pouvais. Il y a d'autres raisons. Utilisation de
== code> ne donnera pas d'exception de référence NULL si son opérande gauche est
null code>. Et utiliser
== code> se plaindre souvent de fausses comparaisons accidentelles. Par exemple,
dm.metricscopeid.equals ("c") code> compilera (mais est inutile car il compare un numéro à une chaîne) tandis que
dm.metricscopeid == "C" code> ne compilera pas (vous informer que l'opération n'est pas autorisée).
Vous voudrez peut-être aussi envisager d'utiliser
double.trypsarse code> si la valeur de
métricvalue code> pourrait causer
convert.todouble code> pour lancer une exception et vous voulez gérer il.