Strucktugramme

[MAfuba]

Halli hallo ! Also ich frage mich wozu diese Dinger da sind ! :D
Ich lerne Pascale jetzt auch in der Schule und kann den Strucktugrammen nix abgewinnen. Ich finde mit den Dingern is alles viel komplizierter !
Kann mir das ma einer von euch hia schmackhaft machen ? ?(

[sami]

du meinst mit struktugramm doch dinger wie das da:
http://www.netzone.ch/jugi/sami/forum/strukto.gif

wenn ja:
- dann schreibt man die struktogramm
- dann gehört das posting ned ins pascal-forum

wenn nein:
- tut mir meine antwort leid :]

[MAfuba]

Na tut mir wirklich leid sami !!!!!
X(
Ich kenn die Dinger nur in Verbindung mit Pascale, aber wenn dich das so stört und das so tot ernst is hia und ich nich ma was fragen kann ( und wenn nich hia wo sonst ? ) dann lass ich es in zukunft ... !! cya
Danke für die konstruktive Hilfe !

[sami]

also die dinger sind halt - wie flussdiagramme - dazu da, den ablauf zu visualisieren.

wurde in der schule auch lange damit genervt, bis ich einsah, dass sowas wirklich nützlich ist.
bei programmen in der grösse, wie man sie normalerweise in der schule macht, sind sie eher sinnlos, aber das ist ja auch nur zum üben.
denn grosse programme kann man unmöglich im code im überblick hamn und n coder sollt ja zu jeder zeit an jedem punkt in seinem programm wissen können, welche variable welchen wert hat etc.
und sowas ist bei grossen programmen halt nur mit visualisierungen möglich.

kann mich gerne noch genauer mit dir darüber unterhalten :) aber muss jetzt weg, sorry
*winke*

[Manu]

Jopp, gehört auch ins "mehr..." Forum tät ich sagen...

Zum Thema.. wer hat denn behauptet, dass die Dinger so toll sind?
Ich find die nur langweilig.. und verkomplizierend.. :]

Cya && Moved

[MAfuba]

meine rede agentsmith !!!!! :D

[gencha]

also erstma sind struktogramme nich auf eine programmiersprache festgelegt. die gelten allgemein, logischerweise!
mal abgesehn davon sind sie einfach nur der allerletzte scheiss. wenn ich mal n kleinen code teil von mir in n struktogramm quetschen wollte bräuschte ich n blat von 10m breite und 50m höhe.
das einzige was wirklich was bringt sind PAPs (Programm Ablauf Pläne) ich hab aber leider kein bild da zur erklärung.

[Manu]

Meinst du vielleicht sowas:

http://www.boever.purespace.de/technik/for.gif

:)

[gencha]

jap, genau sowas :)

[Felix Kaiser]

Wer hatn den Mist erfunden? (:
Einfach irgendwie führt oft schneller zum Ziel als man glaubt, oft sogar über einen besseren Weg. Wie spielt hinterher keine Rolle, hauptsache schnell und effektiv und am Ziel angekommen.

[Bauchi]

sowas nennt man flowchart .. btw

[Codeq]

@ guru
nööö!!!
du hast noch nie im team oder an komplexen programmen mitgearbeitet! wenn du da irgendwie ohne struktur am ziel bist weiss der nächste dann nicht mehr wo er deine bugs zu suchen hat...
die wartbarkeit eines programms ist genauso wichtig wie die funktionalität !

[Felix Kaiser]

Der Coder wartet den Code, der is ja nicht für andere bei mir meistens. Hab aber schon für Studenten Codes gebastelt, bin da genauso herangegangen, hab vernünftige kurze Kommentare an entsprechenden Stellen gesetzt und man war dankbar für Übersichtlichkeit und Funktionalität ;)

[gencha]

f$% off! ein komplexes programm in n struktugramm oder ne pap zu pressen is schwachsinn aber TOTAL! wie große flipcharts gibts denn euch? 5 meter breit und n kilometer lang oder was. ich hab schon sooo billige, einzelne funktionen in nem kleinen programm geschrieben, die auf n blatt papier zu quetschen is echt ne rekordreife leistung. konzepte sind fürn arsch, man muss wissen was man will und dann codet mans, dann debugger durchlaufen lassen, fehler raushaun und die sache steht. da brauch ich mir nich vorher sone kriggelei aufzuhalsen.

[nj0y]

Wenn ich mir ein COBOL-Programm angucke, seh ich ein, wofür man Struktogramme braucht: Man blickt sonst einfach nicht mehr durch. Alles total unübersichtlich. Geht mir ähnlich mit Pascal/Delphi. Aber bei C/C++ les ich einen Sourcecode deutlich einfacher als ein Struktogramm.

Es kommt halt immer auf die Vorkenntnis/Gewohnheiten des Programmierers an. Wenn Delphi-Gurus einen Delphi-Code lesen, wird es ihnen ähnlich gehen wie bei mir mit C-Codings.

C ist übrigens nicht gleich C. Wenn die geschweiften Klammern hinter dem Funktionskopf/der if/while/...-Schleife aufgemacht werden statt dadrunter (schon tausendmal hier im Board gesehen), bin ich immer kurz vor´m Herzkaspar. Andere Leute kriegen das Flattern, wenn sie die geschweiften Klammern dadrunter sehen. Ich find´s einfach übersichtlicher, symmetrischer und einfacher lesbar. Alles Geschmacks- und Gewohnheitssache.

Und wer mit hundert Sprachen gleichzeitig programmiert und keine richtig beherrscht, kann auch in Struktogrammen programmieren und das Coden den Leuten überlassen, die Ahnung davon haben ;).

Ich halte es für eine Glaubensfrage. Außer in meiner Ausbildung hab ich noch nie ein Struktogramm gemacht und werde nach jetzigem Kenntnisstand auch nie eins freiwillig machen - während andere Leute einfach mehr Überblick haben, wenn sie erst eins machen.

[Felix Kaiser]

Hehe, ich kenn des gut, in einigen Sprachen ersetzt mein Gehirn bereits den Debugger ;) In Pascal, Delphi, Assembler benutz ich nur seltenst den Debugger und in vielen anderen Skriptsprachen vorallem haste ja keinen Debugger, siehe JavaScripts. Mit Struktugrammen wirds bei mir ähnlich sein wie mit Firewalls: Ich habs nich, ich hattes nie und ich werde nie haben 8)

[gencha]

amen

[Dominic Suter]

Möchte hier vieleicht auch noch etwas zur Diskussion anfügen:

Ich mache bei grösseren Programmen (Java) erst ein UML Diagramm. In disesem Diagramm werden schon viele Sachen (Klassen, Objekte, Verbindungen etc) definiert, ohne dass ich mich auf den Code stürzen muss. Sobald das Projekt grundsätzlich laufen sollte, ist die Projektierung in UML abgeschlossen. Nun hat mein UML-Editor die schöne Angewohnheit, dass er allen Quelltext, soweit möglich, schon erstellt, mir also eine Menga Tip-Arbeit abnimmt.
Den Rest auszucoden ist in der Regel auch keine grosse Sache mehr.

Aber zurück zu den Struktogrammen

Die Struktogramme erfüllen eigentlich genau denselben Zweck, jedoch für eine prozedurale Programmierweise.
Wer immer meint, dass all das nicht notwendig sei, der täuscht sich gewaltig. Wenn ein Programm nicht richtig funktioniert, wir der Fehler bestimmt viel eher in einem guten Struktogramm gefunden als im Quelltext, der möglichts noch aus einer Unmenge Files besteht!
In einem guten Struktgramm arbeitet man auch nicht mit km-Papier, dass möglicht DIN A0 haben muss, damit man eine Übersicht gewinnt -> Die ist hier schon wieder verloren. Viel besser man verwendet die Ebenen oder Layers (Hirarchie). Auf dem Top-Sheet sind dann nur ganz rudimentäre Programmabläufe aufgezeigt. Sobald man nun in einem Programmablauf etwas detailierter sehen will, geht man eine Ebene tiefer um über diesen Ablauf detailierter unterrichtet zu werden. Natürlich können auch hier wieder Blöcke mit Hirarchien gebildet werden. Aber eine zu grosse Tiefe kann das ganze auch wieder unübersichtlich machen.
Mein Struktogramm Pgm macht mir aus dem Struktogramm übrigens auch gleich den Source...

Und hey: Ein Programm mit einer Menge Files, in dem Ihr nach 2 Jahren etwas ändern müsst, oder das jemand anderes für euch tun sollte, dann seit Ihr um ein gutes Struktogramm und UML Diagramm 100% dankbar.
Soviel zu den Struktogrammen.


Wengen einem BAP oder Flussdiagramm: Die sind eigentlich veraltet und wurden durch die Flussdiagramme ersetzt...

[Patrik Graf]

Also, meiner Meinung nach ist der Scheiß zu nix gut. Ich musste auch Struktogramme zeichnen und fand es für viel Zeitaufwändiger als das ganze erst mal schnell zu coden, danach optimieren und Kommentare zu setzen. Beim Bugs suchen Breakpoints setzten und die Sache ist gegessen. Wenn ich etwas code, versuche ich erst mal alle Bugs rauszukriegen indem ich viele kleine Funktionen schreibe die eine Teilarbeit übernehmen. Das hört sich im ersten Moment unübersichtlich an, ist aber beim Fehlersuchen absolute Spitzenklasse. Man grenzt Funktion für Funktion ein und hat dann zum Schluß höchstens 10 Zeilen Code in denen der Fehler liegt. So hat man ruckzuck alles ausgemerzt. Und wenn ich erst mal Struktogramme mach, dann sitz ich da und Zeichne mich blöd weil ich den Scheiß auch noch in Schichten aufteilen muß und und und... PAP´s sind da genau so beschissen. Für ASM-Code sind PAP´s echt spitze, aber an sonnsten eigentlich für nichts im Coding-Bereich. Das Prob ist einfach, dass bis man den Scheiß gezeichnet hat, und dann noch die Bugs rausgefiltert hat und was weiß ich nicht was noch alles gemacht hat ist die Konkurenzfirma schon mit der 2. Version draussen die schon 20 mal besser ist als die, die an der man gerade coded... Wenns da ne andere Methode gäbe das Zeug schneller zu machen, wär´s bestimmt nicht schlecht. Aber so... :(

@Stoenggi:

So ein Proggi wie dein UML-Editor ist bestimmt nicht schlecht, aber das ist ungefähr das selbe wie der JBuilder von Borland. Wenn ich seh, was der mir da für´n Code einfügt, bekomm ich das große Kotzen und deshalb benutz ich ihn eigentlich nicht mehr so oft. Jeder hat seinen eigenen Programmierstil. Und mich erst mal umzugewöhnen auf einen anderen find ich scheisse.

[sami]

ich denk (bzw. weiss) dass im professionellen business weniger die zeit um es zu coden zählt als die "pflegeleichtigkeit" des codes und des ganzen projekts.
deshalb nimmt auch etwa die hälfte der ganzen zeit eines professionellen projekts die planung in anspruch und nur der rest das coden selbst...

[Dominic Suter]

@ Grafitty

Jedem das seine, aber ein grosses Pgm ist mit vernuenftigen Diagrammen schneller entwickelt, da eh zuerst ueberlegt werden muss, was man wie machen will.
Hier gilt halt auch die Regel, dass ich das Programm entwickle und nicht das Programm mich (mir also vorschreibt, was ich zu tun habe).
Zudem ist das beim prozeduralen Programmieren ein wenig ein kleineres Problem als beim Objektorientierten Programmieren, da Vererbungen etc. eine grosse Tiefe in ein Programm geben koennen, die ganz sicher nicht einfach so entstehen. Ein gutes Konzept kann hier viel Text und u.U. auch Zeit beim Programmablauf ersparen.

Die vorgenerierten Quelltexte sehen meiner Erachtens gar nicht so schlecht aus, klar, sie sind nicht so wie selbst gemacht, aber mit ein wenig Routine spielt das keine Rolle.

[Patrik Graf]

Ok, jedem das seine... :D aber ich bleib bei meiner Meinung das Struktogramme und das ganze Zeug nicht das Gelbe vom Ei sind :(

Wenn ich ein grösseres Projekt in Angriff nehme, mach ich das alles per Text, d.h. ich denk mir was aus und schreib´s auf damit ich´s nicht vergess. Der Rest kommt da wie von alleine und spielt sich bei mir nur im Kopf ab. Find ich die bessere Geschichte :))

[sami]

klar, für dich selbst, da ists egal, wie du es löst.
aber schonma was von projektgruppen gehört? oder nachfolger in ner firma?
will damit nur sagen: nur weil du (oder andere) es als einzelne ned nutzen, sollt man es ned alls überflüssig oder gar stumpfsinn abstempeln.

[Dominic Suter]

Ich schliesse mich da gerne Sami an. Musste bis jetzt 1x ein Projekt von einem Vorgänger übernehmen mit einer Dokumentation == 0. Wie sch... das ist, kansst du dir sicher ausmalen. Da ist oft fast einfacher, wenn du erneut bei 0 anfängst.

[Bibolorean]

Hab mal gehört, dass einige Firmen ergend so ein ISO-Zertifikat haben. :D
Dass Teil schreibt eigentlich vor, dass jede Arbeit bestens dokumentiert sein sollte.. ;(

Bei kleinen Lernaufgaben ist das recht lässtig, aber wie ihr (mehrheitlich) sagt, ist´s bei grossen Projekten schon recht nützlich! :]



Greetz Bìbòlorean