ejemplos - Normas de codificación PHP en el trabajo: loco, ¿o sí?

utf-8 encoding

Question

Prefiero que los estándares de codificación sean lógicos. Este es mi argumento de por qué el siguiente conjunto de estándares no lo es.

Necesito saber una de dos cosas: (1) por qué estoy equivocado, o (2) cómo convencer a mi equipo para que los cambie .

camelCase: las funciones, los nombres de clase, los métodos y las variables deben ser camelCase.

• Hace que sea difícil diferenciar entre variables y clases
• Va en contra de las variables / funciones minúsculas / subrayadas de PHP y las clases UpperCamelCase

Ejemplo:

$customerServiceBillingInstance = new customerServiceBillingInstance(); // theirs
$customer_service_billing_instance = new CustomerServiceBillingInstance();

Las funciones / métodos siempre deben devolver un valor (y los valores devueltos siempre deben almacenarse).

Esto aparece en cientos de nuestras páginas php:

$equipmentList = new equipmentList();
$success = $equipmentList->loadFromDatabase(true, '''');
$success = $equipmentList->setCustomerList();
$success = $equipmentList->setServerList();
$success = $equipmentList->setObjectList();
$success = $equipmentList->setOwnerList();
$success = $equipmentList->setAccessList();

El valor de retorno rara vez se usa, pero siempre se almacena. Fomenta el uso de copiar y pegar.

Sin métodos estáticos

Líneas como las siguientes aparecen miles de veces en la base de código:

$equipmentList = new equipmentList();
$success = $equipmentList->loadFromDatabase();

Yo preferiría:

$equipmentList = equipmentList::load();

¿Qué razón hay para no usar métodos o propiedades estáticos? ¿No son los métodos estáticos responsables de la lógica no específica de instancia? ¿Como inicializar o poblar una nueva instancia?

Tu código no es OOP a menos que todo devuelva un objeto

Hay un fragmento de código que realiza una consulta, lo comprueba de varias maneras en busca de errores y luego procesa el conjunto resultante. Se repite (copiado + pegado) varias veces, así que lo puse en la clase base. Luego me dijeron que devolver una matriz no es POO.

¿Cómo defiendes estas prácticas? Realmente necesito saber. Siento que estoy tomando pastillas locas

Si no puede defenderlos, ¿cómo convence al autor firme de que deben ser cambiados?

Answer 1

Si no puede defenderlos, ¿cómo convence al autor firme de que deben ser cambiados?

¡Al dar argumentos fuertes / válidos! ¡Aún así creo que solo debes cambiarlos cuando tus argumentos sean realmente fuertes! Debido a que la mayoría de los programadores en el trabajo están acostumbrados a estos estándares de codificación, es un gran punto el porqué de usarlos.

==

Como otros dijeron antes, esto es bastante subjetivo, pero estas son mis opiniones / argumentos.

1. camelCase: las funciones, nombres de clase, métodos y variables deben ser camelCase.

Usaría el estilo PHP si codifico en PHP y el estilo Camelcase si codigo en Java. Pero no importa qué estilo elijas siempre y cuando te mantengas constante.

2. Las funciones / métodos siempre deben devolver un valor (y los valores devueltos siempre deben almacenarse).

Esto es una tontería en mi opinión. En casi todos los lenguajes de programación tiene algún tipo de tipo ''vacío''. Pero desde un punto de vista de prueba, la mayoría de las veces es útil si su función no tiene efectos secundarios. No estoy de acuerdo en que su código de producción siempre use el valor de retorno, especialmente si no tiene ningún uso.

3. Sin métodos estáticos

Te aconsejo que leas los métodos estáticos son la muerte a la capacidad de prueba de misko

Durante la instanciación cableo las dependencias con simulaciones / amistosos que reemplazan las dependencias reales. Con la programación de procedimientos no hay nada que "cablear" ya que no hay objetos, el código y los datos están separados.

Aunque PHP es un lenguaje dinámico, no es realmente un gran problema. Aún así, el último PHP admite el tipado, por lo que todavía creo que la mayoría de las veces los métodos estáticos son malos.

4. Su código no es OOP a menos que todo devuelva un objeto

Creo (no estoy seguro al 100%) que un verdadero lenguaje OOP debería hacer esto (devolver un objeto), pero no estoy de acuerdo con esto como uno de los mismos idiomas, como por ejemplo Java (que creo que no es realmente OOP). Muchas veces tus métodos deberían devolver primitivas como String / Int / Array / etc. Cuando está copiando y pegando una gran cantidad de código, debe ser una señal de que algo no está del todo correcto con su diseño. Deberías refactorizarlo (pero primero ten una prueba (TDD) lista para que no rompas ningún código).

Answer 2

El único aspecto de esto que no veo a nadie más comentando es el "2. Las funciones / métodos siempre deben devolver un valor (y los valores devueltos siempre deben almacenarse)".

Si no está utilizando excepciones, entonces cualquier función que pueda fallar tiene que devolver un valor. La última cláusula está mal escrita; los valores devueltos no siempre se DEBEN ALMACENAR, pero siempre se deben VERIFICAR. De nuevo, eso es SI no estás usando excepciones, lo cual no es común en estos días, pero aún así vale la pena mencionarlo.

Answer 3

Los estándares y las convenciones existen por muchas razones, pero la mayoría de estas razones se reducen a "hacen que el código sea más fácil de escribir y mantener". En lugar de preguntar "¿es esta la forma correcta de hacer X?" simplemente corte a la persecución y pregunte si este criterio se cumple. El último punto en particular es simplemente una cuestión de definición. OOP es un medio, no un fin.

Answer 4

Muchos de esos son asuntos de gusto. Puedes argumentar a favor o en contra de camelCase todo el día.

Sin embargo, el almacenamiento de valores devueltos que nunca se utilizan es Incorrecto. No hay valor para el código. El código no se ejecuta. También podría rociar $foo = 47 * 3; alrededor del código.

Cualquier código que no esté haciendo algo útil debe ser eliminado.

El problema más grande es que, si trabajas para un gerente desorientado, puede ser hora de mudarte.

Answer 5

Muchos de estos estándares de codificación son muy subjetivos, pero algunas cosas importantes a considerar son:

1. Obtenga un solo conjunto de nombres de código y reglas de estilo, y sígalos. Si aún no tiene reglas definidas, asegúrese de obtener reglas resueltas. Luego, trabaje en la refactorización del código para seguirlos. Este es un paso importante para facilitar que los nuevos desarrolladores se unan y mantengan la codificación coherente entre los desarrolladores.

2. Lleva tiempo y esfuerzo cambiar los estándares de codificación que su compañía implementa. Cualquier cambio en las reglas significa que el código tiene que pasar de nuevo para actualizar todo para que sea coherente con los nuevos estándares.

Teniendo en cuenta lo anterior, y mirando más a lo largo de las líneas de estándares específicos de codificación PHP. Lo primero que debe observar es si su empresa utiliza algún tipo de marco, consulte los estándares de codificación para ese marco, ya que es posible que desee mantenerlos para mantener la coherencia en todo el código. A continuación, he enumerado enlaces a algunos de los frameworks populares de PHP:

1. Convenciones de nomenclatura de Zend Framework y estilo de Zend Framework Code
2. Estándares de Pera

Mi preferencia personal con respecto a tus estilos de codificación específicos:

1. camelCase: las funciones, nombres de clase, métodos y variables deben ser camelCase

Los nombres de las clases deberían ser Pascal Case (Caso Camel superior).

Entonces en tu ejemplo:

class CustomerServiceBillingInstance
{
// Your class code here
}

Variables y funciones , generalmente, creo que deberían ser camello.

Entonces cualquiera de estos, dependiendo de su preferencia en términos de guiones bajos:

$customerServiceBillingInstance = whatever;
$customer_service_billing_instance = whatever;

2. Las funciones / métodos siempre deben devolver un valor (y los valores devueltos siempre deben almacenarse).

Éste parece un código extra y puede terminar usando recursos adicionales. Si una función no necesita devolver nada, no devuelva nada. Del mismo modo, si no le importa qué devuelve una función, no la almacene. No tiene sentido usar la memoria extra para almacenar algo que nunca vas a mirar.

Una cosa interesante que puede probar en este caso es ejecutar algunos puntos de referencia. Vea si le toma más tiempo devolver algo y almacenarlo aunque no lo esté mirando.

3. Su código no es OOP a menos que todo devuelva un objeto

En este caso, siento que tienes que trazar la línea en alguna parte. En cuanto a rendimiento, es más rápido para usted:

return false;

Que hacer:

return new Boolean(false); // This would use up unnecessary resources but not add very much to readability or maintainability in my opinion.

Defender un estándar de codificación

Para defender un estándar de codificación que consideras correcto (o mostrar por qué otro no es tan bueno), realmente vas a tener que mencionar uno de dos puntos.

1. Rendimiento Si puede demostrar que un estándar de codificación particular está afectando adversamente el rendimiento, puede considerar cambiar.

2. Mantenibilidad / legibilidad Tu código debería ser fácil de leer / entender.

El objetivo es encontrar la mediana feliz entre el rendimiento y la facilidad de mantenimiento / legibilidad. A veces es una decisión fácil porque la opción que más se puede mantener también es la mejor, otras veces hay una opción más difícil de realizar.

Answer 6

Sugiero tratar de enumerar los objetivos de sus estándares de codificación y ponderarlos según cuáles sean los objetivos más importantes y cuáles sean menos importantes.

PD: No hablo PHP, por lo que algunos de estos argumentos pueden contener código PHP descaradamente incorrecto.

camelCase: las funciones, los nombres de clase, los métodos y las variables deben ser camelCase.

Razón aparente del lugar de trabajo: "consistencia" a costa de "densidad de información en el nombre".

Argumento:

1) Dado que la palabra clave ''nueva'' siempre debe ser seguida por una clase, entonces puede detectar fácilmente la creación de instancias ilegales, por ejemplo:

$value = new functionName();
$value = new local_variable();
$value = new GLOBAL_VARIABLE();

levantaría una alarma, porque ''nuevo'' debería ir seguido de un nombre de TitleCase.

$value = new MyClass(); // correct

Confiar en Case hace que sea fácil detectar estos errores.

3) Solo se pueden llamar funciones, nunca se pueden llamar variables. Al confiar en la regla de casos, entonces podemos detectar fácilmente llamadas a funciones sospechosas como:

$value = $inst->ClassName();
$value = $inst->instance_variable();
$value = $GLOBAL_VARIABLE(); 

3) Asignar a un nombre de función y variables globales es un gran problema, ya que a menudo conducen a un comportamiento que es difícil de seguir. Es por eso que cualquier declaración que se ve así:

$GLOBAL = $value;
$someFunction = $anotherFunction;

debe ser muy analizado. Usando Case Rule, es fácil detectar estas posibles líneas problemáticas.

Si bien la regla de caso exacta puede variar, es una buena idea tener una regla de caso diferente para cada tipo de nombre diferente.

Las funciones / métodos siempre deben devolver un valor (y los valores devueltos siempre deben almacenarse).

Razón aparente del lugar de trabajo: al parecer, otra regla nacida de la consistencia ciega. La ventaja es que cada línea de código que no es un control de flujo (por ejemplo, bucle, condicionales) es una asignación.

Argumento:

1) La asignación obligatoria crea líneas largas innecesarias, lo que perjudica la legibilidad ya que aumenta la cantidad de información irrelevante en la pantalla.

2) El código es un poco más lento ya que cada llamada de función implicará dos operaciones innecesarias: retorno de valor y asignación.

Mejor Convención:

Aprende del paradigma de programación funcional. Haga una distinción entre "subrutina" y "funciones". Una subrutina hace todos sus trabajos por efecto secundario y no devuelve un valor, y por lo tanto su valor de retorno nunca necesita almacenarse en ningún lugar (la subrutina no debe devolver el código de error, use la excepción si es realmente necesario). Una función no debe tener ningún efecto secundario y, por lo tanto, su valor de retorno se debe usar inmediatamente (ya sea para realizar más cálculos o almacenarse en algún lugar). Al tener una política de función libre de efectos secundarios, es un desperdicio del ciclo del procesador llamar a una función e ignorar su valor de retorno; y la línea, por lo tanto, puede eliminarse.

Entonces, hay tres tipos de llamadas correctas:

mySubroutine(arg);            // subroutine, no need to check return value
$v = myFunction(arg);         // return value is stored
if (myFunction(arg)) { ... }  // return value used immediately

nunca deberías tener, por ejemplo:

$v = mySubroutine(arg);  // subroutine should never have a return value!
myFunction(arg);         // there is no point calling side-effect free function and ignoring its return value

y deberían alertar. Incluso puede crear una regla de denominación para diferenciar entre subrutinas y funciones para que sea aún más fácil detectar estos errores.

Específicamente, no permite tener un monstruo "functirrutina" que tenga un efecto secundario y un valor de retorno.

Sin métodos estáticos

Motivo aparente en el lugar de trabajo: probablemente alguien haya leído en alguna parte que la estática es malvada, y la sigue a ciegas sin hacer realmente una evaluación crítica de sus ventajas y desventajas

Mejor Convención:

Los métodos estáticos deberían ser sin estado (sin modificar el estado global). Los métodos estáticos deben ser una función, no una subrutina, ya que es más fácil probar una función libre de efectos secundarios que probar los efectos secundarios de una subrutina. El método estático debe ser pequeño (~ 4 líneas como máximo) y debe ser autónomo (es decir, no debe llamar a demasiados métodos estáticos demasiado). La mayoría de los métodos estáticos deberían vivir en la clase de Utilidad; excepciones notables a esto son las Fábricas de Clase. Se permiten excepciones a esta convención, pero deben ser escrutadas cuidadosamente de antemano.

Tu código no es OOP a menos que todo devuelva un objeto

Razón aparente en el lugar de trabajo: comprensión errónea de lo que es OOP.

Argumento:

Los tipos de datos fundamentales también son conceptualmente un objeto, incluso si el tipo de datos fundamental de un idioma no hereda de su clase Object.

Answer 7

Por lo que sé, bastantes de las convenciones que publicaron también son alentadas por Zend PHP Framework. No estás solo, soy un usuario de Codeigniter y mi trabajo es muy importante en el uso de Zend Framework. Este tipo de convenciones de nombres son absolutamente ridículos y, sinceramente, solo puedo ver una ventaja de usar camelCase para nombres de variables, no nombres de funciones, ya que hace que las cosas sean confusas.

Lea esto: http://framework.zend.com/manual/en/coding-standard.naming-conventions.html

¿Estas convenciones de codificación le resultan familiares?