Hallo,
ein Kollege liebt es seine IF Statements -auch die der aller einfachsten Art so zu formulieren:
if korrekte-eingabe
continue
else
errorhandling
end-if
ich aber bin ein freund der einfachen zeilen und übersichtlichkeit:
if not korrekte-eingabe
errorhandling
end-if
a. was ist eure meinung dazu?
b. ist a. performanter?
Vielen Dank für rat und Tipps!!!
Grüße
Cess
PS Umgebeung ist IBM Großrechner/OS390/MVS
ein Kollege liebt es seine IF Statements -auch die der aller
einfachsten Art so zu formulieren:
if korrekte-eingabe
continue
else
errorhandling
end-ifich aber bin ein freund der einfachen zeilen und
übersichtlichkeit:
if not korrekte-eingabe
errorhandling
end-ifa. was ist eure meinung dazu?
b. ist a. performanter?
Hi Hans,
deine Variante ist schneller, einfacher.
Bei If-Else sollte in den If-Zweig das was häufiger eintritt, in den Else-Zweig das was seltener auftritt, insofern hat dies dein Kollege richtig gemacht, aber If-Else ist hier nicht angesagt, If reicht.
Gruß
Reinhard
a. was ist eure meinung dazu?
Der Ausdruck deines Kollegen weist eine Redundanz auf; man könnte argumentieren, dass dadurch der Wille des Programmierers für dritte leichter ersichtlich wird - quasi selbstkommentierender Code.
b. ist a. performanter?
In dieser
PS Umgebeung ist IBM Großrechner/OS390/MVS
Umgebung ist beides gehuppst wie gesprungen, du kannst davon ausgehen, dass der Compiler den Continue-Zweig deines Kollegen herausoptimiert.
Gruss
Schorsch
Hallo,
theoretisch ist die Überlegung zwar richtig, aber selbst bei einem Embedded Prozessor ohne Optimierung (Waschmaschine o.ä.) ist das nur ein einziger zusätzlicher Sprungbefehl, was in der Praxis nie ins Gewicht fällt.
Bei einem optimierenden Compiler spielt es sowieso keine Rolle.
Mich würde höchstens stören, dass es mehr Schreibarbeit ist.
Gruss Reinhard
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo.
ein Kollege liebt es seine IF Statements -auch die der aller
einfachsten Art so zu formulieren:
Das ist auch mir sympathischer hinsichtlich der systematischen Vorgehensweise. Begründung : In einer Umgebung, in der üblicherweise nach dem Kaskadenmodell entwickelt wird, weiß man (die Lebensdauer von Programmen kann die des Programmierers wesentlich übersteigen!) meist nur für einen begrenzten Zeitraum, wie die Bedingung oder auch das Errorhandling später einmal aussehen wird. Wenn der If-Zweig Deines Kollegen auch nur den kleinsten Inhalt bekommt, ist diese Variante Deiner an Übersichtlichkeitt überlegen.
ich aber bin ein freund der einfachen zeilen und übersichtlichkeit:
Beispiel in COBOL (hoffentlich habe ich die syntax noch drauf!)
IF sys030-status = status-ok.
PERFORM ALLESKLAR.
ELSE.
PERFORM ERROR030.
END-IF.
Das ist selbsterklärend und kann auch in 10 Jahren noch gewartet werden.
Nach Deiner Philosophie :
IF sys030 status-ok.
PERFORM ERROR030.
END-IF.
Das wirft mehrere Fragen für den Wartungsprogrammierer auf : Wie sieht der Ausgang von „ERROR030“ aus? Hält das Programm an, ist alles in Ordnung; springt es zurück, wird mit einem undefinierten Error-Status (status-ok war fehlerhaft; die Error-Routine dafür ist aber schon abgearbeitet!) weitergearbeitet. Entweder verändert man den Error-Status an dieser Stelle hartcodiert (was ganz schlechter Stil wäre), oder aber das Status-Flag ist an dieser Stelle wertlos (was ganz schlechter Stil wäre).
Insofern ist die Variante
IF sys030-status = status-ok.
REM der macht gar nix
ELSE.
PERFORM ERROR030.
END-IF.
ein wenig aufwendiger, aber sinnvoller. Die Performance wird dadurch, dass der ELSE-Zweig tatsächlich die Ausnahme darstellt, nicht wesentlich beeinträchtigt (sofern wir mal als gegeben annehmen, dass der Normalfall die Fehlerfreiheit ist!). Dieses Segment kann auch dann, wenn sich die Rahmenbedingungen ändern, unangetastet bleiben - die Intelligenz steckt im jeweiligen „OK“- oder „NICHTOK“- Paragraphen.
Ich würde jedenfalls das Programm Deines Kollegen als wesentlich wartungsfreundlicher einstufen …
Gruß Eillicht zu Vensre
Hallo, ehrlich gesagt,
verstehe ich überhaupt nicht, was du mir hier sagen möchtest.
wenn ich mit if einen zustand abfrage un dmit end-if abschliesse,
und es keine else gibt,w as will man mehr?
andersherum muss man doch erstmal fragen, also wenn das if zutrifft, mache nichts und sonst mache was und man stellt sich die frage, in welchem fall mache ich denn jetzt was?
so ist zumindest meine denkweise.
versteht man das?
grüeß cess
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
hallo, es wird sicher nicht ins gewicht fallen,
es ist eine prinzipielle frage, die ich mit der performance stelle.
grüße
cess
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
danke!
aber ist der wille wirklich einfacher zu interpretieren?
grüße
Cess
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
danek und grüße
cess
ähm wenn du eh nur die antworten annimmst die so sind wie du sie haben willst warum stellst du dann überhaupt eine frage ?
Ich bin nicht besser 
aber wenn mir die antworten eh nicht gefallen werden stelle ich die fragen erst garnicht.
gruß
Phillip
danek und grüße
cess
ähm, wie bitte?
nichts falsches hier interpretieren!
konkrete fragen, sehr gerne…
grüße cess
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Hans-Cess,
ein Kollege liebt es seine IF Statements -auch die der aller
einfachsten Art so zu formulieren:
if korrekte-eingabe
continue
else
errorhandling
end-ifich aber bin ein freund der einfachen zeilen und
übersichtlichkeit:
if not korrekte-eingabe
errorhandling
end-ifa. was ist eure meinung dazu?
b. ist a. performanter?
Zuerst zu b.: ‚Performanz‘ im
zusammenhang mit ‚Eingabe‘ ist
vollkommen irrelevant.
Zu a.: die Version des Kollegen
ist auf jende Fall zu bevorzugen,
wenn es sich um ein großes Soft-
waresystem mit wechselnden War-
tungspersonen handelt.
Deine Version ist ‚obfuscated‘ und
kann sehr leicht zu Missinterpre-
tationen führen, wenn der Wartungs-
programmierer eine kurze Nacht hatte
Denn:
if korrekte-eingabe
continue
else
errorhandling
end-if
ist praktisch ein „Idiom“, das man
auch im Schlaf versteht, während
if not korrekte-eingabe
errorhandling
end-if
eine Abstraktion gegen den
Programmfluss erfordert -
daher ‚obfuscated‘.
Ich könnte mir vorstellen, dass
es ggf. Richtlinien gibt, grund-
sätzlich nur mit a) zu arbeiten.
Grüße
CMБ
hallo sm,
ich weiss zwar nicht warum du so einen namen für mich verwendest, aber es gibt größere probleme auf der welt als dieses.
für jemand der deine sprache spricht und versteht mag das ja hier eine offenbarung sein, aber ich verstehe nicht, was du mir sagen möchtest. wäre prima, wenn du es noch einmal mit normalen worten versuchen würdest, da es sicher sinnig ist.
danke und grüße
Cess
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hi Hans,
ich weiss zwar nicht warum du so einen namen für mich
verwendest, aber es gibt größere probleme auf der welt als
dieses.
bei Deutung deiner Emailadresse ergibt sich hans, ist kürzer als cesscesscess
Semjon hat dir gesagt dass er für die Variante deines Kollegen ist.
Gruß
Reinhard
Hi Cess,
die performance wird von der Schreibweise nicht beeinflusst, da es der IF-Anweisung völlig schnuppe ist, wo ihr Sprungziel liegt. Und gesprungen wird ganz gewiss, auch wenn es auf den ersten Blick nicht so aussieht.
Die Wartungsfreundlichkeit wird durchaus beeinflusst, aber das ist ja nicht Dein Problem, sondern das der armen Seele, die in zwei Jahren das Programm pflegen muss.
Gruß Ralf
aber ist der wille wirklich einfacher zu interpretieren?
Ich schreibe meine Programme nicht so. Aber ich bin auch ein extrem dokumentationsfeindliches Programmierschwein. Und dennoch: fremde Konstrukte, sind sie langatmig und großväterlich schwätzerisch geschrieben, wie dein Kollege es macht, kann ich tatsächlich besser lesen, als eigenen Code nach ein paar Jahren.
Ich weiss nicht, welche Programmiersprache du auf der MVS nutzt, aber wenn du auf so einer Maschine mal 30 Jahre alten Code gesehen hast und korrigieren oder adaptieren musst, bist du froh um jeden schwätzerischen Ausdruck, den die Kollegen damals verwendet haben.
Andererseits - ob auch nur eine Zeile unseres Codes die nächsten fünf Jahre übersteht…
Schorsch
und man stellt sich
die frage, in welchem fall mache ich denn jetzt was?
Eben! Du stellst dir die Frage! Im Konstrukt deines Kollegen ist die Frage beantwortet, bevor du sie stellen kannst.
Bei deinem Konstrukt muss der Wartungsprogrammierer selbst denken, bei dem deines Kollegen muss er nur warten.
Idiotie? Geb ich dir recht. Aber es gibt (aus mannigfaltigen Gründen durchaus zurecht) auch Betriebswirtschaftler, und die lieben! diese Form der Idiotie.
Gruss
Schorsch
Messen anstatt raten
Moin, Cess,
warum strickst Du nicht einfach ein Progrämmchen, das die beiden Konstrukte in Schleifen 100.000 mal aufruft? Unter MVS (PL/I, Cobol?) sollte das kein Problem sein, da steht Dir eine richtige Uhr zur Verfügung.
Gruß Ralf