Das deutsche QBasic- und FreeBASIC-Forum

[Helli M.]

Hallo an Euch!!

Ich hab in einigen Tutorials gelesen, dass ein bestimmter Befehl zwar möglich ist, aber das ist nicht elegant...
Was ist "elegant programmieren"??
Ist es nicht das Ziel, dass es klappt, und nicht, wieso es klappt??
Ich meine, zb. Ich spiele mich noch immer mit einfachen Übungen herum, und dabei wollte ich alle Möglichkeiten in Betracht ziehen, was soll passieren, wenn ich frage "Wie gehts dir, (g) oder (s)chlecht?"
und man gibt außer g,G,s,S einen anderen Buchstaben ein, ist es dann "unelegant", wenn ich mit case select arbeite??
Wenn ja, warum eigentlich??
Nach welchen Kriterien entscheidet sich, ob ein Code "elegant" ist??
(Ich hab vielleicht Probleme....! )
Bitte, wei(c)ht mich ein, in dieses Geheimnis!!!
Elegante Grüße
sendet Euch
Helli

[Jan]

moin

unelegant find ich den GOTO befehl.

was hast du denn an SELECT CASE auszusetzen??

[Helli M.]

Hi Jan!!!

Wieso findest Du den GOTO unelegant??
Das ist es ja was ich begreifen möchte??

Und an select case hab ich überhaupt nix auszusetzen, eigentlich hab ich an keinem einzigen Befehl was auszusetzen... höchstens es geht nicht so wie ich will!!!

Tschüssi
Helli
_________________
Wieso einfach, wenn's auch kompliziert geht?!

[Gremlin]

Hi.

Mal ein kleines Beispiel:

Anstatt

[Sebastian]

Hallo.

Hierbei muss man seinen eigenen Programmierstil finden. Die Entscheidung, ob man IF oder lieber SELECT CASE benutzen sollte, ist oft eindeutig, aber manchmal kann man in einer "Grauzone" wählen.
Mit etwas Programmiererfahrung entwickelt man automatisch seinen eigenen Programmierstil. Dazu gehören auch Einrückungen usw.
In dem obigen Fall finde ich SELECT CASE "hübscher", aber das ist Ansichtssache.

Zum GOTO. GOTO ist in eigentlich allen Sprachen (ausgenommen Batch ) verpönt. Seine Benutzung bringt oft scheußlichen Spaghetti-Code zustande, durch den niemand mehr wirklich durchsteigt. Dadurch wird auch für den Programmierer selbst das Fehlersuchen und das Erweitern/Ändern des Codes schwieriger.
GOTO lässt sich eigentlich immer vermeiden. Allein schon die Regel auf GOTO zu verzichten, bringt schon ein ganzes Stück "Eleganz" in deine Programme.

Ein "elegantes" Programm ist gut strukturiert und der Quelltext lässt sich mit möglichst wenig Anstrengung überblicken und verstehen.

Einrückungen und Absätze sind ein absolutes Muss. Gremlin hat das mit den Einrückungen (ausgenommen beim Zeilennummernbeispiel) sehr gut gemacht.

Großes Kopfzerbrechen muss man sich über dieses Thema aber nicht bescheren. Man findet auf kurz oder lang meistens selbst heraus, wie man am schönsten/elegantesten programmiert.

Viele Grüße!
Sebastian
_________________

Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!

[Paul]

Ihr mit euren Einrückungen

Absätze müssen natürlich sein, das geht garnicht anders

Aber Einrückungen empfinde ich als sehr lästig, kommentare mit REM sowieso.
Das einziege was ich mir mal angewöhnt hab, ist allerhöchstens 1 Leefzeichen bei Schleifeninhalten, aber mehr auch nicht

Ich komm trotzdem gut mit meinem Code klar
_________________

[Gremlin]

Wenn ich ein Programm schreibe, dann vergess ich für gewöhnlich auch alle Richtlinien (<> Regeln).

Aber ich gehe den Code danach normalerweise auch nochmal durch und trenn dann alles ein wenig und rücke nachträglich ein.
(Grobe Struktur habe ich schon beim Schreiben)

Aber ich denke, wenn, dann grade bei solchen Beispielen, die für andere, z.T. unerfahrene Programmierer (die Antwort ist ja nicht nur für Helli) gedacht sind, sollte man schon Einrücken.
_________________
Tja, hier konnte ihre Werbung stehen.
Pech gehabt.

[Sebastian]

Hallo.

Einrückungen sind sehr wichtig und bei längeren Codes absolut unumgänglich, damit je wieder jemand den Code vernünftig lesen kann bzw. du selbst nach 2 Wochen noch durchsteigst.

Viele Grüße!
Sebastian
_________________

Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!

[Jan]

Mensch, mensch, mensch.

Ihr habt Probleme tztztz

[E-P-S]

Hi...

also ich stimme Sebastian voll zu. Jedoch muß ich sagen das ich auch meine ersten Programme (auch größere wie z.B. JUMPER) noch mit GOTO und wenig Übersicht gemacht habe.

Es hat Jahre gebraucht einen "Stil" heraus zu arbeiten der vor allem eins ermöglicht...den Code auch noch in 5 Jahren zu verstehen.

Wichtigste Regeln hierbei (für mich): Einrücken um Strukturen in Schleifen und Abschnitte zu bekommen und zum Anderen REM Zeilen die beschreiben was welcher Abschnitt genau macht.

REM Zeilen tun niemanden weh - aber in 5 Jahren bis du umso dankbarer damals einen Vermerk gemacht zu haben wenn du nach einem kleinen, fiesen und meist lästigen Bug suchst. Ganz zu schweigen davon das viele Codes ja Freeware sind und auch andere ihn "lesen" können sollen.

Trotzdem denke ich das früher oder später - meist proportional mit dem Umfang des Projektes und der KB an Quellcode - diese Einsicht und Gewohnheit (Routine) von alleine kommt.
_________________
Man kann sich öfter als zweimal im Leben halb tot lachen.

[Sebastian]

Hallo.

Genau.

Mit dem Kommentar zu REM-Zeilen meinte er glaube ich auch nur, dass das Apostroph irgendwie hübscher ist als REM.

Viele Grüße!
Sebastian
_________________

Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!

[Mecki]

Huhu,

Auf alle Fälle ist es praktischer, weil man z.B. keinen Doppelpunkt davor setzen muss, wie es bei REM der Fall ist.

Lustig: Ich hatte mal nen Fehler entdeckt: und zwar:

wenn man schrieb

[dreael]

Eine Software sollte auch immer die Kriterien der Wartbarkeit erfüllen, daher ist Software-Design ebenso wichtig wie eine funktionierende Implementation.
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[helium]

[Paul]

[Jan]

wichtig ist auch, dass du deinen variablen schön aussagekräftige namen gibst.
Dann was man immer, welche variable gerade was speichert.

[Dusky_Joe]

Für Eleganz gibt es bei mir eigentlich zwei Definitionen, die je nach Aufgabe gültig sind.
Wenn einfach nur darum geht, ein Programm zu schreiben, dass für den User nützlich sein soll, muss der Code seine Aufgabe SCHNELL und mit MÖGLICHST WENIGEN ZEILEN bearbeitet.
(Das erste ist meistens die Folge des zweiten).
Übersichtlichkeit ist in erster Linie einmal Nebensache.
Beispiele:
statt
IF a <> 0 THEN
PRINT "Wert wird geprüft..."
CALL TESTWERT
END IF

ist es in dieser Bedeutung eleganter, zu schreiben

IF a THEN PRINT "Wert wird gerprüft": TESTWERT

Der Unterschied zwischen den Beiden Codes liegt einfmal darin, dass a nicht mehr mit 0 verglichen wird, dass die CALL-Anweisung wegfällt, und dass der IF-Block in eine einzige Anweisung gepackt wurde.
Auf diese Art lässt sich auch der Quellcode kleiner halten. Sicher, hier spart man nur (*nachzähl*) 21 Bytes, aber sobald das Programm einmal größer wird, (sobald es sich eben rentiert, so zu optimieren) macht das doch etwas aus. Etwa 48 auf diese Weise vereinfachte IF-Blöcke machen dann ein KB aus. Auf diese Zahl kommt man ziemlich schnell, denke ich. (Gut, öfter wird wohl SELECT-CASE drankommen...)
Ob sich das dann auch auf das compilerten Prog auswirkt, habe ich noch nicht ausprobiert, aber so weit ich mich in ASSEMBLER auskenne, dürfte zumindest ein kleiner Effekt spürbar sein.

Elegant kann aber auch sein, dass das Programm besonders leicht nachzuvollziehen ist.
Das kann dann schon bedeuten, dass man genau das Gegenteil macht, von dem, was ich oben beschrieben habe.
Über Einrückungen in Schleifen lässt sich streiten, ich jedenfalls komme besser mit ihnen klar, vor allem weil ich oft so viele Schleifen ineinander Schachtele, dass ich Kopfweh vom nachvollziehen bekomme.... (vielleicht sollte ich das auch Eleganter lösen?)
Das selbe gilt für Absätze.


Wie lässt es sich jetzt also anstellen, dass man ein Prog in beiden hinsichten Elegant ist?
Gar nicht.
Die einzige Möglichkeit ist, zwei Versionen zu schreiben, bzw sein Prog nach der Entwicklungsphase (vor dem Compilern) umzuschreiben.

Tja, so sehe ich das auf jeden fall.
Post what you think

Have a nice Day - Ciao!
_________________
fully biological degradable

Once, the big wave arrives, you've got two ways, you can go:
Either, you ride it, or you don't do.
But, if you don't ride, you'll never know wether you'd have gone wet.

[stef]

Warum man elegant programmieren können sollte? Kann ich Dir sagen. Stell dir mal vor Du stehst vor dem Personalchef und er fragt Dich:
"Es gibt doch so viele Programmierer. Warum sollten wir gerade sie einstellen?"
Jetzt könnte man antworten: "Na ich schustere irgendwie meine Programme zusammen und zum Schluß laufen sie. Aber fragen sie dann bloß nicht wie."

Oder die Antwort könnte lauten (ohne dabei zu ausschweifend zu werden):
"Ich arbeite nach den heutzutage anerkannten und ausgereiften Regeln der Softwareentwicklung. Ich habe mir angewöhnt den den Aufwand in meine Programme zu investieren, daß sie übersichtlich und gut strukturiert sind. Damit spart man viel Zeit, wenn Fehler gesucht werden müssen oder das Programm später erweitert oder verändert werden soll. Außerdem ist diese Art der Programmierung sehr nützlich wenn man ein Programm in Teamarbeit entwerfen muß."

Ich habe schon gehört, das es Programmierer gibt, die mit der Ausrede ihr Programm wäre zu langsam, wenn sie ordentlich programmieren. Meinentwegen, dann ist das bei denen halt so. Deren Programm fallen dann unter die Rubrick: Kann nicht mehr erweitert werden weil keiner mehr sich in dem Programm zurecht findet. Ich hoffe nur, das ich nicht der Depp bin, der genau das dann versuchen soll.
Andererseits habe ich gehört das im Linux-Quellcode haufenweise goto-Befehle gibt aus genau diesem Grund.

Ich habe jedenfalls keine Probleme das meine Programm zu langsam wären, weil ich sauber programmiere. Das Einrücken ist nun wirklich kein großer aufwand. Das hat man sich sehr schnell angewöhnt. So ist es mit den meißten Dingen beim eleganten Programmieren.

Na gut hier mal alles was mir so einfällt zum Thema elegantes Programmieren, was ich mir so mit der Zeit angewöhnt habe und bestimmt nicht so schnell abgewöhnen werde:
Füher als ich es noch nicht besser wußte bin ich mit goto immer kreuz und quer durch meine Programme gehüpft, bis ich in meinen eigenen Programmen mich nicht mehr auskannte. Mitlerweile habe ich diesen Befehl schon seit Jahren nicht mehr verwendet und ich finde es sehr löblich, das in moderen Programmiersprachen wie Jave dieser Befehl nicht mehr gibt.

Dann solle man die Einzelnen Arbeitsschritte in Funktionen und Subs auslagern, anstatt ein riesiges unübersichtliches Programmmonstrum zu erschaffen. Gerade das nicht verwenden von Unterprogrammen ist eine der Heufigsten Schwächen vieler Programmierer finde ich. Erst vorhin hatte ich ein Aufgabe und habe mir gesagt, das hast du doch schon mal gelößt. Ich mußte nur die Funktion rüber kopieren und einen Funktionsaufruf in mein Programm einfügen. Vieleicht hatte ich damals ein wenig mehr aufwand, denn habe ich jetzt aber garantiert eingespart.

Das war eigentlich schon das wichtigste. Kommentare können auch nicht schaden und sind manchmal unerläßlich. Zum Beispeil explodierte vor ein paar Jahren eine Ariane 5 Rakete kurz nach dem Start. Der Grund war ein Softwarefehler. Es wurde eine Funtion einer Ariane 4 Rakete übernommen, die als Parameter den Treibstoff in Gallonen benötigte. Nun wurden aber amerekanisch mit britischen Gallonen verwechselt und die Funktion berechnete das falsche. Hätte man nur dazu schreiben müssen.

Da es hier angesprochen wurde will ich auch zu Select-Case was sagen. Ich habe gehört, daß es Leute gibt, die Select-Case nicht mögen. Das ist deren Problem. Was ich aber unverantworlich halte, ist das sie versuchen Select-Case als schlecht darzustellen. Es ist ein sehr gutes Werkzeug um den Code übersichtlicher zu machen und ich verwende es immer wieder.

[helium]

[stef]