C# e as nomenclaturas

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.

A ideia de usar o I é gambiarra. Havia problemas de conflito de nomes e o I foi usado para resolver isso. Você não tem que saber se é uma interface ou não. A ideia toda do mecanismo é não precisar isso. Mas pode ter casos que saber seja útil, aí você precisa saber muito mais do que só se é interface.

Mas mesmo que tenha uma só classe usando a interface não quer dizer que no futuro não possa ter outras e se você não tinha criado a interface quando acontecer isso todo lugar usou a classe e agora não é algo genérico e você terá que mexer em todo seu código, e se não tiver acesso a todo ele a desgraça está feita, por exemplo o .NET não tem acesso ao seu código. Veja mais: https://pt.stackoverflow.com/q/86484/101. Também pode ser útil: https://pt.stackoverflow.com/q/107524/101.

Se entendi sobre as chaves eu uso a de baixo, não existe um padrão oficial de C# como deve usar. O fato de ter um template do Visual Studio que põe assim significa que o pessoal do VS prefere assim. Hoje boa parte das pessoas preferem o primeiro, programadores raiz tendem a preferir mais o segundo, acham que o código fica mais limpo assim.

Usar _ para campos privados não é padrão de C#, algumas pessoas usam, mas é opção delas. Embora não seja uma recomendação explícita é desincentivado. É gambiarra. Não importa que até dentro do .NET use coisas assim, vai contra o estilo, e mais amplamente considerado algo ruim, quem o faz é por vício, e apesar de não grandes, traz problemas.

C# usa camelCase para variáveis locais, então faz sentido que algo de maior importância seja diferente e tenha mais destaque, e o PascalCase funciona bem. A pergunta é por que outras linguagens modernas copiaram antigas que tem um padrão menos óbvio?

Para ver mais: https://pt.stackoverflow.com/a/32665/101.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

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.

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.

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 é.

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).