PureBoard

Verfasst: **27.04.2014 20:28**

Da sagst du was. Da konnte man noch mit PageDown in einer Minute durch den ganze 64k Speicher durchscrollen und mit Assemblerprogrammierung jedes Byte gezählt...

Verfasst: **03.05.2014 22:15**

Goto ist für mich nicht wegzudenken. Wenn ich ASM für Controller programmiere. Da heisst es halt Jump oder Branch (bedingtes Goto).

Ansonsten habe ich Goto zuletzt wahrscheinlich auf dem Amiga verwendet. Das war vor mehr als 15 Jahren. Ich vermisse es nicht.

Verfasst: **17.01.2015 13:16**

Hi,

ich hätte ja so gerne etwas darüber gelernt, wann und wo Goto in einem Programm 'gefahrfrei' und auch noch 'sinnvoll' verwendet werden könnte, aber irgendwie geht es hier nur um ASM und Geschwindigkeiten (Prozessoren, div. OSs ...).

Vermutlich ist dieser Thread für weit Fortgeschrittene oder Insider sehr ergiebig, aber mir hilft das alles nicht weiter, ob ich denn nun Goto irdendwo mal echt brauchbar einsetzen könnte.

Gruß ~ Vera

Verfasst: **17.01.2015 14:21**

Wenn du glaubst mit Goto deinen Code einfacher oder übersichtlicher machen zu können, dann nutze es einfach. Es macht nichts langsamer oder schlechter.

Verfasst: **17.01.2015 15:03**

NicTheQuick hat geschrieben:Wenn du glaubst mit Goto deinen Code einfacher oder übersichtlicher machen zu können, dann nutze es einfach. Es macht nichts langsamer oder schlechter.

Nein, ich glaube bezüglich Goto gar nichts, hab's noch nie verwendet (außer a long time ago) und weiß nur, dass es schwere Kritik und Warnungen dagegen gibt.
Deshalb hatte ich gehofft, unter diesem Thread-Titel, tatsächliche, diskurse Beispiele vorzufinde, die mir zeigen, wann es mal sinnvoll sein kann, doch Goto zu nutzen und es dann als brauchbaren Befehl einzustufen.

Aber ich denke, ich kann auch weiterhin ohne Goto auskommen, bevor ich damit irgendwelche AblaufProbleme erzeuge, die ich dann nicht nachvollziehen kann.

Verfasst: **17.01.2015 15:36**

Verfasst: **17.01.2015 16:26**

walbus hat geschrieben:Ansonsten ist Goto weitestgehend unproblematisch, wenn´s knallt, knallt´s gleich...

Das ist ja mal 'ne brauchbare Ansage

~ man weiß sofort, wo man dran ist.

Erinnert mit an Loriot:
"... und wenn man was falsch gemacht hat, dann macht es Puff
. . . und alle Kühe fallen um"

~ Danke für die Ermutigung ~

***

Addendum an dieser Stelle, da mein Beitrag nun im abgehängten ThreadTeil steckt und hier dann im nahsten Zusammenhang steht.

Vielen Dank Sicro,
ich finde Dein Beispiel fast schon intuitiv verständlich, so übersichtlich und eingängig ist er.
Das kann ein ProcedureReturn niemals leisten, von dem man nie weiß, wohin er turned.

Dank' auch Nic ~ denn dem Continue bin ich so deutlich auch noch nicht begegnet.

Greets, I'll GotoReturn And GiveItATry

Verfasst: **17.01.2015 17:04**

In einem meiner Programme finde ich bei folgendem Code die Goto-Variante sinnvoll:

Code: Alles auswählen

Procedure MultiFillFields()
  Protected Date   = GetGadgetState(#Date_AutoFillFrom)
  Protected DateTo = GetGadgetState(#Date_AutoFillTo)
  
  CreateDirectory(WorkTablesPath)
  
  Repeat
    If GetDayOfWeekAsString(Date, Day(Date)) = "Mo" And Not GetGadgetState(#CheckBox_IncludeMonday):    Goto JumpToEnd: EndIf
    If GetDayOfWeekAsString(Date, Day(Date)) = "Di" And Not GetGadgetState(#CheckBox_IncludeTuesday):   Goto JumpToEnd: EndIf
    If GetDayOfWeekAsString(Date, Day(Date)) = "Mi" And Not GetGadgetState(#CheckBox_IncludeWednesday): Goto JumpToEnd: EndIf
    If GetDayOfWeekAsString(Date, Day(Date)) = "Do" And Not GetGadgetState(#CheckBox_IncludeThursday):  Goto JumpToEnd: EndIf
    If GetDayOfWeekAsString(Date, Day(Date)) = "Fr" And Not GetGadgetState(#CheckBox_IncludeFriday):    Goto JumpToEnd: EndIf
    If GetDayOfWeekAsString(Date, Day(Date)) = "Sa" And Not GetGadgetState(#CheckBox_IncludeSaturday):  Goto JumpToEnd: EndIf
    If GetDayOfWeekAsString(Date, Day(Date)) = "So" And Not GetGadgetState(#CheckBox_IncludeSunday):    Goto JumpToEnd: EndIf
    
    If Not OpenPreferences(WorkTablesPath + "WorkTable_" + RSet(Str(Month(Date)), 2, "0") + Str(Year(Date)) + ".ini")
      If Not CreatePreferences(WorkTablesPath + "WorkTable_" + RSet(Str(Month(Date)), 2, "0") + Str(Year(Date)) + ".ini")
        MessageRequester("WorkTimeBook", "Daten konnten nicht eingetragen werden!")
        Break
      EndIf
    EndIf
    
    If GetGadgetText(#String_AutoFillWorkBegin)
      WritePreferenceString("WorkBegin_" + Str(Day(Date)), GetGadgetText(#String_AutoFillWorkBegin))
    EndIf
    If GetGadgetText(#String_AutoFillWorkEnd)
      WritePreferenceString("WorkEnd_" + Str(Day(Date)), GetGadgetText(#String_AutoFillWorkEnd))
    EndIf
    If GetGadgetText(#String_AutoFillWorkBreak)
      WritePreferenceString("WorkBreak_" + Str(Day(Date)), GetGadgetText(#String_AutoFillWorkBreak))
    EndIf
    If GetGadgetText(#String_AutoFillWorkNotice)
      WritePreferenceString("WorkNotice_" + Str(Day(Date)), GetGadgetText(#String_AutoFillWorkNotice))
    EndIf
    
    ClosePreferences()
    
    JumpToEnd:
    Date = AddDate(Date, #PB_Date_Day, 1)
  Until Date > DateTo
EndProcedure

Alternativ hätte man bei diesem Code eine Fake-Schleife verwenden oder die IF-Bedingungen jeweils einklammern und mit dem OR-Operator verbinden können, aber so finde ich es am besten.

Verfasst: **17.01.2015 17:23**

Sorry dass ich wieder reingrätschen muss aber ernsthaft? Dein Code hätte man viel effizienter lösen können und nicht so ein Spaghetticode, sorry. Warum nicht einfach eine Variable nutzen um den mittleren Teil auzuschließen oder in zwei Prozeduren teilen um sogar modularer zu gestalten?! Auch wenn es hart klingen mag aber bitte versuche vor dem Schreiben deines Codes zu planen und nicht einfach los zu programmieren. Das ist auch eine Form von Spaghetticode wenn man planlos was entwickelt ohne Effizienz und Strukturierung. Ich vermute mal du hast auch noch nie OOP programmiert? Bitte keinen HATE aber wenn ein professioneller Entwickler den Code sehen würde dann ... ich sage nur fremdschämen. Bitte nicht als Beleidigung ansehen sondern nur als Kritik.

Einige meinen zwar es gibt sinnvolle Goto Varianten die viel besser sind aber mal erlich das sagen nur die Leute, die nicht wissen, wie man es richtig machen kann. Stattdessen nehmen sie so eine Lösung mit GOTOS. O_o

Verfasst: **17.01.2015 17:45**

@CodeCommander:
Die Alternativen hat er ja schon drunter geschrieben. Deine Variation mit der extra Variable ist natürlich auch möglich. Aber ganz ehrlich. Es hat nichts mit guter Programmierung zu tun, dass man Goto immer vermeiden soll. In diesem Fall finde ich das Goto auch nicht schlimm. Schonmal die Sourcen der Java-Bibliotheken durchgeschaut und gemerkt, dass da auch öfter mal ein Goto benutzt wird? Und Java ist ziemlich reines OOP.
Es gibt nunmal unterschiedlichste Meinungen zu diesem Thema und du hast eben auch eine. Das ist ja nicht schlimm. Aber wenn du professionelle Entwickler kennen würdest, würdest du wissen, dass Goto auch im professionellen Bereich Verwendung findet, wenn es eben gerade sinnvoll ist. Das ist ja eh immer von Fall zu Fall unterschiedlich und auch sehr Programmiersprachenabhängig. Wie weiter vorne im Thread schon festgestellt wurde, leidet nicht mal die Effizienz des Codes darunter. Und dass man wissen sollte, was man tut, ist sowieso Voraussetzung für das Programmieren allgemein.
Du redest auch noch von Spaghetticode. Aber ich habe die Vermutung, dass in deinem Gehirn einfach "Goto" und "Spaghetticode" in der selben Schublade stecken und du das deswegen zusammen wirfst. Im Code von Sicro sehe ich kein bisschen Spaghetticode. Oder findest du irgendetwas daran verwirrend?

Hier übrigens noch eine Version des Codes ohne Goto, ohne Fakeschleife, ohne extra Variable und ohne ein großes verkettetes Or-Konstrukt (wenn wir schon dabei sind):

Code: Alles auswählen

Procedure MultiFillFields()
	Protected Date   = AddDate(GetGadgetState(#Date_AutoFillFrom), #PB_Date_Day, -1)
	Protected DateTo = AddDate(GetGadgetState(#Date_AutoFillTo, #PB_Date_Day, -1)
	
	CreateDirectory(WorkTablesPath)
	
	Repeat
		Date = AddDate(Date, #PB_Date_Day, 1)
		If GetDayOfWeekAsString(Date, Day(Date)) = "Mo" And Not GetGadgetState(#CheckBox_IncludeMonday):    Continue : EndIf
		If GetDayOfWeekAsString(Date, Day(Date)) = "Di" And Not GetGadgetState(#CheckBox_IncludeTuesday):   Continue : EndIf
		If GetDayOfWeekAsString(Date, Day(Date)) = "Mi" And Not GetGadgetState(#CheckBox_IncludeWednesday): Continue : EndIf
		If GetDayOfWeekAsString(Date, Day(Date)) = "Do" And Not GetGadgetState(#CheckBox_IncludeThursday):  Continue : EndIf
		If GetDayOfWeekAsString(Date, Day(Date)) = "Fr" And Not GetGadgetState(#CheckBox_IncludeFriday):    Continue : EndIf
		If GetDayOfWeekAsString(Date, Day(Date)) = "Sa" And Not GetGadgetState(#CheckBox_IncludeSaturday):  Continue : EndIf
		If GetDayOfWeekAsString(Date, Day(Date)) = "So" And Not GetGadgetState(#CheckBox_IncludeSunday):    Continue : EndIf
		
		If Not OpenPreferences(WorkTablesPath + "WorkTable_" + RSet(Str(Month(Date)), 2, "0") + Str(Year(Date)) + ".ini")
			If Not CreatePreferences(WorkTablesPath + "WorkTable_" + RSet(Str(Month(Date)), 2, "0") + Str(Year(Date)) + ".ini")
				MessageRequester("WorkTimeBook", "Daten konnten nicht eingetragen werden!")
				Break
			EndIf
		EndIf
		
		If GetGadgetText(#String_AutoFillWorkBegin)
			WritePreferenceString("WorkBegin_" + Str(Day(Date)), GetGadgetText(#String_AutoFillWorkBegin))
		EndIf
		If GetGadgetText(#String_AutoFillWorkEnd)
			WritePreferenceString("WorkEnd_" + Str(Day(Date)), GetGadgetText(#String_AutoFillWorkEnd))
		EndIf
		If GetGadgetText(#String_AutoFillWorkBreak)
			WritePreferenceString("WorkBreak_" + Str(Day(Date)), GetGadgetText(#String_AutoFillWorkBreak))
		EndIf
		If GetGadgetText(#String_AutoFillWorkNotice)
			WritePreferenceString("WorkNotice_" + Str(Day(Date)), GetGadgetText(#String_AutoFillWorkNotice))
		EndIf
		
		ClosePreferences()
	Until Date > DateTo
EndProcedure

PureBoard

Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen

Re: Goto sinnvoll nutzen