Ist goto ausnahmslos immer schlecht?
-
dog-mom schrieb:
bei hartmut1164 sieht alles kompliziert und schwer wartbar aus, auch die komische ungarische notation macht es nicht gerade besser, eher im gegenteil.
das kommt wohl am ende raus, wenn man sich zu sehr seine dogmatischen grundsätze klammert.also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen, was immer man bezüglich der namensgebung auch sonst noch treiben mag. es ist meistens vorteilhaft, wenn man variablennamen halbwegs ansieht, was sie speichern
goto ist ein grundbefehl wie alle anderen auch und hat genauso seine berechtigung bzw. sinnvollen einsatzgebiete wie if oder while
-
dog-mom schrieb:
bei hartmut1164 sieht alles kompliziert und schwer wartbar aus, auch die komische ungarische notation macht es nicht gerade besser, eher im gegenteil.
das kommt wohl am ende raus, wenn man sich zu sehr seine dogmatischen grundsätze klammert.Nicht unbedingt - Ich folge der logischen Abfolge der Moeglichkeiten, ich benutze keine globalen Vriablen und das Verhalten ist genau definiert. Ausserdem mein Code ist ziemlich flexible. Wenn Du bei meinem Beispiel in Zeile 3 das iElement durch soetwas ersetzt:
void *pData
und eine Function definierst wie
IsEqual (const void *pCheck0, const void *pCheck1, int (*Compare)(const void*, const void *) );
und diese in Zeile 15 statt des "pToCheck->iElement == iToCheck "einfuegst, kannst Du den Einzeiler "CheckCube" ergaenzen und erhalest einen neuen Cubus mit allen Bedingungen, die flexible in "Compare" definiert wurden. Ich brauche mich nicht mehr um Array-Groessen, abbruchbedingungen etc. zu kuemmern. Das ist unterm Strich einfach zu verstehen und warten.
---
Wenn man natuerlich nicht in Recursionen denkt, hat man ein Problem.
-
hartmut1164 schrieb:
Das ist unterm Strich einfach zu verstehen und warten.
...und schwer zu reversen.
...und schwer zu debuggen.
-
hartmut1164 schrieb:
Wenn man natuerlich nicht in Recursionen denkt, hat man ein Problem.
ne ne ne. alles falsch.
rekursion ist ein tool das man benutzen kann und nicht etwas dass man auf alle probleme draufknallen muss.
-
Ich denk eigentlich zuerst immer rekursiv, aber mit solchem furchtbaren Code (
if (foo == true)
*schüttel*) möcht ich dann doch nichts zu tun haben
-
rekursion funktionierte in pascal, aber nicht in basic. also hat man geknallt, was das zeug hielt, um cool und wissenschaftlich zu sein.
uups, in c++ sehe ich einen ähnlichen effekt, was die verwendung von metaprogrammierung angeht. *angst*
-
ungarischer schrieb:
also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen, was immer man bezüglich der namensgebung auch sonst noch treiben mag.
warum ausgerechnet bei pointern?
es ist meistens vorteilhaft, wenn man variablennamen halbwegs ansieht, was sie speichern
das zeigt mir jedes halbwegs moderne ide in aller ausführlichkeit an. und wenn du typen trotzdem falsch verwurstelst, sagt dir das der compiler.
ungarische notation erhöht den aufwand ohne echten nutzen.
-
Und Rekursion ist in C ja auch nicht ganz ungefährlich: http://damienkatz.net/2008/02/recursion_unsaf.html
-
volkard schrieb:
rekursion funktionierte in pascal, aber nicht in basic.
in basic geht's so in etwa: http://www.olympus.net/personal/7seas/recurse.html
-
Je nach Sprache kann auch ein goto sinnvoll sein- natürlich nicht als
spaghetti - was ist den ein exec sql whenever.... - ist auch nur ein
goto oder
exec cics handle condition... ist auch ein goto
Wenn ich in eine Routine komme, und feststelle, hier brauch ich nix
zu tun, ist ein goto zum Routinenende sicherlich übersichtlicher wie
20 Klammern und 35 Ifs - ist so aus der mittlerweile 27-Jährigen
Programmentwicklung gewachsen.
-
Als ob irgendein Spacken hier die Weissheit mit Löffeln gefressen hätte und mir sagen darf was gut oder schlecht ist. Die Sprache stellt goto bereit. Jeder kann jetzt damit machen was er will.
-
dog-mom schrieb:
ungarischer schrieb:
also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen, was immer man bezüglich der namensgebung auch sonst noch treiben mag.
warum ausgerechnet bei pointern?
weil man als anfänger nur bei pointern ohne jede compilerwarnung folgenden schweren fehler wiuederholt macht
while(a!=b) //statt while(*a!=*b)
-
ungarischer schrieb:
also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen...
dann besser ausschreiben, also nicht sowas wie 'pRxPd' sondern 'RxPacketDescriptorPointer'. auch wenn's länglich wird, es macht den code verständlicher.
-
+fricky schrieb:
ungarischer schrieb:
also zur unterscheidung von pointern und daten sollte man mindestens auf ungarische notation zurueckgreifen...
dann besser ausschreiben, also nicht sowas wie 'pRxPd' sondern 'RxPacketDescriptorPointer'. auch wenn's länglich wird, es macht den code verständlicher.
einfach nur ein kleines p davor. also pPacketDescriptor istein pointer und PacketDescriptor ist ein kein pointer. das ist zwar schlimm, aber mir wird nicht übel davon.
-
Nichts für ungut, aber wie man seine Bezeichnet wählt, sollte jedem selbst überlassen bleiben, sofern man in sich konsistent bleibt und es keine Richtlinie gibt, die konkrete Vorgaben machen.
-
Tachyon schrieb:
Nichts für ungut, aber wie man seine Bezeichnet wählt, sollte jedem selbst überlassen bleiben, sofern man in sich konsistent bleibt und es keine Richtlinie gibt, die konkrete Vorgaben machen.
auf gar keinen fall. sonst kommt die gedankenpolizei und justiert den persönlichen geschmack neu.
-
+fricky schrieb:
sprunghaft schrieb:
Nicht für jede Schleife mit break; lässt sich eine äquivalente Schleife ohne break; erfinden.
Zumindest kann ich mir nicht vorstellen, dass das Gegenteil beweisbar wäre.warum nicht? musst einfach nur in der schleife die abbruchbedingung gewaltsam herbeiführen, beispiel:
for (s=0; s<100; s++) { if (s == 10) s = 100; // selbe wirkung wie 'break' }
und wieso sollte das besser sein?
schließlich musst du beim lesen des codes immernoch die Zeile "if(s==10)" lesen, dann sehen dass "s = 100" einen abbruch bzw eine beendigung der schleife bedeutet, was umständlicher ist als ein einfaches "break", da man sich noch die Abbruchbedingung merken muss(zugegebenerweise im allgemeinen leicht zu merken).
Break ist ein offensichtlicher Abbruch, deine Variante hingegen ein "verdeckter"
-
kingcools2 schrieb:
und wieso sollte das besser sein?
es ist nicht besser, aber irgendwer hier hatte was gegen break und continue in schleifen.
-
+fricky schrieb:
kingcools2 schrieb:
und wieso sollte das besser sein?
es ist nicht besser, aber irgendwer hier hatte was gegen break und continue in schleifen.
Ja - weil es klare Abbruchbedingungen versteckt. Die Codition der Durchfuehrung einer Schleife sollte nur einmal definiert sein und nicht an verschiedenen Orten. Ist halt wieder ein hidden-goto.
-
hartmut1164 schrieb:
Die Codition der Durchfuehrung einer Schleife sollte nur einmal definiert sein und nicht an verschiedenen Orten. Ist halt wieder ein hidden-goto.
lass mich raten - du findest es bestimmt auch doof, wenn mehr als ein 'return' aus einer funktion herausführen, oder?