Introducción al PHP (Parte 2: Guía de estilo)

  Continuando con la serie de entradas sobre este lenguaje de guiones comenzada en una entrada anterior del presente blog, se hablará aquí del modo básico de escribir en PHP.
  Como es obvio en cualquier lenguaje, este tipo de lenguaje informático posee una sintaxis, una gramática y una ortografía propias, pero su modo de aplicarlas puede variar, hasta cierto punto, según el gusto del programador que lo utilice. Aquí se verá una de las formas más estandarizadas de utilizar PHP.
  En términos generales, una guía de estilo de programación se emplea para unir la manera de crear código, lo cual permite que un código desconocido sea más fácil de entender.
  En las grandes empresas suele haber un grupo dedicado a elaborar esta guía de estilo. Del mismo modo, en internet existe una gran cantidad de grupos de personas que se encargan de buscar la mejor manera de hacer bien las cosas, como, por ejemplo,  Framework Interoperabiliy Group, que se encargan de hacer una recopilación de los puntos en común de los proyectos en PHP y de encontrar maneras de trabajar en conjunto. En este grupo participan los autores de los marcos de trabajo PHP más populares.
  Este grupo propuso y aprobó una serie de recomendaciones de estilo, entre las que se encuentran:

•  PSR-1: (Basic Coding Standard) Codificación estándar básica.
•  PSR-2: (Coding Style Guide) Guía de estilo de codificación.
•  PSR-3: (Logger Interface) Interfaz de acceso.
•  PSR-4: (Autoloader) Estándar de autocarga de clases.

  Puede verse todo lo relacionado con las guías de estilo del Framework Interoperabiliy Group en su página web. Otro buen ejemplo de creadores de guías de estilo, más centrados en PHP, es PEAR (cuya página puede verse en el siguiente enlace).

GUÍA DE ESTILO GENERAL

  Una guía de estilo para PHP bastante estandarizada implica los siguientes puntos:

•   Los archivos deberán utilizar sólamente las etiquetas "<?php... ?>".
•   Los archivos deberán emplear sólamente la codificación UTF-8 sin BOM.
•   No debe haber más de una sentencia por línea.
•   Las palabras clave deben ir en minúscula, así como las constantes "true", "false" y "null".
•  Las constantes deben declararse en mayúsculas con guiones bajos como separadores (Ej.: CONSTANTE_DE_CLASE).
•   El código debe usar 4 espacios como indentación, no tabuladores.
•   Los comentarios de una sola línea "//" son aconsejables. Los comentarios de varias líneas se delimitarán con "/*…*/" o con varios "//". Se deberá colocar el cierre del comentario de varias líneas (*/) al comienzo de la línea siguiente a la finalización del comentario.
•   No debe haber un límite estricto de longitud de línea, pero una misma línea deberá tener 80 carácteres o menos o se dividirá en varias líneas de las dimensiones mencionadas.
•   (PEAR) Cualquier operador binario (+, -, *, /, =, ., ==, &&, ||, ?, :) debe estar rodeado
  de espacios en blanco.
•   (PEAR) Los operadores unarios (!, ++, --, por ejemplo) deben unirse a su argumento
  sin espacios en blanco.
•   (PEAR) El nombre de las variables debe escribirse con estilo camelCase, es decir, comezar en minúscula y, si el nombre de la variable está formado por varias palabras, la primera letra de las palabras (excepto la primera) debe escribirse en mayúscula.
•   (PEAR) Si se definen varias variables, deben alinearse las igualdades con espacios en blanco para facilitar a legibilidad.
•   No es necesario comparar las variables boolenas con los valores "true" y "false", es más aconsejable utilizar directamente la variable o su negación.
•   Debe haber una línea en blanco después de la declaración del namespace, y debe haber una línea en blanco tras el bloque de declaraciones "use".

GUÍA DE ESTILO DE ESTRUCTURAS DE CONTROL

  Además de las normas de estilo genéricas, se deben tener en cuenta las siguientes reglas para las estructuras de control:

•   Las palabras clave de las estructuras de control deben tener un espacio después de ellas.
•   No debe haber espacios después del paréntesis de apertura ni antes del de cierre.
•   Debe haber un espacio entre el paréntesis de cierre y la llave de apertura.
•  Las llaves de apertura de las estructuras de control deben estar en la misma línea, y las de cierre deben ir en la línea siguiente al cuerpo.
•   El cuerpo de la estructura debe estar indentado una vez.

GUÍA DE ESTILO DE LOS MÉTODOS

   Junto a las reglas de estilo básicas, también existen las siguientes reglas para los métodos:

•   Los nombres de los métodos y funciones deben declararse en notación camelCase.
•   Las llaves de apertura de los métodos deben ir en la línea siguiente, y las llaves de cierre deben ir en la línea siguiente al cuerpo del método.
•   Los nombres de los métodos no deben estar declarados con un espacio después del nombre del método. La llave de apertura debe situarse en la propia línea y la llave de cierre debe ir en la línea siguiente al cuerpo del método. Non debe haber ningún espacio después del paréntesis de apertura y tampoco antes del paréntesis de cierre.
•   En la lista de argumentos de los métodos no debe haber un espacio antes de la coma, pero sí 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. En este caso el primer argumento debe estar en la línea siguiente, y debe haber sólo un argumento por línea. Cuando se divida en varias líneas, el paréntesis de cierre y la llave de apertura deben estar justos en su propia línea separados por un espacio.
•   En las llamadas a los métodos o funciones, 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
  pero sí un espacio después de cada coma.

GUÍA DE ESTILO PARA LAS CLASES

  Adicionalmente a las normas de estilo básicas, también existen las reglas siguientes para las clases:

•   Los nombres de las clases deben seguir el estilo StudlyCaps, es decir, comenzar por una letra mayúscula y en nombres compuestos cada palabra deberá comenzar con mayúscula.
•   Las llaves de apertura de las clases deben ir en la línea siguiente, y las llaves de cierre deben ir en la línea siguiente al cuerpo de la clase.
•   La visibilidad debe estar declarada en todas las propiedades y métodos; "abstract" y "final" deben estar declaradas antes de la visibilidad; "static" debe estar declarada después de la visibilidad.