Standard kodowania PHP Zend Framework, który jest bardziej czytelny?

Question

To jest subiektywne pytanie, potrzebuję waszych odczuć i myśli na temat standardów kodowania i praktyk formatowania.

standardem kodowania

PHP Zend wymaga napisać funkcję multilinii nazywa tak:

$returnedValue = $object->longMethodName(
    $argument1, 
    $otherArgument, 
    42 
); 

myślę następujące podejście jest bardziej czytelny:

$returnedValue = $object->longMethodName($argument1, 
             $otherArgument, 
             42); 

poniewaz istnieje tylko jedna linia z lewej po stronie, oznacza to, że jest to tylko jedna instrukcja, a argumenty są bliższe nazwie metody.

Który z nich jest preferowany w przypadku YOU?

Answer 1

Drugie podejście pozostawia nam jeden dodatkowy problem: długość linii. Standard Zend Code sugeruje, że "Maksymalna długość dowolnej linii kodu PHP wynosi 120 znaków."

Oznacza to, że jeśli chcesz mieć dobre (długie, opisowe) nazwy zmiennych i zdarza się, że masz jedną wartość zwracaną, obiekt, dobrze nazwana funkcja i długi parametr znacznie bardziej prawdopodobne, że osiągną limit 120 znaków .

Dodając do tego iw zależności od standardu, maksymalna długość może wynosić tylko 80 znaków lub coś pośredniego.

Dodatkowo lubię pierwsza lepiej jeśli jest stosowany wielokrotnie

$returnedValue = $object->longMethodName(
    $argument1, 
    $otherArgument, 
    42 
); 
$returnedValue = $object->longMethodName(
    $argument1, 
    $otherArgument, 
    42 
); 
$returnedValue = $object->longMethodName(
    $argument1, 
    $otherArgument, 
    42 
); 
$returnedValue = $object->longMethodName(
    $argument1, 
    $otherArgument, 
    42 
); 

$returnedValue = $object->longMethodName($argument1, 
             $otherArgument, 
             42); 
$returnedValue = $object->longMethodName($argument1, 
             $otherArgument, 
             42); 
$returnedValue = $object->longMethodName($argument1, 
             $otherArgument, 
             42); 
$returnedValue = $object->longMethodName($argument1, 
             $otherArgument, 
             42); 

jak Pekka powiedział mniejsze skoki oczu.

Answer 2

Najpierw podoba mi się pierwsze podejście. Ten ostatni wymaga więcej pisania i jest bardziej obciążający IMO. Myślę, że oko - dla "zachodniej", przynajmniej od lewej do prawej części ludzkości - ma tendencję do przeskakiwania do początku następnej linii, gdy dociera do końca aktualnego, i jest za dużo białej przestrzeni przeskoczyć w drugim przykładzie. Może nie być semantycznie w 100% poprawny, ale zapewnia dobry przepływ danych.

Answer 3

Ani? Opcja A jest potencjalnie myląca, ponieważ do bloków kodu używa się pojedynczego wcięcia. Opcja B jest problematyczna w przypadku długich nazw argumentów i/lub głęboko wciętych kodów.

Wolę podwójne wcięcie dla ciągłych list argumentów.

przykład, na życzenie erenon za:

$returnedValue = $object->longMethodName(
     $arg1, longInlinedMethod($argFoo, $argBar) + otherLongInlinedMethod(), 
     $arg2, $arg3); 
while ($val) { 
    someStatement(); 
} 

Answer 4

Z dwóch podanych, preferuję pierwszy.

Jeśli istnieje standard kodowania, postępuję zgodnie z nim. Jednak w mojej pracy nie ma, a ja wolę następujące:

$returnedValue = $object->longMethodName(
           $argument1, 
           $otherArgument, 
           42 
          ); 

Dla mnie łatwiej jest od razu zobaczyć, że istnieje zmienna przypisania robione (ze względu na sposób, że parametry i zamknięcie nawiasu są wcięte Za pomocą standardu Zend trzeba właściwie szukać znaku równości, aby zobaczyć, że jest to zadanie, w przeciwnym razie można by pomylić go z prostym multilinicznym wywołaniem funkcji:

Jeszcze jeden komentarz ...Moje wywołania funkcji stają się wieloliniowe, jeśli przekroczą 120 znaków, cokolwiek więcej niż 120 znaków nie będzie widocznych w moim IDE w rozdzielczości 1600x1200 z przeglądarką Workspace i panelami nawigacyjnymi Code Navigator.

Ta linia kodu jest tylko 74 znaków, tak bym zrobił tak:

class myClass 
{ 
    public function myFunction(...) 
    { 
     $returnedValue = $object->longMethodName($argument1, $otherArgument, 42); 
    } 
} 

Answer 5

Lubię standardem PEAR i opowiada pierwszemu z przykładów

$returnedValue = $object->longMethodName(
    $argument1, 
    $otherArgument, 
    42 
); 

ale może zamiast zrobiliśmy to dla tak krótkiego zestawu parametrów:

$returnedValue = $object->longMethodName(
    $argument1, $otherArgument, 42 
); 

EDYCJA: o! i na przykład za gwiazdowy:

$notInlined = longInlinedMethod($argFoo, $argBar) + otherLongInlinedMethod(); 
$returnedValue = $object->longMethodName(
    $arg1, $notInlined, $arg3, $arg4 
); 
while ($val) { 
    someStatement(); 
} 

Answer 6

ja zwykle iść z pierwszym, ale z uchwytem zamknięcia na tej samej linii lub przynajmniej samego tiret jak powyżej.

$returnedValue = $object->longMethodName(
    $argument1, 
    $otherArgument, 
    42 
    ); 

$returnedValue = $object->longMethodName(
    $argument1, 
    $otherArgument, 
    42); 

Wydaje się, że uniknęło to zamieszania na poziomie podczas nestingu, dla mnie.

Jednak: mój indenter w vim zaczął robić ten sam poziom-jako-paren (2, powyżej) i lubię go. Łamie się z nim na długich liniach, które wymagają pomocy przy zawijaniu, ale generalnie myślę, że prowadzi to do czytelnego kodu, jeśli przede wszystkim skanujesz nazwy metod zamiast parametrów.

BTW, robi tego rodzaju wcięcia dla zagnieżdżonych instrukcji boolean i takie też działa dobrze.

Będę również grupować argumenty w jednym wierszu, jeśli nie są one zbyt długie i mają sens w grupowaniu.

Answer 7

wolę pierwszy, z dwóch powodów:

1. To pozwala na użycie klawisza Tab do wcięć (lub skróty klawiszowe dla wcięcia/unindent), bez obaw o dodanie dodatkowych spacji aby uczynić swoje argumenty wiersza w górę.
2. Co ważniejsze, nie trzeba modyfikować wcięcia argumentu, jeśli długość zmiennej, obiektu lub metody zmieni się w pierwszym wierszu.