Vom heutigen Datum x Tage abziehen
-
Hallo,
ich würde gerne immer vom aktuellen Datum 10 Tage abziehen.
Für die Addition wäre das ja kein Problem mit DateTime.Today.AddDays(x)
Zum Abziehen hab ich nur DateTime.Today.Subtract gefunden, allerdings wird da ja ein DateTime Format und keine Zahl erwartet.
Kann mir da bitte jemand helfen, wie ich das geschickt lösen kann?!
Dankeschön!
-
DateTime.Today.AddDays(-10);
-
DANKE! *schäm*
-
var vorZehnTagen = DateTime.Today - TimeSpan.FromDays(10);
-
O.o schrieb:
var vorZehnTagen = DateTime.Today - TimeSpan.FromDays(10);
varnsinn
-
var-Missbrauch schrieb:
O.o schrieb:
var vorZehnTagen = DateTime.Today - TimeSpan.FromDays(10);
varnsinn
VARnung!
Dieser Code ist nicht zum Nachahmen zu Hause geeignet. Minderjährige oder Menschen mit schwachen Nerven sollten das Forum umgehend verlassen!
-
Hä,
weißt du nicht was das Schlüsselwort "var" bewirkt, oder worüber regst du dich auf?
-
@Th69: Trollinger
-
Th69 schrieb:
Hä,
weißt du nicht was das Schlüsselwort "var" bewirkt, oder worüber regst du dich auf?
Doch: var ist Scheiße, einfach weil's dir den Speicher zumüllt. Wer bei so einfachen Typen schon var verwendet, dem ist dann auch nicht mehr zu helfen ...
-
Th69 schrieb:
Hä,
weißt du nicht was das Schlüsselwort "var" bewirkt, oder worüber regst du dich auf?
Für anonyme Typen und sonst garnichts. Man sieht nur immer mehr Leute die es aus Faulheit überall verwenden und das codelesen somit erschweren.
var y = f();
Super, nicht?
-
var-Polizei schrieb:
Th69 schrieb:
Hä,
weißt du nicht was das Schlüsselwort "var" bewirkt, oder worüber regst du dich auf?
Für anonyme Typen und sonst garnichts. Man sieht nur immer mehr Leute die es aus Faulheit überall verwenden und das codelesen somit erschweren.
var y = f();
Super, nicht?
Wer seine Variablen und Methoden so benennt, dem ist nicht mehr zu helfen.
-
Wieso müllst "var" den speicher voll?? Wenn der code übersetzt wird, wird automatisch das var entsprchend dem Typ ersetzt!?! oder net
-
var-Polizei schrieb:
Für anonyme Typen und sonst garnichts.
Quatsch. Zu extrem gedacht.
Was ist besser?
var specialFoo = new Foo<Dictionary<string, Bar<Gnarl>>, List<double>, Func<int, double, bool, Bar<float>, long>>();
oder
Foo<Dictionary<string, Bar<Gnarl>>, List<double>, Func<int, double, bool, Bar<float>, long>> specialFoo = new Foo<Dictionary<string, Bar<Gnarl>>, List<double>, Func<int, double, bool, Bar<float>, long>>();
Was ist nun lesbarer? Was soll die sinnlose Duplizierung der Information bewirken?
-
Dass nach dem Refactoring, bei dem
new Foo<Dictionary<string, Bar<Gnarl>>, List<double>, Func<int, double, bool, Bar<float>, long>>();
- zusammen mit ein paar anderen Codezeilen - in eine Funktion ausgelagert wird, der Typ immer noch da steht. An Stelle eines kryptischenvar specialFoo = MakeTheSpecialFoo();
-
NullBockException schrieb:
Wieso müllst "var" den speicher voll?? Wenn der code übersetzt wird, wird automatisch das var entsprchend dem Typ ersetzt!?! oder net
Tut es ja eh nicht.
var
ist natürlich statisch typisiert, und hat keinerlei Runtime Overhead.Man ganz davon abgesehen dass ich auch den Zusammenhang zwischen dynamischen Typen und Speicher Zumüllen nicht sehe.
-
ja eben, wollte den Mund jetzt nich zu voll nehmen, aber ich dachte mir schon das "var" statisch ist, also sind "Das müllt den Speicher voll"- Argumente ehr für "Ich hab keine Ahnung wie 'var' funktioniert" zu interpretieren;) In .NET 4.0 gibts es aber so "dynamische" Typen heisten die nich sogar "dynamic" welche wie "var" zu verwenden sind, aber zur laufzeit auch zuweisungen auf andere Typen haben dürfen.. ähnlich wie "void*" nur "typsicherer".
-
hustbaer schrieb:
Dass nach dem Refactoring[...]
Was willst Du mir damit sagen?
- Dass, wenn man die im Studio integrierten Refactoring-Tools benutzt, sein Gehirn ausschalten kann? D.h. wenn man vorher Wert auf Lesbarkeit gelegt hat (man hat var geschrieben), beim (halb-automatischen) Refactoring darauf verzichtet und den Typ nicht von 10 Zeilen weiter unten hochkopieren kann? Wer beim Refactoring darauf verzichet schreibt auch gleich
var x = F();
Und zwar genauso. Ein Variablenname ohne Bedeutung. Ein Funktionsname ohne Bedeutung.
- Dass das VS Refactoring doof ist, da es das var nicht automatisch durch den Typ ersetzt?
- Dass es i.O. ist schlecht lesbaren Code zu produzieren, denn man *könnte* ihn ja refaktorisieren und dann *wäre* ja alles toll?
Außerdem ist es fraglich, dass man so einen komplexen Generic einfach in eine Funktion versteckt und die Generik so einfach wegkapselt. Und wenn der Funktionsname keinerlei Rückschlüsse auf den Typ zulässt, wie du mit Deinem es "wird kryptisch" unterstellst, ist er auch schlecht.
-
void* schrieb:
Was willst Du mir damit sagen?
- Dass, wenn man die im Studio integrierten Refactoring-Tools benutzt, sein Gehirn ausschalten kann? D.h. wenn man vorher Wert auf Lesbarkeit gelegt hat (man hat var geschrieben), beim (halb-automatischen) Refactoring darauf verzichtet und den Typ nicht von 10 Zeilen weiter unten hochkopieren kann? Wer beim Refactoring darauf verzichet schreibt auch gleich
var x = F();
Und zwar genauso. Ein Variablenname ohne Bedeutung. Ein Funktionsname ohne Bedeutung.
- Dass das VS Refactoring doof ist, da es das var nicht automatisch durch den Typ ersetzt?
- Dass es i.O. ist schlecht lesbaren Code zu produzieren, denn man *könnte* ihn ja refaktorisieren und dann *wäre* ja alles toll?
Das erste aus dieser Liste. Ist einfach nur ne Beobachtung, sowas passiert schnell mal. Also ich sage nicht dass man sein Gehirn ausschalten sollte. Ich sage auch nicht dass das nur jemandem passieren kann der sein Gehirn ausgeschaltet hatte. Ich glaube ganz im Gegenteil, dass man sein Gehirn beim Refactoring für andere Dinge braucht, und daher schnell mal solche "Kleinigkeiten" übersieht.
Außerdem ist es fraglich, dass man so einen komplexen Generic einfach in eine Funktion versteckt und die Generik so einfach wegkapselt.
...weil?
Und wenn der Funktionsname keinerlei Rückschlüsse auf den Typ zulässt, wie du mit Deinem es "wird kryptisch" unterstellst, ist er auch schlecht.
Darüber könnten wir uns jetzt streiten. Sprechende Funktionsnamen sind gut, klar. Bloss irgendwo ist eine Grenze, und ein Funktionsname der es einem Programmierer der das jeweilige Projekt nicht sehr gut kennt erlaubt auf den Typ
Foo<Dictionary<string, Bar<Gnarl>>, List<double>, Func<int, double, bool, Bar<float>, long>>
wäre eindeutig zu lange und ... IMO einfach nur schlecht.
-
hustbaer schrieb:
Das erste aus dieser Liste. Ist einfach nur ne Beobachtung, sowas passiert schnell mal. Also ich sage nicht dass man sein Gehirn ausschalten sollte. Ich sage auch nicht dass das nur jemandem passieren kann der sein Gehirn ausgeschaltet hatte. Ich glaube ganz im Gegenteil, dass man sein Gehirn beim Refactoring für andere Dinge braucht, und daher schnell mal solche "Kleinigkeiten" übersieht.
Ok, dann passiert das gelegentlich. Dies sei zugestanden. Dann kann ich aber auch beim Ersten "stutzen" an dieser Stelle das var durch den Typ ersetzen...
Außerdem ist es fraglich, dass man so einen komplexen Generic einfach in eine Funktion versteckt und die Generik so einfach wegkapselt.
hustbaer schrieb:
...weil?
Weil ich nicht glaube, dass man so eine gewaltige generische Konstruktion benutzt und dann jegliche Generik über Bord schmeißt und das Ganze dann auf einen Typen festnagelt.
Ich würde erwarten, dass MakeTheSpecialFoo() selbst auch noch ein paar Typparameter hat. Den Sprung von totaler Generik in quasi statische Typisierung halte ich für unrealistisch.hustbaer schrieb:
Darüber könnten wir uns jetzt streiten.
Jederzeit.
hustbaer schrieb:
Sprechende Funktionsnamen sind gut, klar. Bloss irgendwo ist eine Grenze, und [...] wäre eindeutig zu lange und ... IMO einfach nur schlecht.
Ja, ein Name der die ganze Typisierung ausdrückt wäre zu "fett", aber ein Name der eine Ahnung vermittelt, was hier zurück kommt, kann deutlich kürzer und trotzdem sprechend sein.
Aber noch einmal der Kern meiner Aussage:
var nur auf anonyme Typen fest zu zurren, halte ich für zu extrem. Das geht schon in die "goto ist der Teufel-Ecke".
Ich stimme aber vollkommen zu, dass man var missbrauchen kann und damit die Lesbarkeit von Code deutlich verschlechtern kann.