Hi,
selbst hab ich damit keine Probleme, allerdings kann ich auch nicht erklären wie ich vorgehe da es einfach automatisiert/unbewusst passiert.

Wie geht ihr (gilt jetzt nicht nur für die Progging-Pros sondern auch Anfänger!) vor um zum Ziel (hier primär C++-Code) zu kommen?

€: argh! falsches Board,sry. möge ein Moderator so gnädig sein und verschieben...

O o
/¯¯/_o___o___o___o____o__
\__\¯¯o¯¯¯o¯¯¯¯¯¯o¯¯¯¯¯¯o
i'm doctoroctogonnafuckinggonnapus blaaaaaaaaaaargggggg-

Bei Aufgaben, die ich selbst noch erfassen kann, gehe ich folgendermaßen vor: Zuerst muss ich selbst das Problem verstehen. Dabei ist nicht wichtig, dass mir sofort der Gesamtprozess klar wird, sondern einfache Teilabschnitte entstehen (Modularisierung). Danach analysiere ich mein eigenes Verhalten im Sinne von, was täte ich, wäre ich der Rechner. Auch hier ist wieder nicht notwendig, dass ich das Probem tatsächlich löse. Es entsteht also eine art anthropologischer Algoritmus. Den in ein Programmcode zu übertragen, ist nur noch schreibarbeit.
Diese Methodik hat Haken. Oft wird das Programm aufwändiger. Das habe ich erlebt, als ich einen Sudoku-Löser gebastelt habe. Anstatt ein einfaches rekursives Verfahren mit zwanzig Zeilen anzuwenden, habe ich meinem Programm beibringen wollen, das Sudoku zu analysieren und nicht einfach so rumzuprobieren, bis es passt.

... und der große böse Wolf bootete und bootete und bootete ...
Optimiere deine Map, sieh dir alle Compile-Errors an, frage den Hersteller und beschwer dich über nichts!
http://www.mcscore.de.vu
13+3+7=23, 133/7+23=42

erstmal stellt man fragen im passenden forum, also dem coding-board

dann überlegt man sich: was für daten geb ich rein, welche will ich rausbekommen und wie erzeuge ich zweitere aus den ersteren. oder so.
generell gibt es vllt schon fertige algorithmen oder auch mathematische formeln/vorgehensweisen, das problem zu lösen, die man dann "nur noch" in code umwandeln muss.

ich bin jetzt von rel. einfachen problemstellungen ausgegangen, wie man sie z.b. im info-unterricht in der schule oder in anfänger-info-vorlesungen in der uni hat.

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

Bevor ich etwas anfange, denke ich erst über einen Lösungsweg nach, und wie ich diesen realisiere. Dann schreibe ich die Funktionen , die ich dafür brauche(bzw. es leichter machen) und dann gehts an den eigentlichen Algorithmus.

Music Artist / 2D Artist / Mapper

Recherche -> Brainstorming -> UML Diagramm -> Programmabschnitte -> Programm

"Everything, that can go wrong, will go wrong" Murphy's Law

Nachdenken -> Evolutionäres Prototyping -> Programm (oder auch nicht)

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Schreibt einer von euch bei komplexeren Programmen Struktogramme?

RIP tino579 ^^

Imho sind Struktogramme der größte Mist (selbst für kleine Programme). Um so ein Ding einigermaßen übersichtlich zu halten (zB Breite des Struktogramms) musst du dein/e Programm/Funktion eigentlich schon so konkret vor Augen haben, dass du keins mehr brauchst. Dann lieber einen kleinen Programmablaufplan geschrieben... Da kann man noch drin rumkritzeln wenn was fehlt und solang man dabei ein bisschen Sorgfalt walten lässt, sieht es auch noch annehmbar aus.

Zum Prozess des Programmeschreibens:
Ganz am Anfang kucken: Was hab ich? Was soll rauskommen? (Eingaben und Ausgaben definieren, evtl nen groben Umriss für Strukturen dieser anfertigen)
Dann kommt der wichtige Part: Was muss dazwischen passieren um von E nach A zu kommen? (Algorithmieren [-> Programmablaufplan])
Dann ne kleine Übersicht schaffen, wie man das ganze möglichst günstig auf einzelne Funktionen verteilt und danach einfach in $sprache deiner Wahl schreiben.

Speziell für den Fall OOP (hattest ja geschrieben C++) mache ich mir schon im ersten Schritt Gedanken über ein grobes Konzept der benötigten Klassen (Methoden, Member, Friends, Vererbung, etc).

Aber: Für simple Sachen wie Aufgaben von der FH setz ich mich einfach vor mein Codeblocks und schreibe drauf los. Die Probleme sind da immer so weit konkretisiert, dass die Lösungen eigentlich nahe liegend sind.

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Zitat:

Bluthund postete
Imho sind Struktogramme der größte Mist (selbst für kleine Programme).

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

Da geb ich mal ein fullack (meinte mit meinem Bezug auf Struktogramme die Nassi-Shneiderman-Diagramme)... Ich hör immer wieder UML. Ich glaub das muss ich mir auch mal ankucken =)

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

also ich mache dies seit vielen Jahren beruflich, jetzt keine PC und Büroanwendungen, sondern ich programmiere elektrische Steuerungen.

Letztendlich dürfte es aber Parallelen in der Arbeitsweise geben.

Unterschätzt den ersten Schritt nicht, die genaue Aufgabenbeschreibung. Wenn man für sich selbst was macht, ist dies ja etwas einfacher, da man i.d.R. weiss was man will..obwohl.. Kommt ein Kunde ins Spiel, ist das natürlich noch wichtiger. Hier sollten gleich die wichtigsten Eckpunkte ausgelotet werden, was soll das Programm überhaupt machen? wie schnell, wie oft, wo dürfen die Grenzen sein. Dürfen oder müssen sich Unterfunktionen blockieren oder muss einiges parallel ablaufen? Darf jeder user alles machen, oder müssen Passwortebenen generiert werden. Solche Fragen müssen zunächst beantwortet werden. Ich schreibe das alles auf und das Ganze nennt sich dann Pflichtenheft. Die Form ist eigentlich egal, ich bringe das in ausführlicher und gegliederter Textform zu Papier. Sinnvollerweise wird dann das fertige Pflichtenheft mit dem Kunden diskutiert, geprüft und freigegeben. Man glaubt nicht, wieviele Logikfehler und wieviel "aneinander vorbeidenken" sich dadurch schon im Vorfeld vermeiden lassen.

Die eigentliche Ausführung dann ist mehr oder weniger Routine, da hat wohl jeder unterschiedliche Vorlieben. ich breche das erstmal in einzelne, kleine Funktionen herunter und setzte diese dann auch sofort um. Zum einen kann man bei dieser Methode sofort beginnen, es ist übersichtlich und ich kann aus anderen Projekten sehr vieles evtl. nochmals verwenden und sofort austesten. Kompliziertere Abläufe erstelle ich zunächst als eine Art Blockdiagramm, ein karierter Block, ein Bleistift und ein Radiergummi sind dabei meine Freunde. Spezielle PAP-software ist nicht nur teuer, sondern behindert mich durch das lästige Handling auch beim Denken ;)

Insofern habe ich eigentlich einiges, was ich in Schule/Studium/Lehrgängen so an theoretischem Rüstzeug mitbekommen habe, unbewusst angewandt aber andererseits auch vieles einfach wieder über Bord geworfen. Ich denke mal, einfach das Machen, die Praxis formt die Arbeitsweise..und das bei jedem etwas anders.

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

wenn das projekt allerdings so groß ist, dass man mit mehreren dran arbeiten, sollte man sich schon auf ne diagrammform einigen, damit es für alle eindeutig ist

caedes

Deutschland rückt nach Einschätzung der Sicherheitsbehörden im Superwahljahr verstärkt ins Visier von Terroristen.

da stimme ich dir zu, das Problem stellte sich mir zum Glück nie :)

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW