Anfängerfrage IF - THEN - ELSE

[taaktaak]

Hallo omata,
ich sehe in deiner Variante, die selbstverständlich funktioniert, keinen Vorteil; ich halte sie sogar für ineffizient: Sie benötigt mehr Tipparbeit, ist (für mich) unübersichtlicher und mit Sicherheit nicht schneller. Warum sollte ich dieses Konstrukt einsetzen? Nur um das Break zu vermeiden?

[omata]

Das musst du natürlich für dich entscheiden.

Ich hatte noch nie Probleme mit dem Tippen.
Wie auch immer ich versuche eben strukturiert zu programmieren. Das muss man ja nicht, wenn dir das egal oder nicht wichtig ist ist das nunmal so. Trotzdem finde ich es eben sinnvoll einem Anfänger nicht gleich die "bösen" Befehle beizubringen, nur weil man selber zu "faul" ist. Ok, wenn man es nicht besser weiss ist das nunmal so, deshalb ergibt so sein Thread immer gleich so eine riesige Grundsatzdiskussion.
Wenn die Anwendungen großer werden, ist es nunmal sinnvoll struktiriert zu arbeiten.
Ich persönlich weiss meist nicht gleich das die Anwendung, die ich beginne riesig wird. Deshalb designe ich das gleich ordentlich, weil ich mich eben kenne. Das wird nachträglich nicht mehr angepasst, nach dem Motto läuft doch. Wenn es dann aber irgendwann an irgendeiner Stelle Probleme gibt dann viel Spass bei der Fehlersuche.

Deshalb finde ich solche Threads dann irgendwann nur noch bedauerlich, wenn es nur noch darum geht für die unstrukturierten Befehle eine Daseinsberechtigung zu finden.

Deshalb die einfache Frage warum nicht gleich ordentlich und strukturiert arbeiten?
Nur weil es angeblich Tipparbeit bedeutet?

[phXql]

Faulheit ist bekanntlich die Mutter aller Erfindungen

PS: Das heißt nich, dass ich Spaghetti-Code befürworte..

[grenzgaenger]

Zitat von phXql:

Faulheit ist bekanntlich die Mutter aller Erfindungen

PS: Das heißt nich, dass ich Spaghetti-Code befürworte..

dafür kommt der spass beim debuggen und beim überarbeiten 8)

und mal ehrlich, wieviele threads hier gehen auf kosten von schlechten einrückungen und daraus resultierenden fehlern? 10%, 20%?

[xZise]

Zitat von phXql:

Nein, raise ersetzt man auf KEINEN fall mit rückgabeparametern.

Exceptions kann man nicht ignorieren, Rückgabewerte schon.

// Edit: hähähä, Exceptions ignorieren kann man schon, aber dann kann man demjenigen Vorsatz vorwerfen:

Code:

try
{
 foobar();
}
catch(Exception)
{
}

Erstens habe ich extra ein "nur" darein getippt, und zweitens gibt es soweit ich weiß, Funktionen die einen Rückgabeparemter mit dem Fehler haben.
Bevor du fragst: Ich kann dir nicht die Funktionsnamen nennen, aber ich glaube das sind API-Funktionen.

MfG
xZise

[taaktaak]

Omata, ich gebe dir prinzipiell Recht - keine Frage! Insbesondere, dass viele Sources fast immer länger und umfangreicher werden, als ursprünglich eingeschätzt.

Was an meinem Beispiel aber so unstrukturiert ist, das erschließt sich mir beim besten Willen nicht.

// OT - Das können wir bei einem Milchkaffee im "Venezia" besprechen!

[phXql]

Zitat von xZise:

Erstens habe ich extra ein "nur" darein getippt, und zweitens gibt es soweit ich weiß, Funktionen die einen Rückgabeparemter mit dem Fehler haben.
Bevor du fragst: Ich kann dir nicht die Funktionsnamen nennen, aber ich glaube das sind API-Funktionen.

Jo, mit den Funktionen hast du wohl recht. Fast alle WinAPI calls benutzen return values. Da hat MS dazugelernt und rät vom Gebrauch von return values in .NET z. B. ab. Und das is auch gut so. Exceptions kosten zwar einiges mehr (nicht Euro, sondern Taktzyklen), dafür erhöhen sie die Qualität der Software ungemein.