Por que o uso de conjunções nos nomes de métodos é uma convenção de nomenclatura incorreta? [fechadas]

Na minha equipe, trabalhamos em estreita colaboração com alguns arquitetos de software. Eles aprovam todas as decisões de design de nossos projetos, fazem algumas revisões de código etc.

Nossos projetos consistem principalmente na funcionalidade de back-end implementada em PHP usando a estrutura Symfony 2. Então, sintaticamente, o código, as convenções de nomenclatura e a estrutura do projeto parecem quase idênticas à aparência do Java (o Symfony 2 incentiva essa estrutura). Estou mencionando isso porque convenções específicas de Java também se aplicam ao nosso caso (se possível).

Recentemente, eles sugeriram algo que eu acho muito estranho: todos os métodos devem ter conjunções em seu nome getEntityOrNull, por exemplo , setValueOrExceptionetc.

Essa convenção de nomenclatura parece muito errada para mim, mas não posso apresentar argumentos concretos ou artigos / páginas on-line que especificamente contestem isso.

As únicas coisas que inventei são:

• tais informações devem estar presentes nas anotações do método, como @returnou@throws
• o uso de conjunções ("e", "ou" etc.) nos nomes dos métodos geralmente sugere que o Princípio de Responsabilidade Única não é respeitado adequadamente

Quais são outros argumentos concretos contra essa convenção de nomenclatura?

Provavelmente o estão fazendo devido a conflitos de nomes. Presumo que você não possa ter dois métodos nomeados getEntity, um que possivelmente lança uma exceção e outro que retorne null. Portanto, você deve nomeá-los adequadamente.

Eu, por exemplo, não gosto da prática de ter muitas maneiras diferentes de chamar o mesmo método, a menos que esteja executando alguma alteração que somente essa classe específica possa executar.

Em outras palavras, se getValueOrNullestiver simplesmente chamando getValueOrException, capturando a exceção e, nesse caso null, retornando , isso pode ser realizado pelo chamador. Isso confunde a classe com métodos que realmente não contribuem com nada útil. Em vez disso, prefiro o getValue, e sei que isso gera a exceção. Melhor ainda, eu gostaria de saber que todos os métodos get potencialmente lançar exceções, e nenhum deles voltar nullem vez de modo que o comportamento é uniforme em todo o meu projeto, ou inversamente, todos potencialmente voltar null, e sei que o chamador teria que lançar uma exceção se que foram desejados.

No entanto, também é verdade que você não é responsável por isso. Meu conselho é trazer à tona, mas não se preocupe. Por fim, a responsabilidade de tais convenções de nomenclatura recai sobre seus ombros, independentemente de eles seguirem ou não seus conselhos e, por serem os idiotas deles em jogo, acredito que é prerrogativa deles dizer não, na minha humilde opinião.

Embora o uso de conjunções indique frequentemente uma violação do SRP, neste caso, está apenas indicando o valor de retorno do tipo de dados algébricos de um homem pobre que pode ser um de dois valores, nullou um valor de "sucesso".

Eles estão usando um tipo de notação húngara para compensar deficiências no sistema de tipos, a saber, a falta de tipos não anuláveis. Em outras palavras, não há como especificar na @returnanotação que a função nunca retornará nulle, inversamente, não há como especificar na @returnanotação que a função possa retornar null.

Além disso, acredito que as @throwsanotações não são obrigatórias no php, portanto, a ausência da anotação não indica a ausência de uma exceção, embora isso seja melhor resolvido ao tornar a anotação obrigatória no seu guia de estilo.

Dadas as limitações do idioma que você está usando, não é um estilo totalmente irracional.

No meu código, às vezes crio pares de métodos com nomes como getEntity () e getEntityOrNull (). O nome deixa claro o comportamento esperado. Se getEntity () não encontrar nenhuma entidade, uma exceção será lançada. getEntityOrNull () retornará um valor nulo.

Ao fazer isso, o código de chamada se torna um pouco mais claro. Se o código de chamada precisar ter uma entidade, o getEntity fará o truque. Se entidade é algum tipo de coisa opcional, getEntityOrNull é o método de escolha.

O mesmo poderia ser realizado com um único método, mas isso transfere parte da carga para o programa de chamada. Você sempre precisa testar um nulo ou precisa de um bloco try / catch. De qualquer forma, é um código extra que precisa ser duplicado toda vez que o método é chamado.

Se seus arquitetos não estiverem usando esses tipos de pares de métodos, sim, eu questionaria a necessidade do sufixo.

Nunca vi realmente um método setValueOrException. Não consigo pensar em um bom caso de uso comum para isso.

Você pode perguntar aos arquitetos o porquê. Os que eu conheço sempre ficam felizes em explicar suas decisões. Muitas vezes, com ótimos detalhes (e às vezes torturantes).

Seus dois argumentos são sólidos. Mas se eles são os responsáveis ​​por decidir a convenção de nomenclatura, tente não se sentir tão mal por ser algo com o qual você não concorda.

Enquanto você estiver nisso, convença-os a não usar as partes "get" e "set", a menos que esses métodos realmente definam diretamente ou obtenham uma variável de membro.