Denkansätze (Algorithmik? richtiges Vorgehen?)

[julchen]

Hallo,

habe dieses Thema Nächstes Datum errechnen gelesen und habe mir dazu ein paar Gedanken gemacht. Da ich häufig (leider) auch "irgendwelchen Unsinn" verzapfe wie StrToDate(DateToStr(Now)) - ich nehme das jetzt mal als Beispiel-Code, weil dieses Konstrukt am häufigsten "Angesprochen" wurde - würde ich gerne von den "Profis" wissen, wie man solche "Denkfehler" vermeiden kann? Vielleicht könnt Ihr eine Lösung posten und vielleicht einmal - für Anfänger und halb- bis wenigwissende wie mich - erklären, wie die vorgehensweise wäre, um so etwas zu lösen.
Ihr könnt auch ein anderes Beispiel nehmen, wenn es pädagogisch wertvoller ist - die Gedanken sind frei!!!
Mich interessiert besonders, wie ich Programmierwissen richtig anwende und wie ich "denken" muss, um ein Problem zu lösen.
Ich hoffe, Ihr versteht, worauf ich hinaus möchte

An die Mods:
Sollte hier etwas konstruktives bei heraus kommen, wäre es vielleicht gut, das Thema in eine andere Rubrik hinzuschieben, wo es dauerhaft erhalten bleibt. Das überlasse ich Eurem ermessen.

Mit vielen Grüssen
julchen

[edit=Phoenix]Titel mal etwas verbessert und das ganze nach Programmieren allgemein geschoben. Mfg, Phoenix[/edit]

[mkinzler]

Am Besten im Trockenen überlegen, wie man das Problem am Besten lösen kann ( z.B. auf einem Blatt Papier). Dort kann man auch einen Algorithmus auf richtige Funktion Testen ( Schreibtischtest)

[DeddyH]

Genau, geeignete Mittel wären der Programmablaufplan (PAP) oder das Struktogramm.

[Phoenix]

Zitat von julchen:

Da ich häufig (leider) auch "irgendwelchen Unsinn" verzapfe wie StrToDate(DateToStr(Now)) - ich nehme das jetzt mal als Beispiel-Code, weil dieses Konstrukt am häufigsten "Angesprochen" wurde - würde ich gerne von den "Profis" wissen, wie man solche "Denkfehler" vermeiden kann?

Okay, das ist ein grober Schnitzer.
Wer einen Datumswert in einen String konvertiert, nur um genau diesen String dann wieder in einen Datumswert zu konvertieren, der ist irgendwie merkbefreit. Natürlich funktioniert das. Nur ist 'StrToDate(DateToStr(now))' halt gleich 'now', und das kann man auch gleich hinschreiben.

Genauso der ganze Quatsch wie mit if boolscherAusdruck = true then oder fast noch schlimmer

Delphi-Quellcode:

if boolscherAusdruck then
  irgendwas := true
else
  irgendwas := false;

Was man ganz einfach mit irgendwas := boolscherAusdruck; machen kann.

Man sollte bei jedem Code den man schreibt hinterher nochmal einen guten Meter bis zwei nach hinten gehen, sich das in seiner Gesamtheit angucken und bei jedem Ausdruck fragen: Macht das wirklich Sinn? Ist das wirklich notwendig?

Oder noch besser: Solche Ausdrücke (seien es Konvertierungen, Vergleichsoperationen etc.) mal im Kopf (oder auf Papier) vollständig auswerten. Wenn man drüber nachdenkt was man macht, dann erkennt man solche unnötigen Operationen ziemlich schnell und kann sie vereinfacht darstellen. Das macht den Code übersichtlicher und damit später leichter Wartbar.

[SirTwist]

Wenn ich vor einem Problem hocke und nicht weiter weiß, hilft es mir oftmals, jemand anders (der auch programmieren kann) das Problem zu erklären. Es passiert mir dann regelmäßig, dass ich am Ende der Problembeschreibung auch die Lösung weiß. Man bedankt sich dann höflich fürs zuhören, schmunzelt über das WTF-Gesicht des anderen und geht weiterprogrammieren.

Ich denke das liegt daran, dass ich mir Mühe gebe, dem anderen das Problem möglichst verständlich zu erklären. Das dürfte ähnlich zu dem "mal ein paar Meter zurückgehen" sein, was Phoenix vorgeschlagen hat.

Gruß,
SirTwist

[mkinzler]

Das war ja auch mein Ansatz. Eine Lösung unabhängig vom Computer um zuerst einen allgemeinen Lösungsnsatz zu entwickeln.

[kalmi01]

Zitat von Phoenix:

Wer einen Datumswert in einen String konvertiert, nur um genau diesen String dann wieder in einen Datumswert zu konvertieren, der ist irgendwie merkbefreit. Natürlich funktioniert das. Nur ist 'StrToDate(DateToStr(now))' halt gleich 'now', und das kann man auch gleich hinschreiben.

Na ja, so ganz korrekt ist das nicht immer. Manchmal gibt auch Unsinniges einen Sinn.

In einer anderen Programmierumgebung verwende ich manchmal ein ähnliches Konstrukt: FloatToInt(IntToFloat(Zahl))
Auf den ersten Blick reichlich dämlich, ABER bei der Konvertierung IntToFloat werden Buchstaben/Zeichen ausgefiltert. Ich erhalte also IMMER mindesten 0 (null) als Rückgabe. Null führt bei der Berechnung zwar nicht zu einem Sinnvollen Ergebnis, verhindert aber den Absturz.
Was in einer Programmierumgebung, in der es kein try except-Konstrukt gibt, schon Sinn macht.

[mkinzler]

Now ist aber definitv ein korrekter DateTime-Wert

[kalmi01]

stimmt, aber dieser Vor-Zurück-Konvertiererei ist in diesem Thread doch nur ein Beispiel für (angeblich) unsinnigen Code.

[fkerber]

Hi!

Zitat von SirTwist:

Wenn ich vor einem Problem hocke und nicht weiter weiß, hilft es mir oftmals, jemand anders (der auch programmieren kann) das Problem zu erklären.

Ich ziehe hier meist sogar jemanden vor, der eben gerade nicht programmieren kann, da es manchmal die dämlichsten Sachen sind, die man übersieht und die ein anderer Programmierer dann auch mit "äh, das war ja wohl klar" abtut. Ein "Laie" fragt da schonmal eher nach...


Ciao, Frederic