Executando verificação de segurança...
2

C# e as nomenclaturas

Recentemente assisti um vídeo de um youtuber realizando um teste lógico com 25 linguagens diferentes e queria entender por que C#, fugiu muito do padrão de nomenclatura.

Nomenclatura digo a utilização de PascalCase, enquanto as outras linguagens utilizam camelCase ou as chaves:

`{

}, ao invés {

}`

Tem muita coisa nas nomenclaturas em C#, que achei uma ideia ótima em adicionar I, pra indicar que é um interface ou _, para indicar que o campo é privado.

Um exemplo disso é o typescript, sendo desenvolvido pelo mesmo criador do C#, não deixou adequado essa mesma nomenclatura... por que?

4

A formatação de código do C# recebeu diversas influencias do Java (seu competidor direto quando foi criado, hoje não é mais) e também de outras linguagens mantidas pela Microsoft na época como VisualBasic.

Dificilmente alguém vai ter uma resposta precisa de pq as chaves na formatação padrão do Visual Studio começa na linha abaixo da primeira linha do bloco. Talvez isso facilite para a IDE onde começa e termina cada bloco, talvez fosse uma necessidade para o processo de compilação quando ela foi criada e se manteve assim. No fim, isso é apenas uma convenção, nada vai parar de funcionar por conta da formatação do código.


Quanto ao padrão de usar I para interfaces, eu já acho que isso é um padrão ruim. Quando a única coisa que diferencia o nome da classe da sua interface é a letra I, provavelmente você não precisa de uma interface.

Já vi códigos onde havia apenas uma classe para a interface, por exemplo:

    interface IDbConnection
    class DbConnection : IDbConnection

A intenção é boa, mas só adiciona complexidade pois se é 1 pra 1, não precisa de interface.

Agora se sua aplicação pode ter diferentes implementações, aí começa a fazer sentido:

    interface DbConnection
    class MySQLDbConnection : DbConnection
    class SQLiteDbConnection : DbConnection
    class OracleDbConnection : DbConnection

Nesse cenário, faz sentido ter uma interface pois a aplicação espera uma variação de implementações, e a própria nomenclatura das classes indica que não precisa do I na interface.

"Ah, mas vai que um dia eu precise de mais uma implementação de conexão...", quando esse dia chegar você cria a interface e as implementações, enquanto ele não chega, use apenas uma implementação e mantenha as coisas simples.

2

Mano, o padrão é usar I em todas as interfaces, não apenas em relação 1:1. Até porque a implementação diz respeito mais sobre o teu código do que sobre o padrão da linguagem.

Sempre que tu for implementar uma interface tu sabe já de antemão que é uma interface pelo prefixo I. Isso é particularmente importante quando o padrão extends/implements se aplicam da mesma forma através de um simples ":".

1

Sobre PascalCase, pensei que fosse uma nomenclatura antiga da Microsoft, por conta das pastas de arquivos do Windows, serem desse jeito. Isso influenciou até numa boa visibilidade, pois no lançamento do Java, por conta dos processos talvez MS gostaria de fazer diferente.

Sobre I na interface, achei uma ótima ideia por questões que voce sabe quando será uma Interface por causa da visibilidade, ao contrario do Java que voce precisa abrir a documentação do método/atributo e verificar se é uma interface, etc.

1

Sobre I na interface, achei uma ótima ideia por questões que voce sabe quando será uma Interface por causa da visibilidade, ao contrario do Java que voce precisa abrir a documentação do método/atributo e verificar se é uma interface, etc.

Não faz muito sentido né? Se você vai usar uma classe ou interface o mínimo que você precisa saber é o que ela oferece, normalmente lendo a documentação. Começar com I ou não, nesse caso não ajuda em nada.

Por exemplo, o que mudaria para você saber que IDbConnectioné uma interface? Se você não conhece-la, não ajudar muito de qualquer forma.

Agora imagina uma classe chamada DbConnection, não existem variações no seu sistema então DbConnection é a única classe que implementa o que você precisa. Se por ventura você precisar de variações, você pode converter a classe para uma interface sem mudar seu nome, e gerar classes derivadas como MySQLDbConnection e PostgreSQLDbConnection que implementem a interface DbConnection e tudo continuará funcionando.

Usar o I para interface me lembra a notação húngara que era usada muitos anos atrás, onde variáveis de texto começam como str, txt ou s, por exemplo:

  • strNomeCliente
  • txtEndereco
  • sEmail
  • intIdade
  • iDia
  • dtNascimento
  • ... e por aí vai

Se você precisa do I para diferenciar uma interface, então precisaria do A para uma classe abstrata (ADbConnection) certo? E do S para uma struct (SPessoa) não é?

Percebe que o I é só um ruído de um passado onde as IDEs não ofereciam tantas informações e a documentação não era tão acessível?

1

Sobre o I nas interfaces, geral não gosta e fala que não é uma boa pratica. Até entendo o ponto deles, mas na verdade é que não existe certo ou errado aqui. Honestamente eu gosto, vc bate o olho e já sabe se é uma classe ou interface, principalmente qdo tá olhando código no git. Enfim, eu sempre utilizo nos meu projetos seja lá a linguagem q tô usando.

No java, já vi vários projetos com o tenebroso "impl" nas classes. Aí já é demais...

Sobre as chaves, nesse ponto sou indiferente. Gosto dos 2 jeitos. Uso o padrão da linguagem.

Sobre a nomeclatura, eu tbm utilizo o padrão da linguagem. Mas se puder optar, uso PascalCase para o nome dos métodos e classes, e camelCase para variáveis.

O _ tbm é considerado má pratica. Até mesmo no C#, se baixar um linter qualquer fora o padrão do VS, vai ver que reclamam da utilização e sugerem o uso do 'this'. Estou me forçando a não utilizar o _ , mas confesso que ainda sinto falta.

1

Na verdade, os membros privados internos do .NET usam o padrão m_. Eu acho que nenhuma informação sobre tipo, acessibilidade etc... deva constar do nome do membro.
O que entendo ser correto e elegante é usar algumas convenções mais semânticas, como substantivos para propriedade e verbos no infinitivo para função, por exemplo.

1

É um pouco estranho utilizar this, com pascalcase.
Sobre impl é realmente horrivel aquilo no Java.
No Java tu apenas sabe o que é uma constantes, por que o resto e totalmente ruim de visualizar de primeira sem ficar caçando documentação

1

O padrão de chave é aberto pelo guideline do C#, mas como por padrão as ferramentas usam uma em cada linha, a doc também, acaba que todo mundo usa assim, trabalhei em uma empresa que usava na mesma linha, o código fica muito mais limpo.

sobre o PascalCase, provavelmente é herança do Visual Basic, pois lá TUDO é assim: IF, Else, True, False...

O prefixo I nas interfaces é de longe a melhor coisa que eu já vi, pois só de bater o olho tu já sabe do que se trata, fica muito mais legível.

Atributos privados com prefixo _ se não me engano é uma prática do Python e do JS/TS também é cai no mesmo conceito das interfaces, só de bater o olho tu já sabe o que é.

1
1

No fim, de maneira simples, se resume a cultura. TS é do mesmo criado, mas para ter adoção precisava respeitar a cultura do ecossistema JS. Assim como C# seguia respeitando a cultura dos desenvolvedores do ecossistema Microsoft (VB).

1

Contribuir com 10 centavos sobre o padrão de chaves, nas versões iniciais do C#, ele apontava erro quando não estava no padrão :

"{
}"

Isso foi ajustado, mas se mantém essa prática até hoje, aprendi isso na faculdade, eu particulamente gosto muito disso, acho que no final fica bem mais amarrado a questão de fechar e abrir chaves.