@problembär: Das es zum ``in``-Operator ein ``not in``-Gegenstück gibt, ist IMHO konsequent. Denn für ``==`` gibt es ja auch ein ``!=``, so dass man nicht ``not (a == b)`` schreiben muss, wenn man auf Ungleichheit testen muss. Zu ``is`` gibt es konsequenterweise dann auch ein ``is not``.
Verschiedene Sprachen lösen das unterschiedlich. Einige gar nicht, dass heisst man muss sich so einen Test selber programmieren, andere über Funktionen/Methoden, und einige über Operatoren. Und das alles jeweils in verschiedenen Graden von „Lesbarkeit“. Mal ein paar Beispiele:
Eher kompliziertere Formulierungen: ``g_list_find(a_list, b) != NULL`` (C/GLib), ``(find (lambda (x) (= b x)) a-list)`` (Scheme), ``find(aList.begin(), aList.end(), b) != aList.end()`` (C++/STL), ``b `elem` aList`` (Haskell)
Solche die ein verständliches Wort dafür nehmen: ``aList.Contains(b)`` (C#), ``aList.contains(b)`` (D, Java, C++/Qt), ``aList includes: b`` (Smalltalk), ``aList contains(b)`` (Io)
Und da wo es ``in`` heisst (und bis auf bei Io ein Operator ist): ``b in(aList)`` (Io), ``b in aList`` (CoffeeScript, JavaScript, Python)
D hat einen ``in``-Operator der zum Beispiel für Abbildungen implementiert ist, die in D als assoziative Arrays bezeichnet werden.
Verneinung im IF-Statement
Also, ich folge dem Ansatz, dass wenn es schon einen "not in"-Operator gibt, so sollte man ihn auch benutzen.
Auch teile ich die Ansicht, dass bei komplexeren Statements der "not in"-Operator einfacher zu handhaben - bzw. verständlicher ist.
Auch teile ich die Ansicht, dass bei komplexeren Statements der "not in"-Operator einfacher zu handhaben - bzw. verständlicher ist.