Luego de
una acalorada discusión sobre el tema estándares y buenas prácticas, paso en limpio y hago un resumen de todo lo hablado, ya que veo que es un tema que los "Desarrolladores PHP" nos cuesta -aún-
tomar conciencia.
Nuestros referentes obligadosZend -la empresa- nos guste o no, debe ser siempre el referente a todo lo relacionado con
PHP, ya que no solo desarrollan en la actualidad lo que puede considerarse el
"Framework Oficial de PHP" (sin desmedro de ningún otro framework), también es la responsable de desarrollar
el propio lenguaje PHP.
La importancia de los estándaresLos estándares nos permiten disminuir muchos costos que surgen a la hora de desarrollar sistemas que van desde la incorporación de nuevos recursos hasta el entendimiento de los sistemas "legacy" ("sistemas heredados") que existen en cualquier organización. Si todos los desarrolladores programan como quieren, o cualquiera inventa su "propio estándar" o toma el de "cualquier estándar que use otro proyecto", indudablemente esto significará caos.
Qué sucede con la empresa Sun y su lenguaje JavaCreo que está de más decir que a nadie de los profesionales que desarrolla bajo
Java se le ocurriría no seguir el estándar de
Sun Microsystems, y esta empresa a su vez, que es muy metódica y ordenada, tiene predefinidas especificaciones muy claras que explican cómo codificar, cómo programar, cómo usar tal o cual tecnología, para que todos los que usen la arquitectura sigan el mismo criterio.
Empresa Sun == Empresa ZendPor lo tanto, es de sentido común tomar entonces las sugerencias de Zend como
"estándar oficial" y empezar a usar sus criterios (nos gusten o no), sin importar si antes programabas estructurado en PHP con una nomenclatura y ahora quieres seguir usándola, o si no usas Zend Framework y quieres seguir el criterio de otros lenguajes.
Nota: a mi tampoco me gustó la primera vez que vi las llaves de las clases y los métodos contra el margen izquierdo, similar a C o C++, pero a las pocas semanas me acostumbré.
La Historia de PHPPHP es un lenguaje que desde sus orígenes estuvo pensado para programar de forma estructura o "procedural" (uso de funciones y pasaje de datos a través de parámetros), pero con la evolución de los lenguajes este empezó a ser cada vez más Orientado a Objetos, tomando como referencia el lenguaje Java (en la mayoría de los casos, ya que no hizo lo mismo con
el término "namespaces" que en sí lo sacan de .Net).
Aquí surge un híbrido, un lenguaje con una
lista interminable de "funciones estructuradas" que empieza a evolucionar hacia
los Objetos, que permite crear clases como en Java, pero que por un lado usa la nomenclatura "smallcase" (en todas sus funciones) y por otro sugiere la nomenclatura
"camelcase".
"Camelcase Versus Smallcase""Camelcase" es un estándar en la mayoría (por no decir todos) los lenguajes POO, por lo que Zend sugiere, al igual que Java y .Net, seguir esta nomenclatura.
1 <?php
2
3 require_once 'Usuario.php';
4
5 $admin = new UsuarioAdmin();
6
7 echo $admin->getNombre();
8
9 ?>
Aquí es donde surge el problema (o la confusión), muchos desarrolladores PHP siguen usando el estándar viejo "smallcase" porque así es como inició PHP con la práctica estructurada y todas sus funciones siguen usando esa nomenclatura (ver Anexo a continuación).
1 <?php
2
3 require_once 'usuario.php';
4
5 $admin = new UsuarioAdmin();
6
7 echo $admin->get_nombre();
8
9 ?>
Pasando en limpio, para PHP la regla sería:
"Cuando es POO se usa camelcase, cuando es programación estructurada se usa smallcase"
Anexo: hacia donde debería evolucionar PHP7Mi solución a este problema, buscando una "migración de paradigmas", sería que en PHP7 (ya que para PHP6 no hay miras de hacerlo) se implementen "Clases Wrappers" (envoltura / cáscara) que ocupen el lugar de las "Clases Base" (String, Integer, Boolean, etc) que existen en cualquier lenguaje 100% POO, logrando que cada método "esconda" la función "estructurada" correspondiente y mejorando notablemente la organización del lenguaje.
Por ejemplo, en vez de:
1 <?php
2
3 $nombre = 'Enrique Place';
4
5 $cadena_en_mayusculas = strtoupper( $nombre );
6
7 ?>
Debería ser:
1
2 <?php
3
4 $nombre = new String('Enrique Place');
5
6 $cadena_en_mayusculas = $nombre->toUpper();
7
8 ?>
Y también se debería poder hacer algo como:
1 <?php
2
3 $cadena_en_mayusculas = String::toUpper( $nombre );
4
5 ?>
Cuando tienes que buscar algo relacionado con "strings" solo deberías buscar los métodos dentro de la clase correspondiente.
Nota: hace algunos años había iniciado sobre este tema
un proyecto experimental como parte de mi taller piloto de PHP.
En ResumenSe sabe que Sun define todos los estándares de Java y a nadie se le ocurre no seguirlos, en nuestro caso están empezando a existir fuertes "sugerencias" de parte de Zend ("nuestra Sun") para seguir el criterio "camelcase", porque justamente, lo usan en la mayoría de los lenguajes 100% POO.
Aquí está el enlace hacia una presentación realizada por Zend sobre las
Buenas Prácticas de Desarrollo en PHP y
la documentación de Zend Framework donde explica el estándar de codificación del proyecto (indistintamente si usas o no este framework, la guía sirve para todo desarrollo POO bajo PHP).
Para cerrar, resumo la explicación del manual sobre el "objetivo" del estándar de codificación y una frase de la presentación de Buenas Prácticas:
"Buenas normas de codificación son importantes en cualquier proyecto de desarrollo, pero sobre todo cuando varios programadores están trabajando sobre el mismo proyecto. Usar normas de codificación ayuda a asegurar que el código es de alta calidad, tiene menos bugs, y es fácil de mantener."
"No eres tan especial como para necesitar inventar tu propio estándar"
Espero haber aportado un poco de luz sobre el tema.