Os 9 padrões de codificação C# que desenvolvedores precisam começar a usar
Os 9 padrões de codificação C# desenvolvedores precisam começar
C# é sobre objetos, classes e métodos de classe. O tempo de execução lida com o gerenciamento de memória para que você não precise. Seu código C# é compilado em um idioma intermediário e é executado na plataforma .NET. É uma linguagem construída em torno da produtividade; portanto, o compilador faz muitas otimizações para que você possa escrever código limpo e legível.
Existem alguns padrões gerais que os escritores C# fluentes seguem. Então, se você é um desenvolvedor que está vindo para C# de outra linguagem de programação, você vai querer saber essas coisas também! Este post é uma introdução aos padrões mais importantes e coloca você no curso para outros recursos que podem ajudar a construir sua proeza C#.
1. Casing
Nomear é difícil. E como é difícil, não queremos confundir o problema com a invólucro misturado. Cada língua tem seus próprios padrões de invólucro. Para aumentar a confusão, muitas organizações, ou mesmo equipes, têm seus próprios padrões. Quando não há um padrão no lugar, você pode até ver uma cornucópia de cada convenção de nomeação em apenas uma página de código? Com certeza eu tenho!
Existem três cápsulas geralmente aceitas pelos padrões C#:
- PascalCase: Isto é para nomes de classe, nomes de arquivos, nomes de namespace, nomes de métodos ALL e nomes de membros públicos.
- camelCase: Este é usado para nomes de membros que não são acessíveis publicamente.
- UPPER_CASE: Você também pode pensar nisso como uma caixa de cobra superior. Isto é usado apenas para constantes.
Existem algumas exceções que existem no mundo, e por boas razões.
Nomes como “Pascal_snake_case” ou “snake_case” às vezes são usados em testes de unidade. Um nome de método descritivo como Should_return_2_when_adding_1_and_1 é muito mais fácil de ler. Essa é a razão para a invólucro de cobra em testes unitários.
Os manipuladores de eventos (um tipo de método) geralmente incluem um sublinhado para separar o alvo da ação. Um exemplo clássico é Page_Load em ASP.NET. Mas isso não é Pascal_snake_case. Por exemplo, em InputControl_Init, o InputControl é o alvo e Init é o evento.
Seu código, no seu melhor.
Seja o melhor desenvolvedor da equipe.
Uma convenção muito debatida é a variável de membros privados. Uma vez que isso sempre se refere ao escopo de classe, é bom usar camelCase para variáveis membros. Quando você faz isso, você realmente deve usar **este.
public class Person
{
private string firstName;
public void SayHello()
{
Console.WriteLine($"Hello, {this.firstName}!");
}
}
Neste exemplo, a classe Pessoa tem uma variável de membro privado firstName, que só é acessível de dentro desta classe. O método SayHello está disponível para qualquer consumidor desta classe. Ele acessa a primeira variável Do Nome?através disso?que se refere à instância atual de Pessoa.
Outra abordagem comum é preparar o nome do membro com um sublinhado. Aqui está o mesmo exemplo usando essa convenção:
public class Person
{
private string _firstName;
public void SayHello(string firstName = null)
{
Console.WriteLine($"Hello, {firstName ?? _firstName}!");
}
}
Usar o sublinhado nos permite omitir isso quando usamos a variável. No exemplo, o parâmetro do método tem o mesmo nome base de um membro de classe. Portanto, se usarmos sublinhado em todas as variáveis membros, podemos evitar acidentalmente tomar a variável errada.
Nota aos leitores: ?? é um operador de coalizão nulo?um bom atalho, que significa “se nulo, então”. Além disso, usei interpolação de cordas neste exemplo, já que é melhor ler do que a corda antiga. Método de formato.
Pecados DeSarmes Cardeais de C
As seguintes convenções de invólucros de outras línguas vão aterrissar você no inferno C# …
Notação Húngara
Presendo um identificador de tipo para o nome é um não- não!
Notação húngara convida dois problemas em C#. Por um tempo, o nome é enganoso quando o tipo muda. Outro problema é a legibilidade. C# frequentemente usa tipos e interfaces personalizadas. Nomes como iDictNames e mpLateFeeMessageProcessor jogam lixo no código com desinteligibilidade extra (o que é um “mp” de qualquer maneira?).
Novos desenvolvedores terão que aprender as convenções internas de nomeação, o que retarda o desenvolvimento e introduz riscos operacionais. O IDE lhe dá muitas informações sobre o tipo se e quando você precisar.
Convenções Mistas
Convenções mistas de nomeação tornam o programa menos legível. Seja consistente e preste atenção à legibilidade. Claro, estamos programando um computador, mas o código é realmente para humanos. Computadores ficariam perfeitamente bem com um programa inteiro de 0s e 1s.
Tenha em mente ao seu leitor ao escrever software e use as mesmas regras de invólucro por toda parte!
Para ilustrar mais, aqui está um pequeno programa que mistura muitas convenções:
class aPOORRLY_written-CLASS {
public static int METHOD_FindHello_Get()
{
String LINE = null;
for(iCURRENT_ITERATION =0; iCURRENT_ITERATION < _nMaxIterationCount; iCURRENT_ITERATION++)
{
if(c_MyReadingSomething_CLASS.READALINE(out LINE)){
if(LINE.Contains("Hello")){
response = 1;
}
return response;
}
}
}
private const long _nMaxIterationCount = 100;
public static int iCURRENT_ITERATION = 0;
public static int response;
}
Desculpe, isso foi provavelmente bastante doloroso mesmo para um programa tão pequeno. Aqui está uma versão limpa:
internal class Hello
{
public static bool ContainsHello()
{
for(var i = 0; i < 100; i++)
{
if(LineReader.ReadLine(out string currentLine)
&& currentLine.Contains("Hello"))
{
return true;
}
}
return false;
}
}
Embora este código não seja tão grande, é muito mais limpo do que o exemplo anterior com invólucro misto e muitas outras inconsistências. Esta próxima seção irá ajudá-lo a entender algumas das outras questões.
2. Formatação
Temos convenções de formatação para C#, assim como fazemos em qualquer linguagem de programação. A formatação tem a ver com quebras de linha, recuo e espaçamento. É verdade que o IDE muitas vezes ajudará na formatação, mas não faz tudo por você.
Indentação
O recuo é uma questão muito contestada em muitas línguas. Você deve usar guias ou espaços? Este post não resolverá o argumento. Mas estabelecerá que quatro é o número adequado de espaços. Além disso, se você estiver usando guias, a guia deve ser igual a quatro espaços. Estes são padrões no Visual Studio, e a maioria dos IDEs tem essa predefinição para C#.
Suportes
Em C#, os suportes contêm o escopo de um namespace, classe, interface, método e afins. Os suportes são grandes construções estruturais e devem sempre seguir sua própria linha. Este post so tenta racionalizá-lo, mas honestamente, é apenas a convenção comum.
Terminador
Um ponto e vírgula termina uma declaração. Ele vai na mesma linha que o final da declaração, assim como um período faria. Não use ponto e vírgula extra?
Linhas Extras
Uma linha extra é suficiente para separar métodos ou diferentes seções de uma classe, como a lista de variáveis de membros, construtores e métodos.
3. “var” é seu amigo
Usando? var é realmente uma boa ideia para todas essas variáveis de curta duração. Ele não só economiza muita redundância, mas permite mais flexibilidade no código. Basicamente, se você já pode ver o tipo com base no nome da variável, você está pronto para ir com o VAR! Aqui estão alguns exemplos de var na prática:
var person = new Person(id);
var result = await _someApiClient.GetAsync(id, cancellationToken);
for(var i = 0; i < max; i++)
{
// i is implicitly typed
}
var person = this.personFactory.GetOrCreate(id);
this.someDependency.SubmitPerson(person);
4. Use sempre modificadores de acesso
Use sempre modificadores de acesso! Eu sei, eu sei… o padrão às vezes é o que você quer: “privado” para membros, “interno” para as aulas. Mas realmente ajuda ser explícito sobre isso. Isso mostra que você foi proposital em sua intenção.
E enquanto estiver nisso, use o modificador mais baixo necessário. Isso equivale ao princípio do menor privilégio. Por exemplo, não use protegido quando o privado fará. Use interno protegido para dar acesso apenas a subclasses no conjunto. Se sua classe for pública e você quiser compartilhar um membro com uma subclasse fora da assembleia, faça o membro protegido. Aqui está um exemplo para esclarecer.
Na minha montagem, eu faço uma aula para ler um certo tipo de arquivo.
public FileReader
{
protected virtual string Read(string location)
{
// read file and return result
}
}
Você faz referência à minha montagem ou usa o NuGet para adicioná-lo ao seu projeto. Uma vez que o método Read é protegido e virtual, você pode não só acessá-lo a partir de sua própria subclasse, mas você pode substituí-lo.
5. Use propriedades automáticas
Uma propriedade de automóveis cria um campo de apoio para você; você simplesmente não pode vê-lo ou acessá-lo. Se você não precisa de controle sobre o campo de apoio, não crie um. Em vez disso, basta usar a propriedade automática (o atalho é “prop”). Vai economizar um monte de código extra!
public int Count { get; set; }
Este é um exemplo de uma propriedade automobilística. Torna seu código muito mais limpo.
6. Onde declarar variáveis
Declare variáveis o mais próximo possível de seu uso. Algumas línguas funcionam melhor quando você declara todas as suas variáveis no início da função, mas o compilador C# não se importa. Vai fazer a coisa ideal, não importa onde você coloque a variável. Coloque a variável perto do seu uso para que você tenha mais facilidade para refatorar seu código. Na verdade, seu IDE permite que você destaque a seção e o clique com o botão direito do mouse (ou use Ctrl+.) para fazer algum refatoração útil. Se sua variável for declarada lá em cima, o refator será excessivamente complexo ou até mesmo totalmente impossível.
7. Organização de arquivos de código
Você só deve colocar uma classe, interface, estrutura ou enum em um único arquivo. Isso torna a base de código mais fácil de navegar. Por essa mesma razão, você deve manter seu código organizado em pastas dentro dos projetos.
Um projeto é uma coleção de arquivos que estão relacionados. O namespace deve corresponder ao nome do projeto e ao caminho do diretório em que está localizado. Por exemplo, digamos que você tem um projeto chamado Peoples and a Utilities diretório (para, você sabe, utilitários). Uma classe de utilidade para formatar nomes seria assim:
namespace Peoples.Utilities
{
public class NameFormatter
{
public static string FormatName(Person person)
{
return $"{person.FamilyName}, {person.GivenName}";
}
}
}
Esta classe de utilidades viveria dentro da pasta Utilitários do projeto Peoples. Observe o uso da interpolação de sequência de cordas em vez de string. Formato.
8. Use os codinomes, Jack!
Todos os tipos primitivos têm pseudônimos. String tem corda. Int32 tem int. Int64 tem? longo. Há muito mais de onde esses vieram, e é a maneira preferida de se referir a esses tipos. Use-os mesmo que você esteja chamando um método no tipo como int. O Parse.
9. “usar” é seu amigo!
Quando você tem um tipo descartável, há uma grande construção embutida na linguagem: usando. Ele chama De descarte quando o fluxo do programa deixa o escopo. Aqui está um exemplo:
using(var connection = _connectionFactory.Get())
using(var stream = connection.OpenStream())
{
// use the connection and the stream
}
Este exemplo requer uma pequena explicação. Para começar, a maioria das pessoas não sabe que você pode empilhar as declarações de uso como esta. Outra coisa é quando o fluxo do programa sai dos suportes por qualquer razão, tanto a conexão quanto o fluxo serão eliminados.
Espero que, se você tiver uma classe de conexão bem projetada, a conexão será fechada antes de ser descartada. Neste caso, não há necessidade de fazer mais nada. É assim que C# deve ser!
Quer saber se você está acertando quando aprende C#?
Obtenha uma revisão de código instantânea e automatizada com CodeIt.Right.
Continue a Jornada
Claramente, cobrimos muito até agora, mas isso é só o começo. Há tantos padrões em C# que não podemos cobri-los todos em apenas um post. Felizmente, temos ferramentas como o Visual Studio para nos ajudar enquanto estamos codificando.
Mas há uma maneira ainda mais poderosa de verificar seu trabalho antes que ele saia para a natureza. Ferramentas como CodeIt.Right oferecem muito mais e estão continuamente no topo dos padrões e convenções mais recentes. Confira algumas das regras explicadas para ver o porquê.
Sobre o autor
Phil Vuollet
Autor Contribuinte
Phil Vuollet usa software para automatizar processos para melhorar a eficiência e a repetibilidade. Ele escreve sobre temas relevantes para a tecnologia e negócios, ocasionalmente dá palestras sobre os mesmos temas, e é um homem de família que gosta de jogar futebol e jogos de tabuleiro com seus filhos.
Relacionado
Notação húngara Pós-morte: O que deu errado?
Is Hungarian notation really adjDead? Suggesting a postmortem might be a bit premature, but it could be fun to take a quick dive into what we?ve learned from a really smart Hungarian named Charles Simonyi who tried to find a better way. Anyone who tries to bring some clarity to…
12 de dezembro de 2017
Em “Artigos”
StyleCop: Um guia detalhado para iniciar e usá-lo
Content updated: 4/23/2019. Put two developers together and they’re bound to have a discussion about coding style. No two developers write code in the exact same way. More often than not, one isn’t better than the other and it’s just a matter of taste. In a team or in a…
10 de abril de 2018
Em “Artigos”
A morte de WinForms foi muito exagerada
Depending on your age and experience as a .NET developer, you might or might not be familiar with the technology known as Windows Forms. Windows Forms, or WinForms, was introduced together with .NET 1.0 in 2002. It was the first desktop UI technology for .NET. We’re now 16 (!) years…
28 de agosto de 2018
Em “Artigos”