Nomeando classes, métodos, funções e variáveis [duplicado]

Eu tive a mesma pergunta há um ano atrás, então eu mesmo observei alguns códigos. Aqui está o que eu encontrei (constantes foram ALL_CAPS em cada projeto, a propósito):

╔═══════════════════════╦═════════════╦════════════╦══════════════╦════════════╦════════════╗
║      PHP Project      ║   Classes   ║  Methods   ║  Properties  ║ Functions  ║ Variables  ║
╠═══════════════════════╬═════════════╬════════════╬══════════════╬════════════╬════════════╣
║ Akelos Framework      ║ PascalCase  ║ camelCase  ║ camelCase    ║ lower_case ║ lower_case ║
║ CakePHP Framework     ║ PascalCase  ║ camelCase  ║ camelCase    ║ camelCase  ║ camelCase  ║
║ CodeIgniter Framework ║ Proper_Case ║ lower_case ║ lower_case   ║ lower_case ║ lower_case ║
║ Concrete5 CMS         ║ PascalCase  ║ camelCase  ║ camelCase    ║ lower_case ║ lower_case ║
║ Doctrine ORM          ║ PascalCase  ║ camelCase  ║ camelCase    ║ camelCase  ║ camelCase  ║
║ Drupal CMS            ║ PascalCase  ║ camelCase  ║ camelCase    ║ lower_case ║ lower_case ║
║ Joomla CMS            ║ PascalCase  ║ camelCase  ║ camelCase    ║ camelCase  ║ camelCase  ║
║ modx CMS              ║ PascalCase  ║ camelCase  ║ camelCase    ║ camelCase  ║ lower_case ║
║ Pear Framework        ║ PascalCase  ║ camelCase  ║ camelCase    ║            ║            ║
║ Prado Framework       ║ PascalCase  ║ camelCase  ║ Pascal/camel ║            ║ lower_case ║
║ SimplePie RSS         ║ PascalCase  ║ lower_case ║ lower_case   ║ lower_case ║ lower_case ║
║ Symfony Framework     ║ PascalCase  ║ camelCase  ║ camelCase    ║ camelCase  ║ camelCase  ║
║ WordPress CMS         ║             ║            ║              ║ lower_case ║ lower_case ║
║ Zend Framework        ║ PascalCase  ║ camelCase  ║ camelCase    ║ camelCase  ║ camelCase  ║
╚═══════════════════════╩═════════════╩════════════╩══════════════╩════════════╩════════════╝

Então, depois de analisar tudo isso, decidi usar:

• ClassName
• methodName
• propertyName
• function_name (destinado a funções globais)
• $variable_name

Não existe algo como "o estilo de codificação mais popular", é estritamente uma questão de convenções e preferências pessoais de sua equipe. Como você está segmentando desenvolvedores, pesquise as convenções mais populares da sua plataforma e siga a que você considera mais conveniente, legível e, bem, mais próxima do seu estilo pessoal. Para o PHP, um conjunto popular de convenções de nomenclatura é Zend Framework .

Ser consistente com a convenção de nomenclatura escolhida é mais importante do que a própria convenção.

Embora possa não ser tão onipresente quanto a versão Java, seguindo o Apache Guia de Estilo PHP certamente não vai doer. Para convenções de nomenclatura:

Naming: FunctionNamesLike, $localVariableName, $objectVariable, ClassNamesLike, MethodNamesLike, CONSTANTS_LIKE_THIS. Global names (classes, functions, variables, defines) must be prefixed to prevent naming clashes with PHP itself. This approach includes preventing prefixes that clash with PHP or are likely to. Apart from constants, prevent underscores in your names unless you simulate namespaces and are sure you can switch to real namespaces once PHP has them (and of course for object variables).

A seguir, os nomes de classe e método seriam PascalCased .

Existem vários outros guias de estilo razoáveis, como listado aqui . A maioria parece concordar que os nomes de classes devem ser PascalCased , mas alguns, incluindo o guia de estilo do MIT, indicam que os métodos devem ser camelCased .

Então, quatro anos depois que eu originalmente respondi a essa pergunta, eu diria que aceite a resposta acima.

Eu pessoalmente acho o camelcase mais natural quando codifico variáveis, mas como as variáveis no PHP fazem distinção entre maiúsculas e minúsculas, e não é divertido procurar pelo código procurando por uma variável que você esqueceu de fazer camelcase, eu sempre uso o caso snake para variáveis.

Embora seja verdade que as convenções sejam mutáveis, codificar depois de alguém que usou camelcase em variáveis e tentar ter certeza de que você sempre usa sua convenção para essa variável, pode ser frustrante.

Temos esse sistema estranho em que tudo tem sua própria convenção:

• ClassesAreLikeThis.
• variablesAndFunctionsLikeThis
• UNLESS_THEY_ARE_CONSTANTS
• andMemberVariablesEndWith _