PHP Zend Framework estándar de codificación, ¿cuál es el enfoque más legible?

Question

Esta es una pregunta subjetiva, necesito tus sentimientos y pensamientos sobre los estándares de codificación y las prácticas de formateo.

estándar de codificación

PHP Zend requiere para escribir la función de varias líneas llama así:

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

Creo que el siguiente enfoque es más legible:

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

lástima pues el sólo hay una línea a la izquierda lado, esto indica que esta es solo una declaración, y los argumentos están más cerca del nombre del método.

¿Cuál es YOU preferir?

Answer 1

El segundo enfoque le deja con un problema adicional: Longitud de la línea. El Zend Coding Standard sugiere que "la longitud máxima de cualquier línea de código PHP es de 120 caracteres".

Esto significa que si quiere nombres de variables buenos (largos, descriptivos) y tiene uno para el valor de retorno, el objeto, una función bien nombrada y un parámetro largo es mucho más probable que alcance el límite de 120 caracteres .

Agregando a eso y dependiendo de su estándar, la longitud máxima puede ser de solo 80 caracteres o algo intermedio.

Además me gusta el primero mejor si se usa repetidamente

$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); 

Como dijo Pekka, menos salto ojo.

Answer 2

Me gusta el primer acercamiento mejor. Este último requiere más tipeo, y es más agotador en el ojo IMO. Creo que el ojo -para la parte de lectura de "izquierda" de izquierda a derecha de la humanidad, al menos- tiende a saltar al principio de la siguiente línea cuando llega al final de la actual, y hay demasiado espacio en blanco para saltar sobre el segundo ejemplo. Puede no ser semánticamente 100% correcto, pero proporciona un buen flujo de lectura.

Answer 3

¿Ninguno? La opción A es potencialmente confusa porque el single-indent se usa para bloques de código. La opción B es problemática con nombres largos de argumento y/o código profundamente sangrado.

Prefiero el doble sangrado para las listas de argumentos continuados.

ejemplo, según la petición del erenon:

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

Answer 4

De los dos que proporcionó, prefiero el primero.

Si hay un estándar de codificación en su lugar, lo seguiré. Sin embargo, en mi trabajo no lo hay, y yo prefiero el siguiente:

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

Para mí, es más fácil ver inmediatamente que hay una asignación de variables se está realizando (por la forma en que los parámetros y cerrar paréntesis son sangría Con el estándar Zend, tienes que buscar el signo igual para ver si es una asignación, de lo contrario podría confundirse con una llamada de función simple de líneas múltiples.

Un comentario más ...mis llamadas a funciones solo se convierten en multilínea si exceden los 120 caracteres; más de 120 caracteres no estarán visibles en mi IDE a una resolución de 1600x1200 con el navegador del Área de trabajo y los paneles del Navegador de códigos abiertos.

Esta línea de código es sólo 74 caracteres, por lo que yo hubiera hecho esto:

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

Answer 5

Me gustaría estándar de PEAR y aboga por el primero de sus ejemplos

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

sino que puede ser en su lugar lo he hecho para un conjunto tan breve de parámetros:

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

EDIT: oh! y, por ejemplo de sideral:

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

Answer 6

Me suelen ir con la primera, pero con el corchete de cierre en la misma línea o por lo menos el mismo punto que antes.

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

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

Esto parece evitar la confusión de nivel al anidar, para mí.

Sin embargo, mi indenter en vim comenzó a hacer lo mismo-level-as-paren (2, arriba) y me gusta. Rompo con eso en largas líneas que necesitan ayuda, pero en general, creo que conduce a un código legible si estás buscando principalmente nombres de métodos en lugar de parámetros.

BTW, haciendo ese tipo de sangrado para declaraciones booleanas anidadas y este funciona bien también.

También agruparé argumentos en una línea si no son demasiado largos y tienen sentido para agruparlos.

Answer 7

Yo prefiero el primero, por dos razones:

1. Se le permite utilizar la tecla de tabulación para el sangrado (o teclas de acceso rápido para el guión/Unindent), sin preocuparse por la adición de espacios adicionales para hacer que su línea de argumentos arriba.
2. Más importante aún, no tiene que modificar su sangría de argumento si la longitud de su variable, objeto o nombre de método cambia en la primera línea.