Después de leer PSR-1, surgieron algunas ideas que me gustaría compartir con la comunidad de programación para obtener historias sobre su experiencia.
PSR-1: Estándar de codificación básico: un estándar que recomienda reglas para formatear y codificar. El estilo es cómo escribir código y la escritura es lo que se escribe.
El subtexto del PSR-1 dice que no debe usar una combinación de código y conclusiones lógicas del código. Lo digo un poco, no claramente, pero entonces comprenderá que PSR-1 no recomienda escribir una clase, mostrarla en la pantalla e inicializar las propiedades en un archivo.
Todos los archivos PHP deben usar <?php
o <?=
. Todo es obvio y comprensible aquí, la primera etiqueta dice acerca de la declaración de una sección de código php, y la segunda es un registro corto <?php echo
, es decir, la salida.
Los archivos también deben estar en codificación UTF-8 sin BOM, lo cual tiene sentido. Una vez hubo casos en un proyecto donde había varios programadores. Entonces, uno de alguna manera logró insertar un símbolo de lista de materiales y debido a esto, los archivos de análisis se rompieron.
También establece que no se recomienda utilizar múltiples efectos secundarios. Con la traducción, no siempre estoy bien ... Es decir, no podemos tomar y escribir en el archivo:
<?php
// side effect: change ini settings
ini_set('error_reporting', E_ALL);
// side effect: loads a file
include "file.php";
// side effect: generates output
echo "<html>\n";
// declaration
function foo()
{
// function body
}
Bueno, aquí el momento es extremadamente controvertido. Aunque el estándar recomienda el uso de un cargador automático de acuerdo con sus estándares PSR-0 y PSR-4. Por un lado, sí, pero puede haber inicialización de la aplicación en un solo punto de entrada. En resumen, el momento es dudoso. En el mismo Yii2 no se sigue este enfoque ... No prestaría atención a esta misma recomendación.
(namespace). , , . StudlyCaps
. PHP < 7.0, , .
, DATE_APPROVED
. , – . .
. PSR-1 : $StudlyCaps
, $camelCase
, $under_score
. . , , , , $camelCase
. , , ... , . camelCase
.
Con la denominación de métodos en el formato, camelCase()
estoy completamente de acuerdo y mantengo. Es lógico que nombremos clases con mayúscula, constantes con minúscula, métodos con minúscula. Y, en principio, se pueden distinguir unos de otros simplemente escribiendo.
Gracias por su atención, espero que el material haya sido útil, aunque es una declaración de pensamientos sobre la lectura del PSR-1.