Styl kodowania PHP dla operatora Nie

Question

Współpracownik i ja najwyraźniej mamy różne style! operator w PHP. Zazwyczaj piszę:

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

Ale on preferuje rozstawianie! z dala od zmiennej.

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

co może doprowadzić do czegoś jak ten

if ($x && ! $y) { 

który wygląda dziwnie na mnie.

Generalnie staramy się postępować zgodnie z PSR-2, ale nie jestem ekspertem i nie znalazłem wyraźnej rekomendacji. Dla innych typów operatorów jest przestrzeń przed i po

if ($x === false) { 

I

if ($x > $y) { 

Wtedy nie ma &

$x = & $y; 

ja zazwyczaj nie robią tego tak nie mieć opinię.

Czy ktoś może zacytować wymaganie PSR dla! przykład? Jeśli nie, czy istnieje inna zasada, której należy przestrzegać? Nasze formatery IDE są teraz w pojedynkę.

Answer 1

Po pierwsze: rób, co chcesz.

Po drugie, tu są dwie konwencje stylu z dwóch dużych projektów, Drupal:

Jednoargumentowe operatorzy (operatorów, które działają tylko na jedną wartość), takie jak ++, nie powinno mieć miejsca pomiędzy operatorem a zmienna lub numer, na którym działają.

i Symfony:

Place operatory jednoargumentowe (!, -- ...) Przylega do zmiennej dotkniętego

Tak, mała próbka szukanego tutaj (po prostu pierwszy pojawiają się w Google) przepisać ma miejsca. Które, na poziomie osobistym, zgadzam się z.

Answer 2

Och, nie wdawaj się w kolejną dyskusję na temat tak nieistotnych konwencji. Jeśli przeczytam if (!$x) { lub if (! $x) { pierwsze pytanie brzmi: $ x? Dla mnie $ x jest koordynatorem lub może licznikiem, więc robienie operacji boolowych jest jak oszczędzanie drogiego bajtu, co czyni kod niełatwiejszym do odczytania lub po prostu niepowodzeniem w nazywaniu tej zmiennej bool.

Wiele projektów zaczyna się od pytania o wytyczne lub zwariowane ciężkie dokumenty i wszystko lint. Jest to właściwie tylko sygnał, że nie wie, jak go uruchomić.

Jeśli mój zespół pisze kod, który jest przyjemny do wielokrotnego użytku i intuicyjny, a może świetnie zintegrowany w ramach, to nie mam problemu z odczytaniem heterogenicznego kodu.

Inną sprawą jest pisanie metod, atrybutów i funkcji małych wielbłądów, stałych z dużymi literami i podkreśleniem, i tak dalej.