PHP Zend Framework стандарт кодирования, который является более читаемым подходом?

Мне больше нравится первый подход. Последнее требует большего набора текста и больше напрягает глаз IMO. Я думаю, что глаз - для "Западной", по крайней мере, читающей слева направо части человечества-имеет тенденцию прыгать в начало следующей строки, когда прибывает в конец текущего, и во втором примере слишком много белого пространства, чтобы перепрыгнуть. Она не может быть семантически 100% правильно, но обеспечивает хороший поток чтения.

мне нравится стандарт PEAR, и он защищает первый из ваших примеров

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

но я мог бы вместо этого сделать это для такого короткого набора параметров:

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

EDIT: oh! и, например, сидерический это:

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

из двух, которые вы предоставили, я предпочитаю первый.

Если есть стандарт кодирования на месте, я буду следовать ему. Однако на моей работе нет, и я предпочитаю следующее:

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

для меня легче сразу увидеть, что выполняется назначение переменной (из-за того, как параметры и закрывающие скобки отступы. Со стандартом Zend вы должны фактически искать знак равенства, чтобы увидеть, что это назначение, иначе это может быть путают с простым вызовом многострочной функции.

еще одно замечание... мои вызовы функций становятся многострочными только в том случае, если они превышают 120 символов что-либо более 120 символов не будет видно в моей среде IDE с разрешением 1600x1200 с открытыми областями браузера рабочей области и навигатора кода.

эта строка кода составляет всего 74 символа, поэтому я бы сделал это:

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

ни? Вариант A потенциально сбивает с толку, поскольку для блоков кода используется один отступ. Вариант B проблематичен с длинными именами аргументов и / или глубоко отступами кода.

Я предпочитаю двойной отступ для продолжения списков аргументов.

пример, по запросу erenon:

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

обычно я иду с первым, но с закрывающей скобкой на той же строке или, по крайней мере, с тем же отступом, что и выше.

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

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

это, кажется, избегает путаницы уровня при вложенности, для меня.

однако: мой индентер в vim начал делать тот же уровень, что и paren (2, выше), и мне это нравится. Я разрываюсь с ним на длинных строках, которые нуждаются в помощи обертывания, но в целом, я думаю, что это приводит к читаемому коду, если вы в первую очередь сканируете имена методов вместо параметры.

BTW, делая такой отступ для вложенных булевых операторов,и такие работы тоже хорошо.

Я также сгруппирую аргументы в одной строке, если они не слишком длинные, и они имеют смысл группировать.

Я предпочитаю первое, по двум причинам:

1. Он позволяет использовать клавишу Tab для отступа (или горячие клавиши для отступа/отступа), не беспокоясь о добавлении дополнительных пробелов, чтобы ваши аргументы выстраивались в линию.
2. что еще более важно, вам не нужно изменять отступ аргумента, если длина вашей переменной, объекта или имени метода изменяется в первой строке.