Heute hab ich wieder gesehen, dass einem die doppelte Negation bei der Entwicklung die wildesten Überraschungen beschert.
Da ist z.B. der Fall eines Settings:

$bNotActive = false;  
if(!$bNotActive == true) {  
  return false;  
}

An solchen Codebeispielen kann man schön lange grübeln, wenn man möchte. Natürlich hätte man das auch so schreiben können:

$bActive = true;  
if($bActive != true) {  
  return false;  
}

Das Problem sind manchmal einfach nur die Gedankengänge, die man beim Schreiben des Quellcodes hat.

Variablenname

Man möchte manchmal einfach ausdrücken, dass ein Aktivitätsflag eben negiert ist, also schreibt man im Namen Ausdrücke wie „not“. Diese Namensnegierungen sorgen immer wieder für Verwirrungen, weil man häufig im Kopf umdenken muss. Solche Negationen sind also besser, wenn man sie nicht macht.

Negation der Variablen statt des Vergleichs

Mal abgesehen davon, dass das Ausrufezeichen vorne kaum zu erkennen ist, erfordert es zweimaliges Umdenken beim Lesen, sodass dort schnell Fehler entstehen können.

Schnelligkeit bei Umstellungen

Man hat etwas umgestellt, was jetzt nicht mehr prüft, ob etwas aktiv ist, sondern eher inaktiv (weil’s einfacher war oder so). Dann entstehen solche Dirty Hacks, die halt einfach funktionieren. Was will man mehr?

Fazit

Es ist eher ein Fluch. Wenn solche Codeschnippsel also entstehen, weil man grad ein bisschen Code umstellen will, ist es manchmal wirklich sinnvoller, etwas mehr Code anzufassen, und es u.U. gleich richtig zu machen, falls sich die Caller solcher Methoden auf evtl. doppelte Negationen berufen und der Kollege, der die Quellen beerbt, das Zeug weiterpflegen soll.