php - psr - notación studlycaps

Estándares de codificación y longitud de línea

Question

Cada estándar de codificación que he visto tiene un límite recomendado o absoluto para el número de caracteres en una línea. Hay varias formas de trabajar dentro de esta limitación, pero no he visto ninguna orientación específica al respecto.

Obviamente, si es posible, no escriba líneas excesivamente largas.

Pero, ¿y si eso no es práctico? ¿Cómo deben manejarse las líneas largas?

Aquí hay un par de ejemplos

if ($Stmt = $Mysqli->prepare("SELECT color, pattern, size,
manufacturer, mfgSku, storeLocation,
aisle, status
FROM tblItems WHERE ourSku = ?")) {

o

$flavors = array (''chocolate'', ''strawberry'', ''vanilla'', ''cookie dough'',
''chocolate chip'', ''mint chocolate chip'', ''rocky road'',
''peach'', ''fudge brownie'', ''coffee'', ''mocha chip'');

o

$Stmt->bind_result( $this->_firstName,
$this->_lastName,
$this->_BillToAddress->address1,
$this->_BillToAddress->address2,
$this->_BillToAddress->city,
$this->_BillToAddress->state,
$this->_BillToAddress->zip,
$this->_BillToAddress->country,
$this->_email,
$this->_status,
$this->_primaryPhone,
$this->_mobilePhone );

En cada uno de estos ejemplos, la sangría del código extenso es diferente. ¿Hay una manera mejor o más "estándar" de hacer esto? Si las líneas adicionales siempre se sangran de la misma manera. ¿O esto está bien?

Answer 1

Alguna información útil aquí http://framework.zend.com/manual/en/coding-standard.coding-style.html

Answer 2

El contexto dicta cuál elegir. En definitiva, estás escribiendo un código para que lo lea un ser humano. Si sangrar un bloque de código de manera diferente facilitaría la lectura, hágalo.

Answer 3

Esto es bastante subjetivo realmente, al igual que la posición de los corchetes y otros estilos de codificación. Lo principal no es tanto qué estilo elijas, sino que eliges un estilo y te apegas a él durante todo el proyecto.

Personalmente, viniendo de un fondo de Python, utilizo una longitud de línea de 79 y una

$flavors = array (''chocolate'', ''strawberry'', ''vanilla'', ''cookie dough'',
''chocolate chip'', ''mint chocolate chip'', ''rocky road'',
''peach'', ''fudge brownie'', ''coffee'', ''mocha chip'');

estilo.

Pero como digo, en mi opinión, es más importante tener un estilo, en lugar de preocuparse por cuál.

Answer 4

Hay un patrón que puede ver en cada ejemplo: están sangrados al primer parámetro de la función. Este es un buen estándar a seguir a medida que transpone los datos de horizontal a vertical y las columnas permiten una fácil lectura.

Para otros problemas de longitud de línea, como cálculos prolongados, el método preferido es desglosarlos. El cálculo de la fecha juliana o Pascua se realiza en varios pasos en lugar de un cálculo largo.

-Adán

Answer 5

La mejor práctica generalmente proviene de los propósitos detrás de la restricción de longitud de línea en sí:

• Aumentar la interoperabilidad (entre programadores, software de edición, etc.)
• Para aumentar la legibilidad y la comprensión
• Para aumentar el disfrute y la velocidad de desarrollo
• Para aumentar los ingresos y las ganancias

Por lo tanto, sus elecciones, como alinear todos los parámetros stmt, son buenas si contribuyen tanto a su propia comprensión futura como a la de los demás integrantes de su equipo.

Espero que esto ayude;) -M

Answer 6

Número de puerta 3. Si no puede hacerlo en una línea, hágalo en una línea por artículo, cualquier otra cosa ofusca los artículos después de la primera en la línea y es horrible de leer. La sangría constante también importa.

Vaya, creo que esto es viejo en una época en la que la mayoría de los programadores deberían tener monitores duales a alta resolución. El primer ejemplo parece que podría ser una línea bastante feliz.

Answer 7

No conozco ningún estándar, ya que sería difícil de decir. Para aquellos de nosotros en monitores más grandes, podemos ver más códigos horizontales que otros en monitores más pequeños. Generalmente intento construir cadenas largas secuencialmente a través de. = (PHP) cuando es necesario, y como tu código demostró, dividí las matrices largas arbitrariamente en nuevas líneas, dependiendo de la cantidad de caracteres que exista en esa línea en particular.

Answer 8

No creo que uno deba tener largas filas intencionalmente, pero, a riesgo de ofender a muchos, sugiero que la longitud de la línea en realidad ya no es tan importante.

Vim y emacs manejan bastante bien las líneas largas, y están instalados en casi todas las cajas de Unix. En Windows, casi siempre estará dentro de un editor de texto GUI. Creo que tu estilo $Stmt->bind_result es el más fácil de leer, pero si solo tienes que cargar una gran cantidad de información estática en una declaración, no tengo ningún problema con una línea de 1000 caracteres.

Answer 9

No me importa demasiado la opción 3 (1 artículo por línea). Además, personalmente, siempre utilizo el engastado de palabras, así que tener código en una línea no me molesta en absoluto. Sin embargo, en su segundo ejemplo, con el envío de la palabra, eso podría parecer un desastre para los programadores que usan el envío de palabras. Quizás soy de un grupo más pequeño al que no le importan las colas largas.

Answer 10

Si está envolviendo más de dos elementos, prefiero una nueva línea para cada elemento, como en su tercer ejemplo. Es más fácil para las herramientas de control de origen automatizadas fusionar ediciones de otras personas si solo hay un elemento por línea.

Answer 11

Siga el estándar usado por el código circundante. No crees tu propio "estándar" sin importar cuánto "mejor".

Answer 12

Un estilo de sangría inusual en el que me encontraba facilitándome cuando hacía un montón de trabajo SQL;

INSERT INTO someTable
(
id,
name,
age,
address1,
address2,
)
VALUES
(
2,
''Bob''
25,
''12 Fake Street'',
''The Moon''
)

De hecho, me resulta mucho más fácil de leer que cualquier otro diseño para largas listas de parámetros.

Answer 13

Mi preferencia personal es la siguiente;

$Stmt->bind_result( $this->_firstName, $this->_lastName, $this->_BillToAddress->address1, $this->_BillToAddress->address2, $this->_BillToAddress->city, $this->_BillToAddress->state, $this->_BillToAddress->zip, $this->_BillToAddress->country, $this->_email, $this->_status, $this->_primaryPhone, $this->_mobilePhone );

De esta forma, el corchete de cierre y el punto y coma están en la misma sangría que la llamada de apertura. Sin embargo, no todos los lenguajes soportan tener parámetros en otra línea para la llamada al método ...

Answer 14

En prosa, se ha demostrado que las líneas de más de 80 o más son más difíciles de leer. (Consulte la página 13 de la documentación de la clase LaTeX Memoir). Code Complete (sección 18.5, página 425 de mi edición) también hace referencia al límite de 80 caracteres con esta condición:

Con pantallas más grandes, tipos de letra angostos, impresoras láser y modo horizontal, los argumentos para el límite de 80 caracteres no son tan convincentes como solían hacerlo conmigo. Una sola línea de 90 caracteres de largo suele ser más legible que una que se ha dividido en dos solo para evitar el desbordamiento de la columna. Con la tecnología moderna, probablemente sea correcto exceder 80 columnas ocasionalmente.

Me gustaría sangrar el SQL en su primer ejemplo por separado del resto del código:

if ($Stmt = $Mysqli->prepare(
"SELECT color, pattern, size,
manufacturer, mfgSku, storeLocation,
aisle, status
FROM tblItems
WHERE ourSku = ?")) {

El segundo ejemplo podría ser mejor si se carga en un archivo o tabla de configuración.

El tercero está bien, pero podrías ajustarlo un poco con:

$Stmt->bind_result(
$this->_firstName,
$this->_lastName,
$this->_BillToAddress->address1,
$this->_BillToAddress->address2,
$this->_BillToAddress->city,
$this->_BillToAddress->state,
$this->_BillToAddress->zip,
$this->_BillToAddress->country,
$this->_email,
$this->_status,
$this->_primaryPhone,
$this->_mobilePhone
);