Oder Abfrage eleganter lösen

[daybyter]

Wenn man den Styler aktiviert, setzt er die Klammern doch eh wieder anders.

[traderdoc]

Zitat von Indexreiter

Programmierer haben eben auch ihre Weltanschauung. Für mich ist Übersichtlichkeit immer wichtiger als Zeilenersparnis. Deshalb setze ich auch immer die öffnende Klammer genau unter das i vom if.
Solche und/oder-Monster vermeide ich wenn es geht. Geht es aber nicht, so würde ich dieses Beispiel der Übersicht halber so codieren:

PHP-Code:

   
   if (Hour() == 8  &&  Minute() >58  &&  [B]!OpenAbstandAN[/B]
      || [B]Open[0] > Open[OpenAbstand][/B]  &&  OpenAbstandAN
      || Bid > iMA(NULL, 0, MAPeriode, 0, MODE_SMA, PRICE_CLOSE, 1)  &&  MovingAvarageControl
      || HandelszeitAN  &&  Hour() < StartStunde
      || HandelszeitAN  &&  Hour() > EndStunde)
   {
      //...
   } 


Mir erscheint das übersichtlicher und pflegeleichter, da Zufügen oder Herausnehmen einer Bedingung nur immer eine Code-Zeile betreffen.

Ja, das Wort Weltanschauung trifft es schon ganz gut, denn viele Wege führen nach Rom.
So kann man es auch schreiben, wobei ich darauf aufmerksam machen möchte, dass die ODER-Verknüpfungen direkt mit dem vorherigen Ausdruck in Beziehung stehen, d.h. in gewisser Weise hängen:

Hour() == 8 && Minute() > 58 && OpenAbstandAN == false || Open[0] > Open[OpenAbstand]

miteinander zusammen, denn es muss entweder OpenAbstandAN == false oder Open[0] > Open[OpenAbstand] true sein. Also sollten diese Abfagen von der Logik her auch in einer Zeile stehen. d.h. man hätte also konsequenterweise auch noch schreiben können:

if (Hour() == 8 && Minute() > 58) {
   if (OpenAbstandAN == false || Open[0] > Open[OpenAbstand]) {
      ...

Ebenso wie

OpenAbstandAN || Bid > iMA(NULL, 0, MAPeriode, 0, MODE_SMA, PRICE_CLOSE, 1)

in eine Zeile gehören usw.

Und ob der TE den Code von der boolschen Logik überhaupt so meinte, ist noch eine ganz andere Frage.
Würde nämlich vor Open[0] > Open[OpenAbstand] eine öffnende runde Klammer ( und z.B. nach OpenAbstandAN eine anschließende runde Klammer ) stehen, dann wäre die boolsche Logik eine ganz andere:

if (... && OpenAbstandAN == false || (Open[0] > Open[OpenAbstand] &&  OpenAbstandAN)  ...

"@Adlerauge - Auf die Idee, alle schließenden Klammern in eine Zeile zu setzen, bin ich auch noch nicht gekommen."
Ne, auf diese Idee wäre ich aus Gründen der Optikverletzung auch nie gekommen!

traderdoc

[Indexreiter]

Da && in der Priorität vor || liegt, trenne ich die Zeile von @Max2018 jeweils vor dem ||. Die &&-Bedingungen werden ja zuerst verkettet und erst danach mit den || verknüpft.

Ich glaube auch, dass die if-Schachtelung nicht zum gewünschten Ziel führt. Ich lese die vorgelegte Zeile so, dass 5 und-verknüpfte Bedingungs-Gruppen mit oder verkettet werden. Sowie eine der Gruppen zutrifft ist alles erfüllt.
Bei der 5-stöckigen if-Abfrage wird schon nach dem ersten Nichteintreffen ausgestiegen

[Adlerauge]

@Indexreiter: Deine Schreibweise gefällt mir auch gut. Wenn man den Code möglichst tabellarisch layoutet, erschliesst sich einem das Ganze sehr viel schneller und besser. Das geht glaube ich jedem so, z.B. wird wohl kaum einer eine .csv-Datei lieber roh lesen, anstatt sie sich als Tabelle anzeigen zu lassen. Bei Code ist es nicht anders. Warum man dann nicht auch die Klammern in eine tabellarische Ordnung bringen sollte, hat noch keiner begründet...

[Nikolaus]

Bevor ich mit den ganzen if-Anweisungen anfangen würde, kommen die Werte aus den Funktionen wie Hour() in eine Variable. Das ist sauberer und schneller.

int intHour = Hour();

Nikolaus