PHP Kleinlich, oder doch entscheidend?

[snsdrv]

Hallo,

eigentlich möchte ich ein klein wenig diskutieren. Ich sitze gerade wieder vor einem Sachverhalt, der wirklich sehr leicht zu lösen ist, aber wieder auf mehreren Arten und Weisen.

Hier erstmal der Code ...

foreach ($array as $key => $dataset) {
    if (!empty ($dataset)) {
        // hier wird weiterer Code ausgeführt ...
    }
    else {
        // Fehlermeldung ?
    }
}

oder eben ...

foreach ($array as $key => $dataset) {
    if (empty ($dataset)) {
        // Fehlermeldung ?
        continue;
    }
    // hier wird weiterer Code ausgeführt ...
}

Ich denke, dass beides seine Daseinsberechtigung trägt. Ich neige eher zu zweiterer Methode, aber begründen kann ich es nicht. Ich kann nur sagen, dass ich mehr auf Geradlinigkeit stehe und mich verschachtelter Code derbe ausgedrückt "ankotzt". Gibt es Softwarentwicklungsrichtlinien für PHP, oder Ähnliches?

Was meint ihr? Neige ich zu autistischem Verhalten, oder völlig korrekt, wie ich denke?

Arseen

 

[Daaron]

Den 2. Code finde ich auch etwas besser strukturiert. Ich bin auch kein Freund von Drölfzillionen Ebenen im Code.

 

[F_GXdx]

Du versuchst gerade, das Problem ob das Glas halb voll oder halb leer ist in Programmcode zu diskutieren. Finde ich nicht sehr entscheidend. Kann mir gut Situationen vorstellen, wo jeweils der eine Fall oder der andere Fall mehr Sinn macht. Das hängt jeweils vom erwarteten Wert ab, es gibt durchaus Fälle, wo man oft ein leeres Objekt erwartet, dann kann es Sinn machen, den Fehler tatsächlich bei "Gefülltheit" zu schmeissen.

Wenn es zB irgendein polling-Algo ist, der überprüfen soll, ob eine Queue abgearbeitet ist und von dem Regelfall "ja" ausgeht, dann sollte der Fehler also fliegen, wenn noch ein Objekt darin ist. Nur ein Beispiel.

 

[Bisumaruku]

Gehüpft wie Gesprungen, völlig egal!

 

[Daaron]

F_GXdx, du hast das ! vorm empty in der ersten Variante übersehen, oder?
Beide Code-Varianten machen absolut dasselbe, bei der 2. ist nur der "mache weiter"-Code nicht noch eine Ebene nach unten verschachtelt, sondern der kurze Abbruch-Code.

 

[Madman1209]

Hi,

würde ich auch sagen: vollkommen egal, wenn es dir besser gefällt dann mach es so wie du möchtest.

VG,
Mad

 

[kinglouy]

Es gibt viele, die solche Sprung-Statements wie continue generell meiden. Ist grundsätzlich auch nicht verkehrt, allerdings handelt es sich in der 2. Lösung lediglich um ein einziges continue direkt am Anfang der Schleife und fördert meiner Meinung nach damit sogar die Übersichtlichkeit. Je nachdem wie groß die Blöcke in der 1. Lösung sind, kann es etwas dauern, bis der Leser versteht, dass der else-Block nur da ist, um eine Fehlermeldung auszugeben. Im Gegensatz dazu ist in der 2. Lösung sofort erkennbar, dass ein leeres Objekt einfach übersprungen wird.

Aber trotzdem, kriegsentscheidend ist das nicht und eher von deinem persönlichen Geschmack abhängig.

 

[C22]

Es ist doch nicht genau das selbe, im zweiten Beispiel wird der "weitere Code" ja auch ausgeführt wenn der Fehler auftritt, im ersten Fall (if else) wird ja entweder der "weitere Code" oder die Fehlerbehandlung ausgeführt.

 

[kinglouy]

Nein, das continue-Statement sorgt dafür, dass der Rest der Schleife übersprungen wird und direkt die nächste Schleifeniteration begonnen wird.

 

[C22]

Aso, continue... danke, habs eben nachgeschaut. Wie mans gelernt hat, ich finde es nicht so gut lesbar.

 

[Yuuri]

Ich bevorzuge immer die zweite Variante. Einfach der Übersichtlichkeit halber und weil ich auch die ganzen Verschachtelungen nicht mag.

 

[ice-breaker]

Variante 2

 

[holy]

Ich bevorzuge immer die zweite Variante. Einfach der Übersichtlichkeit halber und weil ich auch die ganzen Verschachtelungen nicht mag.

Variante 2

Full-ack. Nesting stinkt

 

[F_GXdx]

F_GXdx, du hast das ! vorm empty in der ersten Variante übersehen, oder?

Jo, sorry, der Code im Posting hat sich irgendwie auch mehrmals verändert, "während" ich geschrieben habe

 

[Daaron]

Blitzmutation im Code?

 

[Yuuri]

Da waren wohl kleine Bugs (haha welch Wortspiel) im Code zurande.

 

[Daaron]

man mutt <- siehe hier? *G*

 

[joe67]

Ich bin kein Freund von continue oder break um Schleifendurchläufe zu manipulieren. Angenommen der ganze if-Konstrukt wächst derart an, dass jemand auf die Idee kommen könnte ihn in eine separate Funktion auszulagern, dann hat er durch das continue einen Bezug zum einschließenden Code (nämlich der for-Schleife) und kann den ganzen if-Konstrukt nicht verlagern ohne ihn, wenn auch nur minimal, anzupassen.

Was spricht gegen eine dritte Variante? Damit stünde die einfache Fehlerbehandlung gleich am Anfang und der vermutlich größere Codeanteil folgt.

foreach ($array as $key => $dataset) {
    if (empty ($dataset)) {
        // Fehlermeldung ?
    }
    else {
        // hier wird weiterer Code ausgeführt ...
    }
}

Ich persönlich finde es immer vorteilhaft, wenn sich Code als Nassi-Schneidermann-Diagramm darstellen lässt. Das mag zwar etwas antiquiert anmuten, aber es soll ja Leute geben, die auf solche Darstellungen von Code stehen. Mit dem continue fällt das schwer.

Desweiteren wird in diversen Coding-Richlinien (z.B. Misra-C, ok kein PHP aber vom Prinzip her auch egal) davon abgeraten, Schleifen zu manipulieren oder Funktionen an unterschiedlichen Stellen mittels return zu verlassen.

j o e

 

[Yuuri]

Was spricht gegen eine dritte Variante?

Für mich alles.

foreach ($array as $key => $dataset) {
	if (empty ($dataset)) {
		// Fehlermeldung ?
	}
	else {
		foreach( $dataset['data'] as $key2 => $dataset2 ) {
			if( empty( $dataset2  ) ) {
				// Fehlermeldung ?
			}
			else {
				// hier wird weiterer Code ausgeführt ...
			}
		}
	}
}

Gruselig hoch zehn...

Ich persönlich finde es immer vorteilhaft, wenn sich Code als Nassi-Schneidermann-Diagramm darstellen lässt. Das mag zwar etwas antiquiert anmuten, aber es soll ja Leute geben, die auf solche Darstellungen von Code stehen. Mit dem continue fällt das schwer.

Nett gedacht und prompt wird der Code extrem unleserlich und sehr schwer wartbar (Klammer vergessen? Hm, na wo muss sie denn nur hin...). Nur weil es sich anders gut darstellen lässt, muss es nicht zwangsläufig der beste Stil sein. Ich will mit dem Code arbeiten, nicht an ihm.

Desweiteren wird in diversen Coding-Richlinien (z.B. Misra-C, ok kein PHP aber vom Prinzip her auch egal) davon abgeraten, Schleifen zu manipulieren oder Funktionen an unterschiedlichen Stellen mittels return zu verlassen.

Man manipuliert sie ja nicht, man springt einfach direkt zum Ende und macht den nächsten Durchlauf. Oder hat man break und continue für Lau erfunden, weil eine Richtlinie Anderes besagt? Ich nutze die Möglichkeiten, die mir gegeben werden und halte mich nicht aus Zwang an Richtlinie XY.

 

[ice-breaker]

Ich persönlich finde es immer vorteilhaft, wenn sich Code als Nassi-Schneidermann-Diagramm darstellen lässt. Das mag zwar etwas antiquiert anmuten, aber es soll ja Leute geben, die auf solche Darstellungen von Code stehen. Mit dem continue fällt das schwer.

genauso kann man umgekehrt für Variante 2 auch argumentieren, dass sich die Implementierung mit einem Programmablaufplan deckt. Oder dass sie in der aktuellen Form in einer funktionalen Sprache umgesetzt werden könnte, statt continue wäre es dann eben ein rekursiver Aufruf mit dem Rest des Arrays.