Clasificar nombres, métodos, funciones y variables [duplicar]

Tuve la misma pregunta hace aproximadamente un año, así que miré un código yo mismo. Esto es lo que encontré (las constantes eran ALL_CAPS en cada proyecto, por cierto):

╔═══════════════════════╦═════════════╦════════════╦══════════════╦════════════╦════════════╗
║      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  ║
╚═══════════════════════╩═════════════╩════════════╩══════════════╩════════════╩════════════╝

Así que después de ver todo esto, decidí ir con:

• ClassName
• methodName
• propertyName
• function_name (destinado a funciones globales)
• $variable_name

No existe el "estilo de codificación más popular", es estrictamente una cuestión de las convenciones y preferencias personales de su equipo. Ya que está apuntando a los desarrolladores, debe buscar convenciones populares para su plataforma y seguir la que considere más conveniente, legible y, mejor, más cercana a su estilo personal. Para PHP, un conjunto popular de convenciones de nombres es Zend Framework's .

Ser consistente con la convención de nomenclatura que eliges es más importante que la convención en sí misma.

Si bien puede que no sea tan ubicua como la versión de Java, siguiendo Apache PHP Style Guide ciertamente no te hará daño. Para convenciones de nomenclatura:

  

Nombre: FunctionNamesLike, $ localVariableName, $ objectVariable,   ClassNamesLike, MethodNamesLike, CONSTANTS_LIKE_THIS. Nombres globales   (clases, funciones, variables, definiciones) deben ser prefijadas para prevenir   nombrar choques con el propio PHP. Este enfoque incluye prevenir   Prefijos que chocan con PHP o es probable que lo hagan. Aparte de las constantes,   evita los guiones bajos en tus nombres a menos que simules espacios de nombres y   están seguros de que puede cambiar a espacios de nombres reales una vez que PHP los tenga (y de   curso para variables de objeto).

Después de esto, los nombres de clase y método serían PascalCased .

También hay una serie de otras guías de estilo razonables, como aquí . La mayoría parece estar de acuerdo en que los nombres de clase deben ser PascalCased pero algunos, incluyendo la guía de estilo MIT, indican que los métodos deben ser camelCased .

Por lo tanto, cuatro años después de que respondí originalmente esta pregunta, diría que acepté la respuesta aceptada arriba.

Personalmente, creo que camelcase es más natural cuando codifica variables, pero como las variables en PHP son sensibles a las mayúsculas y minúsculas, y no es divertido buscar código en una variable que se olvidó de hacer camelcase, siempre utilizo snatch case para variables.

Si bien es cierto que las convenciones son mutables, codificar a alguien que ha usado camelcase en las variables, y tratar de asegurarse de que siempre se use su convención para esa variable, puede ser frustrante.

Tenemos este sistema extraño donde todo tiene su propia convención:

• ClassesAreLikeThis.
• variablesAndFunctionsLikeThis
• UNLESS_THEY_ARE_CONSTANTS
• yMemberVariablesEndWith_