PHP Coding Style für Not Operator

Question

Ein Kollege und ich haben offensichtlich verschiedene Stile für die! Operator in PHP. Ich schreibe normalerweise

if (!$x) { 
    $y = 2; 
} 

Aber er bevorzugt Abstand! weg von der Variablen.

if (! $x) { 
    $y = 2; 
} 

die zu so etwas wie dieses

if ($x && ! $y) { 

führen könnte, die mir seltsam aussieht.

Wir versuchen generell, PSR-2 zu folgen, aber ich bin kein Experte darin und habe keine explizite Empfehlung gefunden. Für andere Arten von Operatoren gibt es einen Raum vor und nach

if ($x === false) { 

Und

if ($x > $y) { 

Dann die es &

$x = & $y; 

ich normalerweise nicht tun dies nicht tun, eine Meinung haben.

Kann jemand eine PSR-Anforderung für die! Beispiel? Wenn nicht, gibt es eine andere Regel, die befolgt werden sollte? Unsere IDE-Formatierungen duellieren sich gerade.

Answer 1

Zuerst einmal: Mach was du willst.

Zweitens, hier sind zwei Stilkonventionen von zwei großen Projekten Drupal:

Unäre Operatoren (Operatoren, die nur einen Wert operieren), wie ++, sollte keinen Raum zwischen dem Bediener hat und die Variable oder Nummer, auf der sie arbeiten.

und Symfony:

Platz unäre Operatoren (!, --, ...) Neben dem betroffenen Variable

die kleine abgefragten Probe hier (einfach Also, die erste auf Google zeigen) verschreiben keinen Raum. Dem würde ich persönlich zustimmen.

Answer 2

Ach komm schon keine weitere Diskussion über so unwichtige Konventionen. Wenn ich if (!$x) { oder if (! $x) { lese, ist die erste Frage, was $ x ist? Für mich ist $ x eine Koordinate oder vielleicht ein Zähler, also macht Bool-Operationen wie while($i--) {} teures Byte zu sparen, Code nicht einfacher zu lesen oder nur ein Fehler bei der Benennung dieser Bool-Variable.

Viele Projekte fangen mit der Frage nach irgendwelchen Richtlinien oder verrückter Dokumentation an und fegen alles an. Dies ist eigentlich nur ein Signal dafür, dass man nicht weiß, wie man es startet.

Wenn mein Team Code schreiben, das ist schön wiederverwendbar und intuitiv, und vielleicht großartig in ein Framework integriert, dann habe ich kein Problem, heterogenen Code zu lesen.

Eine andere Sache ist Schreiben von Methoden, Attribute und Funktionen kleine Kamel-cased, const mit Großbuchstaben und Unterstrich, und so weiter.