Nuestros referentes obligados
Zend -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ándares
Los 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 Java
Creo 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 Zend
Por 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 PHP
PHP 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 PHP7
Mi 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 Resumen
Se 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.
) es hacer reflexionar a los "programadores php" que con solo scripting no se hacen sistemas medios en adelante... y eso no es solo por un tema de "falta de plataforma" (porque al día de hoy PHP sigue siendo "solo un lenguaje" pero que se puede complementar con un conjunto de herramientas) es también un tema de "falta de mentalidad de desarrolladores", donde la gran mayoría de los programadores desconoce los conceptos básicos de la POO.
