Quais anti-padrões de nomes existem? [fechadas]

Existem alguns nomes em que, se você os encontrar, sabe que já estragou algo.

Por exemplo:

XxxManager
Isso é ruim porque uma classe deve descrever o que a classe faz. Se a palavra mais específica que você pode apresentar para o que a classe faz é "gerenciar", então a classe é muito grande.

Quais outros anti-padrões de nomes existem?

Para esclarecer, não estou perguntando "que nomes são ruins" - essa pergunta é inteiramente subjetiva e não há como responder. Estou perguntando: "quais nomes indicam problemas gerais de design com o sistema". Ou seja, se você deseja chamar um componente Xyz, isso provavelmente indica que o componente está mal oculto. Observe também aqui que há exceções em todas as regras - só estou procurando sinalizadores de aviso para quando realmente preciso parar e repensar um design.

Os seguintes anti-padrões de nomenclatura estão relacionados ao .NET e, especialmente, ao C #:

• Inconsistências . Se você decidiu iniciar cada nome de campo com um sublinhado à esquerda, cumpra-o .
• Abreviações ambíguas com vogais ausentes . Eu vi seriamente nomes de campos como cxtCtrlMngr. Você mal consegue adivinhar o que isso significa.
• Nomes de variáveis ​​muito longos e detalhados . ILoginAttemptRepositoryé bom e descritivo - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappingé descritivo, mas definitivamente não é bom.

Um que eu encontro frequentemente é simplesmente não usar nenhum padrão de nomenclatura. Tipicamente indicativo de ignorância do desenvolvedor (que os padrões de nomenclatura são uma coisa boa ) e também esse antipadrão tende a violar bruscamente o SRP, colocando todos os tipos de métodos que estão relacionados à classe nessa classe, por exemplo, um Cliente A classe possui propriedades, métodos CRUD, qualquer coisa remotamente relacionada a um Cliente que alguma parte do aplicativo precise.

Também acrescentarei que usar "Engine" como sufixo é o mesmo que usar "Manager". É muito vago e uma classe chamada XxxEnginetende a ser o que equivale a um módulo no estilo VB, contendo vários métodos, por isso é um local "fácil de usar", sem nenhum conhecimento ou idéia de programação orientada a objetos.

Bem, respostas simples primeiro: digite húngaro ( http://mindprod.com/jgloss/unmainnaming.html , também tem outras ótimas idéias. Uma visão mais equilibrada sobre quando húngaro não é mau, http://www.joelonsoftware.com /articles/Wrong.html )

Prefixar um 'I' ao nome de uma interface ou 'Resumo' ao nome de uma classe abstrata. Isso pode ser desculpável em linguagens que não têm o conceito de classes abstratas ou que não diferenciam interfaces e classes abstratas - mas em Java, por exemplo, é sempre uma má idéia.

Além disso, não concordo com você na questão do gerente. Eu uso esse padrão algumas vezes e significa que, se eu tentasse dar outro nome a ele, o nome não seria mais descritivo que o XxxxxManager. Existem algumas tarefas (não necessariamente complexas) que simplesmente não podem ser resumidas em uma ou duas palavras.

Speeling:

Eu tenho uma deficiência inclinada e não consigo soletrar. Sem o corretor ortográfico, sou impotente, tento copiar todos os nomes criados para um processador de texto para verificação, mas sempre sinto falta de alguns. No meu último projeto, escrevi grande parte da API e acho que não fiz a verificação ortográfica na primeira vez em que usei a palavra resposta e presumi que ela estava certa, porque ninguém me contou. Tínhamos pelo menos 50 funções com resposta. Uma nova pessoa entrou na equipe e perguntou por que usamos o responder. Eu me senti muito idiota.

Bem, receio que minhas opiniões sejam um pouco controversas. Mas vamos tentar ...

No que me diz respeito, tenho que concordar com Mike Baranczak, nomes como XxxController, XxxHandler é algo que realmente usamos com frequência. Para nós, um Controller é algo como um ponto de entrada para algo "encapsulado", por exemplo, gerenciar transações, lidar com erros inesperados, chamar o XxxHandler para realizar o trabalho real. Eu diria que um XxxManager é sinônimo de um controlador. Eu acho que é importante não usar o Manager em um caso e o Controller em outro. Ser consistente é muito importante se você trabalha em equipe.

Seria muito difícil ou talvez nem seja possível encontrar nomes melhores para coisas como essa. Xxx deve ser bem escolhido para tornar a situação mais clara.

Pessoalmente, o que eu não gosto é que, quando um método chamado get ... ou set ... é mais do que um simples acessador. Eu gosto de det ... para determinar.

Outra coisa que me vem à cabeça: segundo o tio Bob. Um "E" em um nome de método é um sinal de muito esforço. Mas a vida nem sempre é apenas em preto e branco - há situações em que acho que tudo bem - por exemplo. devido a problemas de desempenho (quando você já possui os dados, verifique por que não processá-los) ...

Pessoalmente, também sou um grande fã da notação húngara de sistemas - na maioria das vezes você está lidando com código fonte em um IDE ok. Mas muitas vezes você está usando apenas um editor ou está navegando no repositório em um navegador. Uma desvantagem pode ser o suporte a ferramentas devido a prefixos de tipo ...

Acho que o mais importante é ser consistente - uma convenção subótima - para mim - é melhor do que não ter nenhuma convenção ...

Talvez o pior anti-padrão de nomeação seja este:

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

Temos uma lista de três elementos de pares [foo, bar]. Se precisarmos de um quarto, teremos que adicionar novas colunas à tabela.

Levando ao código assim:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

Uma tabela separada deve ser criada com as colunas foo e bar e vinculada à tabela de itens:

create table fubar(foo string, bar string, stuff_id long)

O segundo pior é o seguinte:

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

Aqui temos seis campos em vez de duas instâncias de uma classe Address.

Esse antipadrão é marcado por uma série de nomes de duas partes que listam todas as combinações de dois conjuntos, por exemplo, [foo, bar] x [1,2,3] ou [casa, permissão] x [rua, cidade, estado]

Qualquer nomeação de classe ou interface que seja tautológica é ruim, não apenas em Java sobre o qual o link fala, mas em qualquer idioma.

Tautologia (retórica), usando palavras diferentes para dizer a mesma coisa, mesmo que a repetição não forneça clareza.

Frequentemente encontro bibliotecas de software com nomes genéricos como Libraryou Common. Eles indicam design abaixo do ideal: os desenvolvedores se esforçam para evitar a duplicação de código, mas sem qualquer tentativa de criar um design decomposto com base na funcionalidade.

Na Microsoft sobre nomes, posso fornecer esta lista para nomes incorretos:

1. Eles não são semânticos, o que significa que eles têm nomes que, em vez de enfatizar o que faz, enfatizam a tecnologia usada ou o padrão em que se baseia .
2. Eles não seguem uma consistência sintática. Por exemplo, parte dos nomes são revestidos com camelo, enquanto outra parte é revestida com pascal.
3. São abreviações difíceis de entender, como ScrollableX em vez de CanScrollHorizontally
4. Eles são escolhidos de forma a mexer com as palavras-chave desse ambiente.