Denkansätze (Algorithmik? richtiges Vorgehen?)

[lincore]

Zitat von julchen:

Hallo,
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 :gruebel:

Moin Julchen,

ich spare mir die Tools und praktischen Hinweise, die bereits so zahlreich erwähnt worden sind und komme gleich zum Kern meiner Aussage:
Was das vielgepriesene logische Denken anbelangt, entwickelt sich das glaube ich mit der Zeit von selbst. Ich habe mit neun Jahren angefangen, einem Second-Hand Spectrum ZX-81 (mit 16K RAM! :) meine Spielewünsche mit Basic einzubleuen (und das immer wieder, weil ich nicht begriffen hatte, wie man diesen dämlichen Kassettenrecorder benutzt um die Programme zu speichern und zu laden). Seitdem habe ich mich mit dem Programmieren als Hobby beschäftigt, und auch wenn ich diese gewisse "professionelle Barriere" nie durchbrochen habe, glaube ich, dass mir allein das langjährige Tun geholfen hat, besser logisch zu denken und Fehler zu vermeiden. Bestimmt lacht mich jetzt jeder Taschenrechner aus, aber für meine Zwecke reicht es. Die Welt der Computer ist nunmal eine gänzlich andere als die Unsere, in die man sich erst einmal einleben muss; Da sollte man keine Wunder erwarten oder zu verdächtig wohlklingenden Pillen greifen.

Und so peinlich dir besagte Quellcodezeile auch sein mag: sie ist völlig harmlos, wird wahrscheinlich sogar wegoptimiert.
Kleines Plus: Du wirst diesen Fehler nie wieder machen :)
[Edit: Wenns denn deiner gewesen wäre]

Schönes Wochenende,
lincore

[julchen]

Hallo,

erst einmal DANKE für die Antworten.

Ich habe irgendwie nicht das Gefühl, hinter das "Geheimnis" der Programmierung zu kommen,
wie ich meine Ideen und Vorstellungen in praktischen Code umsetzen kann.
Das liest sich jetzt blöd - und ist es auch.
Aber ich kann´s auch nicht besser beschreiben.
Wahrscheinlich bin ich einfach nur zu blöd, den ganzen Scheiss zu kapieren.

Viele Grüsse

[mkinzler]

Das glaube ich nicht.
Man muss nur versuchen, das Problem zu zerlegen und nicht zu kompliziert zu denken

[kalmi01]

Zitat von Julchen:

Wahrscheinlich bin ich einfach nur zu blöd, den ganzen Scheiss zu kapieren.

Mit blöd hat das absolut garnichts zu tun.
Manche können malen, Andere können musizieren und wieder Anderen macht es Spass wehrlose Nullen und Einsen in der Gegend rum zu schubsen.
Das schöne daran ist, das sich diese Talente und Interessen im Laufe der Jahre verschieben können.
Wenn mir vor 2 Jahren jemand gesagt hätte, das ich mal freiwillig eine sauschwere Fremdsprache nur so aus Spass am Lernen, lernen würde, dem hätte ich einen Vogel gezeigt.
Vielleicht platzt bei Dir ja auch irgendwann mal der Knoten und wenn nicht, auch egal, wenn man das was man tuen muss, so gut tut, wie man kann.

[lincore]

Hm,

also wenn es ein Geheimnis gibt, dann kenne ich es nicht. Es ist bestimmt so, dass es manchen Menschen leichter fällt zu abstrahieren und "logisch zu denken". Aber das heißt noch lange nicht, dass der Rest nicht programmieren könnte. Dann wäre dieses Forum so leer wie ein dreckiges Bierglas in einer stürmischen Herbstnacht.

Fehler kommen nunmal vor; davon weiß ich ein Lied zu singen. Wenn ich zum Beispiel den Beat eines Songs mit einem leichten Kopfnicken akzentuiere und dabei eine Funktion schreibe, die auf ein Array von Zeigern zugreift oder etwas ähnlich Gefährliches tut, kann ich mich jetzt schon darauf einstellen, dass ich erst einmal eine Exception um die Ohren gehauen bekomme wenn ich es wage, das Programm auszuführen. Mit ständiger Übung und verbesserter Konzentration verschwinden die meisten Fehler wie von selbst (und machen Platz für neue).

Zudem sollte man sich bemühen, die Grundlagen lückenlos zu kennen, um voraussagen zu können, wie sich ein bestimmter Code verhalten wird. Bestes Beispiel hierfür ist der beliebte "Fence Post Error": Wer nicht weiß, dass das erste Element eines Arrays den Index 0 hat, wird beim Zugriff auf letzte Element eine hübsche Überraschung erleben - und nicht wissen wieso.

Um einen Aspekt der Programmiersprache zu begreifen, sich mit einer unbekannten Komponente anzufreunden oder einen Algorhythmus auszuprobieren, ist es außerdem eine gute Idee, eine kleine (Konsolen-)Anwendung ohne zusätzlichen Schnick-Schnack zu schreiben. So stellt man sicher, dass man alles verstanden hat und die Syntax beherrscht. Das ist gerade zu Beginn eines neuen Projektes ratsam, weil man damit einen Überblick über den Aufwand und die Machbarkeit erhält.

Falls Delphi deine erste Berühurung mit der "Kunst" des Programmierens ist, wäre es übrigens bestimmt keine schlechte Idee, ein gutes Buch zu lesen (Auflistung von Amazon), das nicht nur Delphi selbst, sondern auch allgemeinere Aspekte von Computern und Programmiersprachen beschreibt. Wie bereits geschrieben kannst Du den elenden Zustand des "Im Trüben fischens" nur verlassen, indem Du verstehst was Du tust und was der Computer tut. Wissenslücken können sich mit etwas Pech jahrelang verstecken und immer wieder zu Kopfschütteln und Resignation führen.

Nun zum Thema "Wie muss ich denken, um ein Problem zu lösen?"
In diesem Thread hat jemand geschrieben, man solle Aufgaben in Teilaufgaben zerlegen. Das ist die ganze Magie. Man zerlegt etwas so lange in Teilaufgaben, bis jede dieser Aufgaben mit einer Zeile Code dargestellt werden kann. Zudem muss man sich klar machen, wie man diesen Code strukturieren möchte. Mehrfach wiederverwendeter Code gehört zum Beispiel in eine Funktion/Prozedur, weil mehrfach vorhandener Code auch mehr Aufwand und Fehleranfälligkeit mit sich bringt. Für Klassen wiederum ist es wichtig, die innere Funktionsweise zu verbergen und dem Klienten nur eine möglichst universell einsetzbare Schnittstelle zur Verfügung zu stellen.

Wenn ich eine Funktion schreiben möchte, die einiges Nachdenken erfordert, öffne ich gerne mal eine Textdatei und schreibe den Namen der Funktion und was sie tun soll. Dann überlege ich mir, was dafür getan werden muss und schreibe das nieder. Zuletzt zerlege ich die Teilaufgaben in Pseudocode, der (fast) 1:1 in Delphi umsetzbar ist.

Beispiel:

Code:

function TGenericArray<T>.insert
(Methode der Klasse TGenericArray<T>)

Aufgabe:
Mit der Methode insert kann ein zweites TGenericArray<T> in self eingefügt werden. <index> beschreibt hierbei die erste Position im Array, ab der das zweite Array eingefügt wird. Die Parameter <from> und <til> begrenzen die einzufügenden Elemente des zweiten Arrays

Ablauf:
- Auf Zulässigkeit der Parameter prüfen
- Benötigte Plätze im Array bestimmen und in Variable <space> zwischenspeichern
- Methode rearrange mit <space> und <index> aufrufen, um den benötigten Platz zu schaffen (die folgenden Elemente nach hinten schieben)
- Durchlaufe alle einzufügenden Elemente des zweiten Arrays und füge sie in dieses Array(self) ein.

Globale Variablen/Konstanten:
TGL_TOP_OF_LIST     =     -255;

Lokale Variablen: 
space (integer) speichert Zahl der benötigten freien Plätze
i (integer) Schleifenzähler

Parameter: 
einzufügendes TGenericArray<T>, 
<index> ab dem Einzufügen ist,
<from>, <til> geben den Bereich des zweiten Arrays an, der eingefügt werden soll

Pseudocode:
- Falls <from> oder <til> = TOP_OF_LIST dann setze <from> bzw. <til> gleich self.count() - 1
- Falls (<from> oder <til>) größer sind als self.count() - 1 oder kleiner sind als 0 dann
    - Verlasse die Funktion mit dem Ergebnis false
- Setze <space> gleich <til> - <from> + 1
- rufe rearrange(<index>, <space>, insertion = true) auf
- von [i] bis [i] + <space> - 1 tue dies:
    - dieses Array[i] is gleich zweites Array[from + i - index]

Und hier das Ergebnis:

Delphi-Quellcode:

// inserts a portion of another TGenericArray at <index>. The range of the
// included TGenericArray is determined by the <from> and <til> parameters.
// Returns true when successful.
function TGenericArray<T>.insert(list: TGenericArray<T>; index: integer = TGL_TOP_OF_LIST;
  from: integer = 0; til: integer = TGL_TOP_OF_LIST): boolean;
var
  i: Integer;
  space: integer;
begin
  if from = TGL_TOP_OF_LIST then from := list.high();
  if til = TGL_TOP_OF_LIST then til := list.high();
  if (from < 0) or (from > list.high()) or (til < 0) or (til > list.high()) or (til < from) then        
  begin
    result := false;
    exit();
  end;
  space := til - from + 1;
  auxRearrange(index, true, space);
  for i := index to index + space - 1 do
    mArray[i] := list.data[from + i - index];
end;

Es ist immer gut, solche Dinge aus der Abstraktion zu locken, in die Wirklichkeit zu bannen und damit (be)greifbar zu machen. Wäre ich nicht so unsäglich faul, würde ich mich für solche Aufgaben bestimmt an den Schreibtisch setzen und eine Mindmap machen. Sowas hilft dabei, den Kopf wieder zu entwirren und Ziele und Hürden klar aufzustellen.

Als Letztes möchte ich dir raten, so viel Code zu lesen wie Du kannst. Davon kannst Du eine Menge lernen. Versuche den Code zu verstehen, was tut er? Was macht diese Funktion? Warum ist die Klasse so aufgebaut? Um an guten Quellcode zu gelangen, bietet sich nicht nur das OpenSource-Forum hier bei dp an, auch Google-Code ist eine gute Quelle - wenn man weiß wonach man sucht.

Ich hoffe mein Geschwafel war in irgend einer Weise hilfreich. Viel Erfolg mit Delphi etc.,
lincore

PS: Statt nach dem Stein der Weisen zu suchen wäre es vielleicht besser, an tatsächlichen Problemen zu wachsen. Gib dafür am besten ein Beispiel mit Code zum Besten, sofern vorhanden. Daran sollte sich manches besser erläutern lassen.

[julchen]

Danke für Deinen Text