Se você reparar bem o PHP é no quesito padronização de código uma linguagem bem brasileira. Há os padrões: Pecl, Pecl2, Zend Framework e Java (vulgo Zend Framework Coding Standard for PHP >= 5.3).

Reparando bem, cada modelo tem suas particularidades, porém com mesma base. O Pecl2 e Zend Framework PHP >= 5.3, aqui chamado de Java/Sun/Oracle Coding Standard, tem o mesmo objetivo: atualizar o não-padrão para trabalharem com suporte a Namespaces. O que explico mais adiante.

Antes do namaspace, ou seja, antes do PHP 5.3 a Zend recomendava um padrão que eu sempre achei ridículo, mas pensando bem, não tinha muito como fugir disso:

Arquivo: /application/module/Object.php
Nome da Classe: Module_Object

Arquivo: /application/module/client/view/Json.php
Nome da Classe: Module_Client_View_Json

Funcional ? Sim, sem dúvidas. Elegante ? Bem…

Bonito fica quando encontramos coisas como:

Arquivo: /application/module/AObject.php
Classe: Module_AObject <<abstrata>>

A adoção do prefixo “A” para abstrações e do prefixo “I” para interfaces. Além de nada elegante, só atrapalha o uso de Domain-Driven Design onde, resumidamente falando, tem como foco: transparecer no código o que você ouve de seu cliente/stakeholder.

Salvo engano meu, vi isso em um destes padrões sugeridos para o PHP. Mas infelizmente não encontrei o link :/

E aí veio o PHP 5.3

Com a chegada oficial do PHP 5.3, os padrões ao invés de unificarem-se e sugerir algo em comum, resolveram o que ? Criar mais padrões (o que chega a ser irônico) para brindar a chegada do tão sonhado Namespace (ou pacotes, para os Javeiros).

A Zend sugere o seguinte agora:

Arquivo: /application/module/client/view/Json.php
Namespace: \module\client\view
Classe: Json

Sim, óbvio ! Temos assim o padrão Zend Framework v2 ou simplesmente, Java Coding Standards. E eu não estou brincando não. No próprio artigo proposto por Matthew Ratzloff, ele cita como referência o link para o site do Java. O foco de Matthew é acabar com um problema grave criado pela Zend Framework: abreviação de nomes devido a quantidade de caracteres.

O pessoal do Pecl, sugeriu algo bem parecido. Manteve as particularidades e adicionou o suporte à namespaces ao seu Coding Standard.

Porém, há os frameworks

Obviamente em meio a sopa de pseudo-padrões, cada framework tem o seu próprio como era de se esperar. symfony, Cake PHP, Zend Framework, Kohana, etc. Cada um com o seu próprio mesclando vários e criando um terceiro.

Em minha sincera opinião, acho o Coding Standard do symfony de longe o mais bizarro: tab com dois espaços e nome de classe iniciado por minúsculo e sufixado com .class.php de longe lidera a aberração.

Para piorar o autoload dele autoriza coisas como:

Arquivo: /apps/module/lib/myObject.class.php
Classe: myObjectClass

Isso não funcionará com namespaces. Fato.

Teremos um padrão ?

Gostaria eu que sim. Seria fundamental estabelecer, agora com o reaparecimento de namespaces no PHP – sim, existiu num passado sombrio – um padrão default e que fosse largamente adotado. Complicado é convencer muito ego por aí a fora a abandonar seus pseudo-standards – que de padrão não tem nada – e utilizar um único facilitando a colaboração entre projetos e utilizando o tempo no que realmente importa: criar bons e bem documentados softwares.