Estándares de codificación en PHP V1
MedellínPHP
Andrés Felipe Quiroz Rúa - @afqrbarbax
http://about.me/aquirozr
http://about.me/aquirozr
Agenda
- PSR-1
- PSR-2
- PSR-0
- Namespace en PHP
- Autoload
PSR-1
Tiene como objetivo garantizar un alto nivel técnico de interoperabilidad entre el código PHP.
Recomendación No1
Los archivos DEBEN utilizar solamente las etiquetas
<?php <?=
Se usa <?php ?> para todo el código PHP
Se usa las etiquetas cortas <?= ?> para imprimir salida de información
Recomendación No2
Los archivos DEBEN emplear solamente la codificación UTF-8 sin BOM para el código PHP
Recomendación No3
Los archivos DEBERÍAN declarar cualquier estructura (clases, funciones, constantes, etc) o realizar partes de la lógica de negocio (por ejemplo, generar una salida, cambio de configuración ini, etc,...) pero NO DEBERÍAN hacer las dos cosas, ni DEBERÍA existir efectos secundarios.
Con Efectos Secundarios Sin Efectos Secundarios
Recomendación No4
Los espacios de nombres y las clases DEBEN cumplir el estándar PSR-0, Esto significa que cada clase estará en un fichero independiente y está dentro de un espacio de nombres en al menos un nivel: un nombre de proveedor de nivel superior.
Los nombres de las clases DEBEN declararse con notación StudlyCaps
Los nombres de las clases DEBEN declararse con notación StudlyCaps
StudlyCaps
Es una forma de notación de texto que sigue el patrón de palabras en minúscula sin espacios y con la primera letra de cada palabra en mayúscula.
Ejemplo
<?php <?php
class Persona {} class Factura {}
?> ?>
Recomendación No5
Las constantes de las clases DEBEN declararse en mayúsculas con guiones bajos como separadores CONSTANTE_DE_CLASE.
Las propiedades de las clases o atributos, no sugiere un estándar, pero recomienda que deben ser utilizados en forma coherente con un alcance razonable.
Los nombres de los métodos DEBEN declararse en notación camelCase()
Las propiedades de las clases o atributos, no sugiere un estándar, pero recomienda que deben ser utilizados en forma coherente con un alcance razonable.
Los nombres de los métodos DEBEN declararse en notación camelCase()
camelCase()
Es una forma de notación de texto que sigue el patrón de palabras en minúscula sin espacios y con la primera letra de cada palabra en mayúsculas exceptuando la primera palabra.
Aplicación de la Recomendación No5
PSR-2
Su objetivo es la de reducir la dificultad cuando se lee código de diferentes autores. Lo realiza mediante la enumeración de una serie de reglas común y expresiones sobre cómo dar formato al código PHP.
El código DEBE seguir las normas expuestas en el estándar PSR-1.
Ficheros
Todos los ficheros PHP DEBEN usar el final de línea Unix LF.
http://plugins.netbeans.org/plugin/36810/show-and-change-line-endings
Todos los ficheros PHP DEBEN terminar con una línea en blanco.
La etiqueta de cierre ?> DEBE ser omitida en los ficheros que sólo contengan código PHP.
Líneas
- NO DEBE haber un límite estricto en la longitud de la línea.
- Se recomienda líneas de 80 caracteres o menos, se sugiere un máximo de 120 caracteres, los IDE deben reportar que se ha sobre pasado, mas no desplegar y/o visualizar el error.
- NO DEBE haber espacios en blanco al final de las líneas que no estén vacías.
- PUEDEN añadirse líneas en blanco para mejorar la lectura del código y para indicar bloques de código que estén relacionados.
-
NO DEBE haber más de una sentencia por línea.
Identación
El código DEBE usar una indentación de 4 espacios, y NO DEBE usar tabuladores para la indentación.
Utilizar sólo los espacios, y no mezclar espacios con tabuladores
Palabras Clave
Las Palabras clave de PHP DEBEN estar en minúsculas.
Las constantes de PHP true, false y null DEBEN estar en minúsculas.
Namespace y Use
Cuando esté presente, DEBE haber una línea en blanco después de la declación del namespace.
Cuando estén presentes, todas las declaraciones use DEBEN ir después de la declaración del namespace.
DEBE haber un use por declaración.
DEBE haber una línea en blanco después del bloque de declaraciones use.
Extensiones e Implementaciones
Las palabras clave extends e implements DEBEN declararse en la misma línea del nombre de la clase.
La llave de apertura de la clase DEBE ir en la línea siguiente; la llave de cierre DEBE ir en la línea siguiente al cuerpo de la clase.
La lista de implements PUEDE ser dividida en múltiples líneas, donde las líneas subsiguientes serán indentadas una vez. Al hacerlo, el primer elemento de la lista DEBE estar en la línea siguiente, y DEBE haber una sola interfaz por línea.
Propiedades
La visibilidad DEBE ser declarada en todas las propiedades.
La palabra clave var NO DEBE ser usada para declarar una propiedad.
NO DEBE declararse más de una propiedad por sentencia.
Los nombres de las propiedades NO DEBERÍAN usar un guión bajo como prefijo para indicar si son privadas o protegidas.
Métodos
La visibilidad DEBE ser declarada en todos los métodos.
Los nombres de los métodos NO DEBERÍAN usar un guión bajo como prefijo para indicar si son privados o protegidos.
Los nombres de métodos NO DEBEN estar declarados con un espacio después del nombre del método. La llave de apertura DEBE situarse en su propia línea, y la llave de cierre DEBE ir en la línea siguiente al cuerpo del método. NO DEBE haber ningún espacio después del paréntesis de apertura, y NO DEBE haber ningún espacio antes del paréntesis de cierre.
Argumentos de los Métodos
-
En la lista de argumentos NO DEBE haber un espacio antes de cada coma y DEBE haber un espacio después de cada coma.
-
Los argumentos con valores por defecto del método DEBEN ir al final de la lista de argumentos.
-
La lista de argumentos PUEDE dividirse en múltiples líneas, donde cada línea será indentada una vez. Cuando se dividan de esta forma, el primer argumento DEBE estar en la línea siguiente, y DEBE haber sólo un argumento por línea.
-
Cuando la lista de argumentos se divide en varias líneas, el paréntesis de cierre y la llave de apertura DEBEN estar juntos en su propia línea separados por un espacio.
abstract, final, static
-
Cuando estén presentes las declaraciones abstract y final, DEBEN preceder a la declaración de visibilidad.
-
Cuando esté presente la declaración static, DEBE ir después de la declaración de visibilidad.
Llamadas a métodos y funciones
Cuando se realize una llamada a un método o a una función, NO DEBE haber un espacio entre el nombre del método o la función y el paréntesis de apertura, NO DEBE haber un espacio después del paréntesis de apertura, y NO DEBE haber un espacio antes del paréntesis de cierre. En la lista de argumentos, NO DEBE haber espacio antes de cada coma y DEBE haber un espacio después de cada coma.
La lista de argumentos PUEDE dividirse en múltiples líneas, donde cada una se indenta una vez. Cuando esto suceda, el primer argumento DEBE estar en la línea siguiente, y DEBE haber sólo un argumento por línea.
Estructuras de Control
Las reglas de estilo para las estructuras de control son las siguientes:
-
DEBE haber un espacio después de una palabra clave de estructura de control.
-
NO DEBE haber espacios después del paréntesis de apertura.
-
NO DEBE haber espacios antes del paréntesis de cierre.
-
DEBE haber un espacio entre paréntesis de cierre y la llave de apertura.
-
El cuerpo de la estructura de control DEBE estar indentado una vez.
-
La llave de cierre DEBE estar en la línea siguiente al final del cuerpo.
El cuerpo de cada estructura DEBE estar encerrado entre llaves. Esto estandariza el aspecto de las estructuras y reduce la probabilidad de añadir errores como nuevas líneas que se añaden al cuerpo de la estructura.
Closures
- Las closures DEBEN declararse con un espacio después de la palabra clave function, y un espacio antes y después de la parabra clave use.
- La llave de apertura DEBE ir en la misma línea, y la llave de cierre DEBE ir en la línea siguiente al final del cuerpo.
- NO DEBE haber un espacio después del paréntesis de apertura de la lista de argumentos o la lista de variables, y NO DEBE haber un espacio antes del paréntesis de cierre de la lista de argumentos o la lista de variables.
- En la lista de argumentos y la lista variables, NO DEBE haber un espacio antes de cada coma, y DEBE QUE haber un espacio después de cada coma.
Closures
PSR-0
Describen los requisitos obligatorios que deben cumplirse para la interoperabilidad del autoloader.
Reglas
- Un espacio de nombres y clase completamente cualificada debe tener la siguiente estructura \<Nombre del proveedor>\(<Paquete>\)<Nombre de clase>.
- Cada espacio de nombres debe tener un espacio de nombres de nivel superior ("Nombre del proveedor").
- Cada espacio de nombres puede tener tantos sub-espacios de nombres como sea necesario.
- Cada separador de espacio de nombres se convierte en la constante DIRECTORY_SEPARATOR cuando se carga desde el sistema de archivos.
Reglas
- Cada carácter _ en el nombre de la clase se convierte en la constante DIRECTORY_SEPARATOR. El carácter _ no tiene ningún significado especial en el espacio de nombres.
- Al espacio de nombres y la clase completamente cualificada se le añade el sufijo .php cuando se cargue desde el sistema de archivos.
- Los caracteres alfabéticos en los nombres de proveedor, espacios de nombres y nombres de clase pueden contener cualquier combinación de mayúsculas y minúsculas.
Ejemplo
\Doctrine\Common\IsolatedClassLoader => /directorio/del/proyecto/lib/vendor/Doctrine/Common/IsolatedClassLoader.php
\espacio_de_nombres\paquete\Nombre_De_Clase => /directorio/del/proyecto/lib/proveedor/espacio_de_nombres/paquete/Nombre/De/Clase.php
Namespace
¿Qué son los espacios de nombres? En su definición más amplia los espacios de nombres son una manera de encapsular elementos. En el mundo de PHP, los espacios de nombres están diseñados para solucionar dos problemas que los autores de bibliotecas y aplicaciones se encuentran cuando crean elementos de código reusable tales como clases o funciones:
Autoload
Es una función llamada __autoload() que es automáticamente invocada en caso de que se esté intentando utilizar una clase/interfaz que todavía no haya sido definida. Al invocar a esta función el motor de scripting da una última oportunidad para cargar la clase antes que PHP falle con un error.
Juguemos con Autoload
Código Ejemplo No1
Implementación de SplClassLoader
Web grafía
Todo el materíal fue sacado de las siguientes urls