Any() mit UND-Verknüpfung

@ErfinderDesRades
Genau das habe ich oben gemeint.

Das ist der Grund, warum ich eigentlich niemals var verwende.Viel Datentypen lassen sich mit den ersten drei-vier buchstaben + Tab ausschreiben.

Sollte er sich dennoch wundern, hat er Datentypen nicht verstanden, und sollte sich lieber nochmal ein gutes Buch schnappen.

das sollte aber eher der Grund sein, das typsichere == vorzuziehen, wenn möglich.

Dass Doofi das in diesem Falle sieht liegt daran, dasses nahe beieinander steht.
Aber es ist ja noch viel tückischer, denn Doofi wird das zunächst ja überhaupt nicht merken!
Das Proggi läuft ja, verhält sich nur in bestimmten Situationen nicht ganz richtig - dann nämlich, wenn dateInput und date1 eiglich gleich sein sollten - dann fasst das Proggi die ja nachwievor als unterschiedlich auf, und tut dementsprechend was anderes als das erwartete.

kann ein Super-Fieser Bug sein.

Nun gut, ich gebe mich geschlagen
Dennoch kann man, wenn der Code geschrieben ist, per hovern über dem Equals sehen was nun benutzt wird. Sollte da irgendetwas anderes stehen als DateTime weiß man, dass die Datentypen nicht stimmen.

OT: Vielleicht kann ich mich auch schon nicht mehr ganz in einen neuling hineinversetzen, hab derzeit so viel mit dem Wörtchen dynamic und Reflection im Generellen am Hut, da habe ich wohl verlernt mich auf den Compiler zu verlassen

In Java ist das so dass == auf referenzgleichheit prüft und nur .equals() auf wertegleichheit, kann sein dass der TE das davon hat?

Manü schrieb:

Ich glaube eigentlich nicht, dass die Diskussion noch im Sinne des Thread steht, aber darüber sollen die Mods entscheiden.

na, aber du profitierst doch auch davon, wenn dir die feinen gemeinen Unterschiede von Equals(), Equals() und == auseinandergesetzt werden!

Manü schrieb:

@ErfinderDesRades: was du vergisst, in deiner Affinität an die Typsicherheit, ist dass die Daten nicht immer sauber geliefert werden.

"nicht immer sauber" - das ist in meinen Augen treffender formuliert, als du es glaub gemeint hast
Also wenn es euer erklärter Wille ist, auf Datum-Vergleichen aufzubauen, wo man nichtmal weiß, ob die verglichenen Objekte DateTime oder String sind, dann soll ich wohl den Mund halten.

Also nochmal Code gucken:Da ist der Ausdruck row008["F1391008"].Read<DateTime>() offensichtlich vom Typ DateTime.
Und nach deiner Aussage muss ich jetzt annehmen, dass beginnAu, endeAu vom Typ String sind?
Oder vom Typ Object, oder dynamic und kann mal ein String drinne sein, mal ein DateTime?

Ich glaub nicht, dass das funktioniert, sondern das dürfte genau der erwähnte super-fiese Bug sein.

Achso - du willst im False-Fall ja noch iwie weiter-prüfen.
naja - wie wolle. Also für mich mit meiner Typsicherheits-Affinität sieht das aus als stünde es auf tönernen Füßen, und zwar wackelig.

Beachte: ich hab einen engeren Begriff von Typsicherheit.
Bei mir ist Typsicherheit nichts, was man zuvor prüfend erledigt, sondern typsicher ist, wenn zur Compilezeit die DatenTypen bekannt sind, und wenn sie entsprechend ihren Eigenschaften eingesetzt werden.
Also man kann DatenTypen abprüfen, aber Typsicherheit ist eine anzustrebende Eigenschaft des Code-Stils.
Typsicherheit kann man nicht immer erreichen, etwa EaranMaleasi ist derzeit in Reflection unterwegs, und mit dynamic - da muss man sich sehr nach der Decke strecken.
Oder auch Konvertieren/Parsen (Parsen: Konvertieren von String) ist prinzipiell nicht typsicher, also jede Konvertierung kann auch scheitern, eben wenn das was konvertiert werden soll, halt nicht konvertierbar ist.
Konvertieren/Parsen ist aber ggfs. notwendig, um mit dem geparsten Ergebnis dann typsicher weiterarbeiten zu können.
.Equals(Object) ist aber nicht typsicher, da ist zur Compilezeit nicht bekannt, welchen Datentyp das Argument hat (Object kann ja alles sein).
Und das ist ganz unnötig, denn deine Prüfung hat doch ergeben, dass es DateTime-Parseable ist. Also parse es, und verwende dann den DateTime, den du bekommst.

Allerdings eine Prüfung, die nur ergibt, dass sauber in DateTime geparst werden kann, wäre mir eh zuwenig.
Bei mir würde die Prüfung gleich den DateTime ergeben, dann brauch ich nicht nochmal "sauber parsen".
Kurz: Meine Prüfung würde DateTime.TryParse() verwenden, und dann wär typsicher.