Was ist schneller ?

ich hab die erfahrung gemacht, dass es wesentlich mehr nerven als performance kostet, wenn man break benutzt. damit verliert man teilweise die kontrolle über seinen eigenen quelltext... :rolleyes:

und welcher mensch programmiert in Visual Basic
da gibts schon einige...
 
naja aber ich bin gerade dabei mein programm auf performance zu trimmen weil das hier meine Finalversion wird und ich damit sowieso nix mehr später machen werde (wird nen Druckmanager ;)) ist halt nur so ich möchte guten Programmierstil machen und das muss ich ja dann meinem Lehrer vorzeigen und nach eurem Rat hab ich jetzt alles breaks entfernt und durch lange ... sehr lange schleifen bedingungen ersetzt.
und hab jeden tolower befehl entfernt weil das kostet ja zeit für den unterprogramm aufruf und statt dessen halt wenn ich einen charakter abfrage gross und klein schreibung hingeschrieben... ist das ratsam ???
ist immer so dumm ein mittelding aus performance aber dann auch noch code zu schreiben den man versteht :(
 
ist immer so dumm ein mittelding aus performance aber dann auch noch code zu schreiben den man versteht
dann schreib doch einfach mehr kommentare rein, wenn der code sich nicht mehr selbst erklärt. einfach in 4 oder 5 sätzen den zweck vom nächsten anweisungsblock beschreiben.
mach ich auch immer so, und ich kenn auch eigentlich nur leute, die das so machen.
 
keine frage mach ich ja bloss bei mir muss das programm 6 if bedingungen durchgehen ich kann mir das aber sparen wenn ich das vorher verkleiner also das charakter und dann nur noch die hälfte da stehen hab. ich denke mal das steigert die übersichtlichkeit. unser infolehrer sagt ja immer lieber ein bisschen übersichtlicher machen.
viele kommentare schön und gut aber ich will ja nun auch nicht in kommentaren schwimmen und dann erst nen roman durchlesen ;)
 
Zuletzt bearbeitet:
du musst ja nicht gleich einen ganzen roman nach dem motto "es war einmal ein int main(), das sah so aus: ..." schreiben. einfach in drei bis vier sätzen eine kurze und knappe übersicht geben, was genau in dem nächsten anweisungsblock passiert.
 
Habe bisher zwar sehr selten ein break in einer Schleife eingesetzt, werde es aber zukünftig nicht mehr machen!

Bisher habe ich beispielsweise eine For-Schleife vorzeitig mit break abgebrochen, wenn ich beispielsweise das gesuchte Element in einer Liste nach einem Wert durchsucht habe.
Aber die Alternative bzw. Konseqenz wäre dann eine while-schleife mit Bedingung, ob das Element gefunden wurde!
 
Also muss euch beiden recht geben.

Im Normalfall ist es nicht nötig mit break zu arbeiten da mann dies im Ausdruck mit einbauen kann.
Jedoch gibt es häufig spezialfälle bei denen die notwendigen Zustände für den Schleifenaustieg erst beim Durchlaufen der Anweisungen in der Schleife den benötigten Wert erhalten.
Dann ist es sehr wohl wichtig und auch guten Stil mit break bzw continue zu arbeiten.

Goto habe ich noch nie benötigt (halt vor 13 Jahren bei Basic auf SchneiderCPC :) )
 
um nochmal deutlich zu machen, wie furchtbar sowas aussehen kann, hab ich mal zwei unveränderte codeschnipsel rausgesucht. das ganze programm sieht so aus:
Code:
If MSRDC1(1).Resultset.RowCount = 0 Then GoTo 2005: 'Träger ist noch gar nicht angelegt
MSRDC1(1).Resultset.Delete: MSRDC1(1).Refresh: MSRDC1(1).Resultset.AddNew:
2005: Text2(1).Text = Tr_Name$: MSRDC1(1).Refresh:
Return
Code:
Rem: ausgabe
GoSub 337
GoTo 20

337 Rem: Seite beschränken auf 44 Zeilen, nicht bei Zwischenablage
If ausgab2% = 2 Then Clipboard.Clear: Clipboard.SetText z$: Return
MS_Report.Text1.Text = z$: MS_Report.Visible = True
3399: ll = DoEvents: If MS_Report.Visible = True Then GoTo 3399
z$ = MS_Report.Text1.Text
If z$ = "" Then Return
z11$ = "": i = 0
339: ll = InStr(z$, Chr$(13)): If ll = 0 Then z11$ = z11$ + z$: GoSub 338: Return
z11$ = z11$ + Left$(z$, ll + 1): z$ = Right$(z$, Len(z$) - ll - 1):
i = i + 1: If i > 44 Then GoSub 338: z11$ = "": i = 0
GoTo 339
das ähnelt irgendwie einer mischung aus objektorientiertem urzeit-basic und assembler. eigentlich sogar eine beachtliche leistung, bei sowas noch den überblick zu behalten.
normalerweise wird aber selbst bei visual basic davon abgeraten, goto und ähnliches zu benutzen. sollen sich assembler-programmierer damit rumschlagen. :p
 
ieee das ist ja ekelhaft :)
stimmt, aber das ist noch gar nichts. ich hab das projekt noch mal etwas weiter durchforstet und dabei folgenden vierzeiler gefunden:
Code:
On Error GoTo 22
GoTo 20
22 Resume 20
20: On Error GoTo 0
da hab ich nichts dran gelöscht, das steht genau so im code. damit hätte man wahrscheinlich ziemlich gut bei einem wettbewerb zum thema "wie schreibe ich möglichst umständlich ein programm, das gar nichts macht?" gewinnen können. :)
 

Neue Beiträge

Zurück