Por que não prefixamos enums, classes abstratas e estruturas?

A comunidade C # usou de maneira tão onipresente o prefixo "I" para denotar uma interface que até os programadores mais inexperientes sabem usá-lo.

Por que é que não prefixamos enumerações, classes abstratas ou estruturas (possivelmente com "E", "A" e "S" respectivamente)?

Por exemplo, se marcássemos todas as classes abstratas com um "A", forneceria informações valiosas sobre esse tipo que, embora possa ser inferido, não é imediatamente óbvio.

Observe que não estou advogando por essa mudança; estou apenas tentando entender por que não fazemos as coisas dessa maneira.

Este tópico responde por que usamos o prefixo "I", mas não responde por que não usamos outros prefixos.

O objetivo da convenção de nomenclatura para interfaces é fornecer uma decisão rápida e sem cérebro sobre o que chamar de interface que sua classe implementa. Se você tem uma Frobnicator, mas precisa declarar uma interface para desacoplar ou qualquer outra razão, a decisão de chamá-la IFrobnicatornão requer pensamento consciente, e isso é bom.

O mesmo problema não se aplica a outras construções que você nomeia. Enums e estruturas são úteis, mas não é necessário encontrar um segundo nome , curto, transparente e obviamente relacionado, além do próprio nome. Portanto, não há pressão para colocar um 'E' no nome de uma enumeração ou estrutura.

(As classes abstratas são um pouco semelhantes às interfaces, já que você precisa fornecer uma segunda classe concreta para fazer qualquer coisa, para que elas possam ter adquirido uma convenção de começar com 'A', mas por qualquer motivo, não o fizeram. Estou autorizado a especular, acho que 'eu' sendo uma carta particularmente estreita pode ter algo a ver com isso.)

Eu acho que não é muito usado porque:

• na maioria das vezes, não importa muito se é uma enumeração, uma classe abstrata ou uma estrutura
• se fizer isso, provavelmente posso vê-lo do uso e descobrir rapidamente
• se eu mudar como enum, classe abstrata ou estrutura, também tenho que renomeá-lo
• para pessoas que não conhecem a convenção, é puro ruído.
• as pessoas podem simplesmente descartar toda a ideia porque foram ensinadas a não usar a notação húngara. Houve e ainda há pessoas que dizem que você não deve usar a notação Hungarion, sem fazer a distinção entre Apps Hungarian e Systems Hungarian. Uma boa discussão pode ser encontrada nesta questão SO . Não apenas a primeira resposta é interessante, mas há ótimas respostas e comentários. Da mesma pergunta, vem o artigo de Joel Spolsky (vá para o parágrafo "Sou a Hungria")

em resumo: em geral, o valor agregado não compensa o custo.

A partir desse último item e alguma interpretação, você pode concluir. Sistemas húngaro (tipo de prefixo) é ruim e não deve ser usado. O Apps Hungarian (tipo de prefixo) possui.

Retirando isso da sua pergunta, acho que a notação proposta é uma forma de aplicativos húngaro e se você acha que o valor agregado aumenta os custos e o implementa de forma consistente em sua base de código, tudo bem. Mas como você deve considerá-lo por projeto, não deve ser uma regra geral.

Eu acho que as pessoas notaram que ele se importava com interfaces com mais frequência e é por isso que se tornou uma regra geral para interfaces.

Apenas um pensamento (espero que seja aplicável):

Há uma tendência óbvia para 'codificar para interfaces' em vez de classes concretas. "Hoje em dia", parece quase mais benéfico ter uma convenção de nomenclatura para as classes, como iniciá-las com um 'C', em vez de ter a letra 'I' para a interface.

Acabei de finalizar um projeto Java no qual todas as interfaces eram na verdade chamadas Model. Sim, a convenção de nome de interface era terminar o nome com 'Model' ... então, algum tipo de 'DataTransferObject / DTO' implementa a interface como :

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

enquanto que em c #

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

Reconfigurando meu cérebro para manter essa dor direta, mas posso ver como isso pode ajudar a pensar nos termos de programação da interface.