¿Por qué el uso de conjunciones en los nombres de métodos es una mala convención de nomenclatura? [cerrado]

7

En mi equipo, trabajamos estrechamente con algunos arquitectos de software. Aprueban todas las decisiones de diseño de nuestros proyectos, hacen algunas revisiones de código, etc.

Nuestros proyectos consisten principalmente en la funcionalidad de back-end implementada en PHP usando el framework Symfony 2. De manera sintáctica, el código, las convenciones de nomenclatura y la estructura del proyecto parecen casi idénticas a las que tendría Java (Symfony 2 fomenta dicha estructura). Menciono esto porque las convenciones específicas de Java también se aplican en nuestro caso (si es posible).

Recientemente, sugirieron algo que me parece muy extraño: todos los métodos deben tener conjunciones en su nombre, por ejemplo. getEntityOrNull , setValueOrException etc.

Tal convención de nomenclatura me parece muy mal, pero no puedo encontrar ningún argumento concreto o artículos / páginas en línea que cuestionen específicamente esto.

Lo único que se me ocurrió es:

  • dicha información debe estar presente en las anotaciones del método, como @return o @throws
  • el uso de conjunciones ("y", "o" etc.) en los nombres de los métodos generalmente sugiere que el Principio de Responsabilidad Única no se respeta adecuadamente

¿Cuáles son algunos otros argumentos concretos en contra de esta convención de nomenclatura?

    
pregunta Radu Murzea 08.09.2014 - 09:55

4 respuestas

9

Probablemente lo están haciendo debido a conflictos de nombres. Supongo que no puede tener dos métodos llamados getEntity , uno que posiblemente arroje una excepción y uno que devuelva null . Por lo tanto, tienes que nombrarlos en consecuencia.

Por mi parte, no me gusta la práctica de tener muchas formas diferentes de llamar al mismo método a menos que esté realizando alguna modificación que solo esa clase en particular pueda realizar.

En otras palabras, si getValueOrNull simplemente llama a getValueOrException , captura la excepción y, en ese caso, devuelve null , la persona que llama puede realizar esto. Llena a la clase con métodos que realmente no aportan nada útil. Más bien, preferiría el getValue y saber que produce la excepción. Mejor aún, preferiría saber que todos los métodos de obtención pueden generar excepciones, y ninguno de ellos devuelve null , por lo que el comportamiento es uniforme en todo mi proyecto, o inversamente, todos potencialmente devuelven null y saben que la persona que llama Tengo que lanzar una excepción si se desea.

Sin embargo, también es cierto que no estás a cargo de eso. Mi consejo es que lo mencione, pero no se preocupe por las cosas insignificantes. En última instancia, la responsabilidad de tales convenciones de nomenclatura recae sobre sus hombros, independientemente de que sigan o no su consejo, y porque son sus culos en la línea, creo que es su prerrogativa decir que no, en mi humilde opinión. p>     

respondido por el Neil 08.09.2014 - 10:10
3

Aunque el uso de conjunciones a menudo indica una violación del SRP, en este caso solo indica el valor de retorno del tipo de datos algebraico de un hombre pobre que puede ser uno de dos valores, ya sea null o un "éxito" valor.

Están utilizando una especie de Notación Húngara para compensar las debilidades en el sistema de tipos, a saber, la falta de tipos anulables En otras palabras, no hay forma de especificar en su anotación @return que la función nunca devolverá null y, a la inversa, no hay manera de especificar en su anotación @return que la función posiblemente pueda devolver null .

Además, creo que @throws anotaciones no son obligatorias en php, por lo que la ausencia de la anotación no indica la ausencia de una excepción, aunque eso se soluciona mejor haciendo la anotación obligatoria en su guía de estilo.

Dadas las limitaciones del lenguaje que estás usando, no es un estilo totalmente irrazonable.

    
respondido por el Karl Bielefeldt 08.09.2014 - 18:32
2

En mi código a veces creo pares de métodos con nombres como getEntity () y getEntityOrNull (). El nombre aclara el comportamiento esperado. Si getEntity () no encuentra ninguna entidad, se lanza una excepción. getEntityOrNull () devolverá un nulo.

Al hacer esto, el código de llamada se vuelve un poco más claro. Si el código de llamada tiene que tener una entidad, entonces getEntity hará el truco. Si la entidad es una especie de cosa opcional, entonces el método de elección es getEntityOrNull.

Lo mismo podría lograrse con un solo método, pero eso desplaza parte de la carga al programa de llamadas. Siempre necesita probar un nulo o necesita un bloque try / catch. De cualquier manera, es un código adicional que debe duplicarse cada vez que se llama al método.

Si sus arquitectos no usan este tipo de pares de métodos, entonces sí, me gustaría cuestionar la necesidad del sufijo.

Nunca vi realmente un método setValueOrException. No puedo pensar en un buen caso de uso común para eso.

Podría considerar preguntar a los arquitectos por qué. Los que conozco siempre están encantados de explicar sus decisiones. A menudo con gran detalle (ya veces insoportable).

    
respondido por el Cerad 08.09.2014 - 16:59
1

Tus dos argumentos son sólidos. Pero si son los encargados de decidir la convención de nombres, trate de no sentirse tan mal por ser algo con lo que no está de acuerdo.

Mientras estás en eso, debes convencerlos de que no usen las partes "obtener" y "establecer" a menos que esos métodos realmente establezcan directamente u obtengan una variable miembro.

    
respondido por el Eben 08.09.2014 - 10:00

Lea otras preguntas en las etiquetas