====== Lyx – Bedingungen (if / else / match) ======

Bedingungen steuern den Kontrollfluss in Lyx. Sie erlauben es, Codeblöcke nur dann auszuführen, wenn eine bestimmte logische Voraussetzung erfüllt ist.

→ [[lyx_-_programmiersprache:schleifen|Schleifen]] · [[lyx_-_programmiersprache:pattern-matching|Pattern Matching]] · [[lyx_-_programmiersprache:syntax|Sprachsyntax]]

----

===== 1. Grundlegende Syntax =====

Eine ''if''-Bedingung erwartet einen Ausdruck, der zu ''bool'' oder ''qbool'' evaluiert.

<code lyx>
if (altitude < 1000) {
    ActivateLandingGear();
} else if (altitude > 40000) {
    ReduceThrust();
} else {
    MaintainFlight();
}
</code>

  * **Klammern**: Die Bedingung muss in runden Klammern stehen.
  * **Blöcke**: Geschweifte Klammern ''{ }'' sind auch bei einzeiligen Anweisungen Pflicht.
  * **Vergleich**: Lyx verwendet ''='' für Gleichheit (nicht ''=='') und '':='' für Zuweisung. So ist eine versehentliche Zuweisung in einer Bedingung strukturell unmöglich.

<code lyx>
var speed: int64 := 250;

if (speed = 250) {
    PrintStr("Reisegeschwindigkeit\n");
}

// Ungleich
if (speed != 0) {
    PrintStr("Flugzeug bewegt sich\n");
}

// Kleiner/größer
if (speed > 300 | speed < 50) {
    PrintStr("Außerhalb Normalbereich\n");
}
</code>

----

===== 2. Logische Operatoren =====

^ Operator ^ Bedeutung ^ Beispiel ^
| ''&'' | UND (AND) | ''a > 0 & b > 0'' |
| ''|'' | ODER (OR) | ''a = 0 | b = 0'' |
| ''!'' | NICHT (NOT) | ''!(a > 0)'' |
| ''!='' | Ungleich | ''a != b'' |

> **Lyx verwendet ''&'' und ''|'' — nicht ''&&'' und ''||''.** Beide Seiten werden immer ausgewertet (keine Short-Circuit-Evaluation per Default). Für Short-Circuit-Auswertung: Bedingungen in separate ''if''-Blöcke verschachteln.

<code lyx>
import std.io;

fn Check(x: int64, y: int64): void {
    // Beide Operanden werden immer ausgewertet
    if (x > 0 & y > 0) {
        PrintStr("beide positiv\n");
    }

    if (x < 0 | y < 0) {
        PrintStr("mindestens eines negativ\n");
    }

    if (!(x = y)) {
        PrintStr("ungleich\n");
    }
}

fn main(): int64 {
    Check(3, 5);
    Check(-1, 2);
    Check(4, 4);
    return 0;
}
</code>

==== Nullable-Prüfung mit nil ====

Lyx verwendet ''nil'' (nicht ''null'') für den Abwesenheitswert optionaler Typen:

<code lyx>
// Optionaler Sensor — kann nil sein
var sensor: ^SensorData := nil;

// Erst auf nil prüfen, dann zugreifen
if (sensor != nil) {
    ProcessData(sensor^.value);
}

// Alternativ: Nil-Koaleszenz-Operator
var safe_sensor: ^SensorData := sensor ?? ^DefaultSensor;
</code>

> In DAL-A/B-Code sollten optionale Pointer durch typsichere ''result''-Rückgaben ersetzt werden — ''nil''-Checks sind fehleranfällig und schwer zu analysieren.

----

===== 3. Kurzform: if als Ausdruck =====

''if'' kann als Ausdruck verwendet werden, wenn beide Zweige denselben Typ zurückgeben:

<code lyx>
fn Abs(x: int64): int64 {
    return if (x < 0) { -x } else { x };
}

fn ClampLabel(v: int64): pchar {
    return if (v < 0) { "negativ" } else if (v = 0) { "null" } else { "positiv" };
}
</code>

----

===== 4. Probabilistisches if (qbool) =====

Lyx unterstützt den Typ ''qbool'' für probabilistische Logik — z.B. für Energie-Aware-Entscheidungen oder Wahrscheinlichkeits-Simulationen.

<code lyx>
// 1% Ausfallwahrscheinlichkeit
var failure_prob: qbool := 0.01q;

if (failure_prob) {
    // Dieser Block wird mit ~1% Wahrscheinlichkeit ausgeführt
    TriggerEmergencyRoutine();
}
</code>

''qbool'' ist kein Ersatz für normale Bedingungen in Safety-kritischem Code — es ist ein Werkzeug für probabilistische Modellierung im Energy-Aware-Programmiermodell.

→ Ausführlich: [[lyx_-_programmiersprache:das-energy-aware-programmiermodell|Energy-Aware-Programmiermodell]]

----

===== 5. Pattern Matching (match) =====

Für Enum-Fallunterscheidungen und strukturierte Typen bietet Lyx ''match'' als typsichere Alternative zu langen ''if/else if''-Ketten.

<code lyx>
match (flight_state) {
    case State.Idle    => { PowerOn(); }
    case State.Taxiing => { SetFlaps(10); }
    case State.InAir   => { RetractGear(); }
    default            => { LogError(); }
}
</code>

  * **Exhaustiveness**: Der Compiler prüft (v0.9.0+), ob alle Enum-Werte abgedeckt sind. Fehlt ein Wert, ist es ein Compile-Fehler.
  * **Kein Fallthrough**: Im Unterschied zu C/Java gibt es kein implizites Durchfallen zwischen Fällen.
  * ''_'' ist der Wildcard-Fall (entspricht ''default'').

→ Vollständige Dokumentation: [[lyx_-_programmiersprache:pattern-matching|Pattern Matching]]

----

===== 6. MC/DC und DO-178C Relevanz =====

Für Luftfahrt-Zertifizierung (**DAL A/B**) reicht Branch-Coverage nicht aus — gefordert ist **Modified Condition/Decision Coverage (MC/DC)**.

<code lyx>
// Drei Bedingungen — für MC/DC braucht man 4 Testfälle (nicht 8)
fn IsLandingAllowed(gear_down: bool, speed_ok: bool, runway_clear: bool): bool {
    return gear_down & speed_ok & runway_clear;
}
</code>

Der Compiler instrumentiert alle Bedingungen für MC/DC-Analyse:

<code lyx>
// Build mit MC/DC-Instrumentierung:
// lyxc --mcdc-instrument --coverage-report=cov.json src/flight.lyx
//
// Nach dem Testlauf Coverage-Report erzeugen:
// lyxc --coverage-report-html=report/ cov.json
</code>

> Jede Teilbedingung in einem zusammengesetzten Ausdruck muss **unabhängig** das Gesamtergebnis beeinflussen können. Der Report zeigt welche Test-Vektoren dies nachweisen.

→ Vollständige Dokumentation: [[lyx_-_programmiersprache:do-178c|DO-178C Compliance]]

----

Letzte Aktualisierung: 2026-05-22