Hoje aprender uma linguagem de programação não é uma tarefa tão complicada e em pouco tempo podemos desenvolver, por exemplo, um pequeno sistema de automação comercial sem muito conhecimento ou técnicas de programação. Porém isso pode se tornar uma aventura arriscada. Imagine que um dia outro desenvolvedor vá dar manutenção no seu sistema. Se gastaria muito tempo só para entender a lógica e formatação do seu código, uma vez que você não seguiu nenhum padrão ou boas práticas de programação. Fazer um programa funcionar pode não ser tão difícil, mas escrevê-lo de forma correta pode exigir um pouco mais de tempo. Esse artigo vai mostrar que é possível escrever códigos de qualidade seguindo algumas dicas.
Por que usar padrões e boas práticas
Para escrever um código confiável e de fácil manutenção devemos seguir alguns padrões e boas práticas de programação. Várias convenções de nomes e padrões nesse artigo foram extraídas do próprio guia da Microsoft. É claro que com o decorrer do tempo, adquirimos mais experiência, tornando o uso delas algo automático. Existem vários exemplos na própria Internet que nos ajudam a escrever bons códigos, cabendo a você desenvolvedor filtrar o que há de melhor e tentar segui-los.
Seguindo padrões na equipe
É muito comum numa grande equipe de desenvolvimento encontrar profissionais com os mesmos conhecimentos técnicos, como uma linguagem de programação, e cada um deles ter uma diferente forma de escrever códigos. Nesse caso é necessário convencer todos os integrantes da importância de se usar padrões para que a manutenção e o entendimento sejam realizados por qualquer integrante da equipe. Esse artigo pode ajudar a você criar seu próprio template para que o mesmo seja apresentado e discutido por todos. Cada um pode ter uma opinião diferente sobre cada tópico, mas no final todos devem chegar a um acordo onde TODOS seguirão exatamente os mesmos padrões.
Depois de iniciar o desenvolvimento do seu template, é ideal que sejam agendadas reuniões para revisão de código. Três tipos de revisão de código são recomendadas:
- Revisão de membro: outro membro da equipe revisa o código para assegurar que o mesmo está seguindo os padrões definidos. Esse nível de revisão pode incluir algum teste unitário. Todos os arquivos do projeto devem ser incluídos nessa revisão;
- Revisão de arquiteto: arquiteto da equipe deve rever os módulos do projeto para assegurar que eles aderiram ao design e nenhum grande erro tenha sido cometido ao ponto de comprometer o restante do projeto;
- Revisão de grupo: aleatoriamente escolher um ou mais arquivos para conduzir uma revisão de grupo uma vez na semana. Distribua uma cópia impressa dos códigos para todos os integrantes trinta minutos antes da reunião. Faça com que todos leiam e marquem pontos importantes a serem discutidos. Percorra todas as linhas de código e deixe que cada integrante dê sua opinião do que poderia ser melhorado ou escrito de uma forma melhor forma.
Convenção de Nomes e Padrões
Os termos Pascal Casing e Camel Casing serão usados no decorrer desse artigo.
- Pascal Casing: O primeiro caractere de todas as palavras é maiúsculo e o restante minúsculo. Exemplo: CorDoCarro.
- Camel Casing: O primeiro caractere de todas as palavras, exceto da PRIMEIRA palavra são maiúsculos e o restante minúsculos. Exemplo: corDoCarro.
1. Use Pascal Case para nome de classes
public class HelloWorld
{
}
2. Use Pascal Case para nome de métodos
void DizerPalavra(string palavra)
{
}
3. Use Camel Case para variáveis e parâmetros dos métodos
int contagemTotal = 0;
void DizerPalavra(string palavra)
{
string palavraCompleta = “Você disse “ + palavra;
}
4. Use o prefixo I com Camel Casing para interfaces. Por exemplo: IEntidade;
5. Não use notação húngara para nomear member variables, ou variáveis privadas. Ultimamente muitos programadores têm usado o prefixo m_ para representar variáveis. Por exemplo:
string m_sNome;
int nIdade;
No entanto nos padrões .Net isso não é recomendado. Na verdade o uso desse prefixo não deveria ser usado. Ao invés disso, todas as variáveis devem usar Camel Casing.
6. Dê um nome significativo para suas variáveis e evite abreviações
Bom
string nomeCompleto;
DateTime dataDeNascimento;
Ruim
string nomComp;
DateTime datNasc;
7. Não use caracteres simples para nomear suas variáveis. Exemplo: i, n, s. Use nomes do tipo index, temp.
Uma exceção, porém seria no uso de loops:
for (i==0 ; i < 10 ; i++)
{
}
Se a variável é usada somente para essa iteração, muitos desenvolvedores preferem usar um caractere simples ao invés de dar um nome significativo.
8. Não use underline ou underscore (_) para variáveis locais
9. Todas as member variables (variáveis privadas) devem usar o prefixo _ a fim de ser identificada entre outras variáveis
10. Não use variáveis que podem ser palavras reservadas. Exemplo where, string.
11. Use a palavra é ou is em variáveis do tipo bool. Exemplo:
private bool _isFinished;
private bool _ehHibrido;
12. Para nomear Namespaces, devemos seguir o seguinte padrão:
Nome da empresa.Nome do produto.modulo superior.modulo inferior
13. Use o prefixo apropriado para elementos UI, o que é conhecido por notação húngara. Na Tabela 1 há uma sugestão para nomear corretamente seus componentes visuais.
| Controle | Prefixo |
|---|---|
| Label | lbl |
| TextBox | txt |
| DataGrid | dtg |
| Button | btn |
| ImageButton | imb |
| HyperLink | hlk |
| DropDownList | ddl |
| ListBox | lst |
| DataList | dtl |
| CheckBox | chk |
| CheckBoxList | cbl |
| RadioButton | rdo |
| Image | img |
| Table | tbl |
| Validators | val |
14. Nome do arquivo deve ser o mesmo nome da classe. Por exemplo, para a classe HelloWorld o arquivo deve ser nomeado como HelloWorld.cs
15. Use Pascal Case para nomear seus arquivos.
Endentação e espaçamento
1. Use TAB para endentação ao invés de espaços. Defina o tamanho do TAB para quatro espaços.
2. Os comentários devem ser no mesmo nível do código. Use o mesmo nível da endentação. Exemplo:
Bom
//Atribui à variável o valor da data atual.
DateTime dataAtual = DateTime.Now;
Ruim
//Atribui à variável o valor da data atual.
DateTime dataAtual = DateTime.Now;
3. Use uma linha em branco para separar grupos lógicos de código. Exemplo:
Bom
bool DigaOla ( string nome )
{
string mensagemCompleta = "Olá " + name;
DateTime horaAtual = DateTime.Now;
string mensage = mensagemCompleta + ", a hora é : " + horaAtual.ToShortTimeString();
MessageBox.Show ( mensagem );
if ( ... )
{
// Algo
// ...
return false;
}
return true;
}
Ruim
bool DigaOla ( string nome )
{
string mensagemCompleta = "Olá " + name;
DateTime horaAtual = DateTime.Now;
string mensage = mensagemCompleta + ", a hora é : " + horaAtual.ToShortTimeString();
MessageBox.Show ( mensagem );
if ( ... )
{
// Algo
// ...
return false;
}
return true;
}
4. Use #region para agrupar métodos ou declarações relacionados. Assim seu código ficará mais organizado
5. Mantenha variáveis, métodos e propriedades privadas na parte superior do arquivo e as públicas na parte inferior.
Boas práticas de programação
1. Evite escrever métodos longos. Normalmente temos entre uma e vinte e cinco linhas de código. Se tivermos mais do que isso, pense em rever seu código para separá-lo em mais métodos;
2. O nome do método deve nos dizer o que ele faz. Se o nome for óbvio, pode não ser necessário documentar, explicando o que o mesmo deveria fazer;
3. Um método deve executar apenas um trabalho. Evite combinar diversas tarefas em um mesmo método, por mais simples que ele pareça;
4. Evite usar números “mágicos”. Procure sempre declarar esse tipo de número como constantes, e tenha certeza que essas constantes jamais irão mudar. Exemplo:
Bom
const int mesesAno = 12;
.
.
.
public void AlgumMetodo()
{
int mesAtual = 1;
for (mesAtual < mesesAno < mesAtual++)
{
…
}
}
Ruim
public void AlgumMetodo()
{
for (i = 1 < 12 < i++)
{
5. Use String.Empty ao invés de “”. Exemplo:
if ( nome = String.Empty )
{
. . .
}
6. Não chame programaticamente o clique de um botão para executar a mesma ação de seu event handler. Separe o código do event handler e chame-o.
7. Se algum arquivo de configuração utilizado pela sua aplicação não for encontrado, faça com que seu programa crie automaticamente um com valores default
8. Evite escrever mais de uma classe em um mesmo arquivo
9. Evite ter arquivos muito grandes. Se um único arquivo tiver mais de mil linhas de código, ele é um forte candidato à revisão. Separe-o logicamente em duas ou mais classes
10. Se estiver abrindo conexões com banco de dados, sockets, arquivos, enfim, qualquer objeto não gerenciado ou que precise ser finalizado, não se esqueça de fechá-los bloco finally.
GhostDoc
É muito importante que nossas classes, métodos, variáveis estejam bem documentadas para que outros desenvolvedores possam entender qual era a finalidade de cada um deles. Assim, fica bem mais fácil dar uma manutenção decente em pouco tempo. GhostDoc é um software gratuito que ajuda o desenvolvedor nessa tarefa.
Após instalar a ferramenta, abra o Visual Studio. O programa irá lhe pedir para mapear um hotkey, que fará automaticamente a criação de um comentário para documentação XML, conforme Figura 1. Podemos usar a combinação default, que é CTRL + SHIFT + D. O próximo passo é a configuração de regras (Figura 2). Supondo que essa seja sua primeira vez que tem contato com a ferramenta, não é preciso se preocupar. Apenas clique em Create. A Figura 3 mostra que você concluiu a instalação do produto. Clique em Finish e mãos à obra! Para demonstrar o produto funcionando, vamos criar uma classe bem simples chamada Carro, conforme Listagem 1.
Para que o GhostDoc crie sua documentação, você tem três possibilidades para posicionar o cursor do mouse: no lado direito do método, no lado esquerdo do método ou em qualquer parte dentro do método. Após posicionar o mouse, pressione a tecla de atalho que foi criada ao instalarmos o GhostDoc: CTRL + ALT + D. Note que foi criada bem em cima do método as tags XML summary e param, conforme Figura 4. Note também que o GhostDoc tenta descrever a funcionalidade do método. No caso o método se chama StartEngine. O GhostDoc descreveu o método como Starts the engine, além de descrever o parâmetro como The code, uma vez que o nome do parâmetro é code. Uma pequena desvantagem para nós brasileiros, é que a ferramenta tenta “adivinhar” a descrição baseado na gramática da língua inglesa. Então se o nome do método se chamasse DarPartida, o GhostDoc descreveria esse método como Dars the Partida. Mas podemos criar nossas próprias regras para que o GhostDoc seja também uma ferramenta bem útil e fácil de usar.
Após concluir um projeto utilizando a ferramenta, experimente usar um documentador de código como o nDoc. Você verá que podemos ter bons documentos baseados em nossos próprios códigos!
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace GhostDocExample
{
public class Carro
{
public void StartEngine(int code)
{
//...foo
}
}
}
Conclusão
A maior dificuldade atualmente é seguir um padrão de desenvolvimento comum a todos de uma equipe. Porém todo esforço é recompensado quando deixamos de gastar horas tentando imaginar o que um desenvolvedor quis dizer com certo método ou propriedade, muitas vezes com nomes sem sentido ou chamadas duplicadas. Além de seguir padrões e boas práticas de programação, uma boa documentação é outro excelente passo para uma boa compreensão dos códigos. Espero que esse artigo tenha ajudado, ou que pelo menos tenha feito com que nós desenvolvedores pensássemos não só nas técnicas de programação ou recursos que o framework nos oferece, mas também na qualidade e padronização de desenvolvimento de uma equipe.
