C# Padres de codificao e boas prticas de

programao
Preparado por: Gabriel Gomes


Data de Criao: 29/08/2010
Itima AtuaIizao: 15/05/2011
Verso: 01



Padres de codificao e boas prticas de programao

ControIe do Documento
Registro de AIteraes

Data Autor: Descrio da Mudana:
29/08/2010 Gabriel Gomes Criao do Documento
15/05/2011 Gabriel Gomes Adio de regras para Sistema de controle de verso (Version control system)





Sumrio
1. Autor 3
2. Introduo 3
3. Proposito dos padres de codificao e boas prticas 3
4. Convenes de nomencIatura e Padres 4
5. Indentao e espaos 7
6. Boas Prticas 9
7. Arquitetura 16
8. ASP.NET 16
9. Comentrios 16
10. ManipuIando Excees 17
11. Sistema de controIe de verso (Version controI system) 20




Padres de codificao e boas prticas de programao

1. Autor

Muitas das informaes deste documento so compiladas de padres de codificao e boas praticas de programao
publicados em vrios artigos na internet e livros de programao. Tambem foi usado como referencia C# Coding Conventions
(C# Programming Guide) e varias outras fontes.

2. Introduo
Qualquer um pode escrever cdigo. Com poucos meses de experincia em programao voc pode escrever
"programas, mas escrever software pelo caminho certo requer mais trabalho que apenas faze-lo funcionar, afinal at um
cdigo ruim funciona.
Acredite, a maioria dos programadores escrevem "programas, mas no escrevem um "bom cdigo, escrever um
bom cdigo uma arte e voc deve aprender e praticar.
Todos podem ter uma definio para "bom cdigo, mas acredito que um bom cdigo possui as seguintes
caractersticas:
Confivel
Manutenvel
Eficiente
As maiorias dos desenvolvedores esto focados em escrever cdigo para obter maior desempenho, comprometendo a
confiabilidade e durabilidade. Mas considerando o RO (Return On nvestiment), a eficincia e o desempenho destroem com
a confiabilidade e a facilidade de manuteno, voc (e sua empresa) vo gastar muito mais tempo ao longo da vida da sua
aplicao para identificar os problemas, entender o cdigo e etc.
Quando um projeto tenta aderir a normas comuns algumas coisas boas acontecem:
Programadores podem entrar em qualquer cdigo e descobrir o que esta acontecendo
Novas pessoas podem obter velocidade rapidamente
Novas pessoas so poupadas de desenvolver um estilo pessoal e defende-lo at a morte
Novas pessoas so poupadas de cometer os mesmos erros outra vez
As pessoas fazem menos erros em um ambiente consistente
Programadores tm um "inimigo em comum
3. Proposito dos padres de codificao e boas prticas
Para escrever aplicao confiveis e de fcil manuteno, voc deve seguir padres de codificao e boas
prticas.
As convenes de nomenclatura, padres de codificao e boas praticas so compiladas a partir de referencias
de diversas documentaes tanto Microsoft e orientaes no Microsoft e tambm com a experincia da comunidade que
contribui em fruns e blogs.
Existem diversos padres no setor de programao. Nenhum deles este errado ou ruim e voc pode seguir
qualquer um deles. O que mais importante a seleo de uma abordagem padro e garantir que todo mundo esta
seguindo.



Padres de codificao e boas prticas de programao

4. Convenes de nomencIatura e Padres
Nota :
Os termos Pascal Casing e Camel Casing so usados ao longo deste documento.
PascaI Casing O primeiro caractere de todas as palavras maisculo e os demais caracteres so
minsculos.
Exemplo: BackColor
CameI Casing - O primeiro caractere de todas as palavras, exceto a primeira palavra maisculo e os
outros caracteres so minsculos.
Exemplo: backColor


1. Use Pascal Casing para nomes de Classes

public class HelloWorld
{
...
}

Classes e objetos devem ter nomes com Substantivos(s), como Cliente, PaginaWiki, Conta e
AnaliseEndereco. Evite palavras como Gerente, Dados ou Info no nome de uma classe que tambm no
pode ser um verbo.
No adicione prefixo no nome de uma classe (como a letra C ou cls).
nterfaces que devem comear com a letra so exceo a esta regra.

2. Use Pascal Casing para nome de Mtodos

public void SayHello(string name)
{
...
}

Os nomes de mtodos devem ter verbos, como PostarPagamento,ExlcuirPagina ou Salvar. Devem-se
nomear mtodos de acesso, alterao e autenticao segundo seus valores.

3. Use Camel Casing para variveis e parmetros de mtodos

int totalCount = 0;
public void SayHello(string name)
{
string fullMessage = "Hello " + name;
...
}

4. Use o prefixo " com Camel Casing para interfaces ( Example: IEntity )

5. No use notao Hngara para nomes de variveis



Padres de codificao e boas prticas de programao

Antigamente a maioria dos programadores gostava Tendo o tipo de dados como prefixo para o nome da varivel e usando
m_ para variveis membros. Por exemplo:

string m_sName;
int nAge;

No entanto, nos padres de codificao .NET, isto no recomendado. O uso do m_ para representar variveis membro no
deve ser usado. Todas as variveis membro devem usar camel casing.


6. Use palavras descritivas para nomear as variveis, no use abreviaes, prefervel uma varivel com um nome longo
e descritivo do que uma varivel com nome pequeno de significado oculto.

Bom:
string address;
int salary;

Ruim:
string nam;
string addr;
int sal;

7. No use um nico caractere como nome varivel como i, n, s etc. Use nomes como index, temp
Uma exceo nesse caso para variveis que sero usados em laos de iterao:
for ( int i = 0; i < count; i++ )
{
...
}

Se a varivel utilizada apenas como um contador de iterao e no usado em qualquer outro lugar do loop, muitas
pessoas ainda gostam de usar um nico caracter (i) para a varivel em vez de inventar um nome diferente adequado.

8. No use underscore (_) para variaveis locais.

9. Todas as variveis membro devem ser prefixadas com underscore (_) para que elas possam ser identificadas a partir de
outras variveis locais.
Ex: private string _name;

10. No use nomes de variveis que se assemelham a palavras-chave.

12. Nomes de namespace deve seguir o modelo padro
Ex: <Compahia>.(<Produto|Tecnologia>)[<Feature>].[<Subnamespace>]
Microsift.WindowsMobile.Directx

13. Utilizar o prefixo apropriado para os elementos da interface do usurio para que voc possa identific-los do resto das
variveis.
Use o prefixo apropriado para cada um dos elementos da U (User nterface). Uma breve lista dada abaixo. O .NET
tem criado constantemente novos controles e muitos deles voc tera que deifnir seus prefixos padro para cada um deles
(incluindo controles de terceiros que voc esta usando.)


Padres de codificao e boas prticas de programao


ControI Prefix
Label lbl
TextBox txt
DataGrid dtg
Button btn
mageButton imb
Hyperlink hlk
DropDownList ddl
ListBox lst
DataList dtl
Repeater rep
Checkbox chk
CheckBoxList cbl
RadioButton rdo
RadioButtonList rbl
mage img
Panel pnl
PlaceHolder phd
Table tbl
Validators val

14. Nome do arquivo deve corresponder com o nome de classe.


Padres de codificao e boas prticas de programao

Por exemplo, para a classe HelloWord, o nome do arquivo deve ser HelloWord.cs (ou, HelloWord.vb)

15. Use Pascal Case para o nome de arquivos.


16. Para constantes todos os caracteres devem estar em maisculo e deve ser utilizado underscore como separador (_).
Ex: const decimal HOURS_WORKED_PER_WEEK = 8.5M ;
5. Indentao e espaos
1. Use TAB para indentao. No use ESPAOS. Defina o Tab size para 4.

2. Os comentrios devem estar no mesmo nvel que o cdigo (use o mesmo nvel de recuo).

Bom:
// Format a message and display
string fullMessage = "Hello " + name;
DateTime currentTime = DateTime.Now;
string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString();
MessageBox.Show ( message );

Ruim:

// Format a message and display
string fullMessage = "Hello " + name;
DateTime currentTime = DateTime.Now;
string message = fullMessage + ", the time is : " +
currentTime.ToShortTimeString();
MessageBox.Show ( message );

3. Chaves ( { } ) devem estar no mesmo nvel que o cdigo fora das chaves.

4. Use uma linha em branco para separar grupos lgicos de cdigo.
Bom:
bool SayHello ( string name )
{
string fullMessage = "Hello " + name;
DateTime currentTime = DateTime.Now;

string message = fullMessage + ", the time is : " +
currentTime.ToShortTimeString();

MessageBox.Show ( message );

if ( ... )
{
// Do something
// ...


Padres de codificao e boas prticas de programao


return false;
}

return true;
}


Ruim:
bool SayHello (string name)
{
string fullMessage = "Hello " + name;
DateTime currentTime = DateTime.Now;
string message = fullMessage + ", the time is : " +
currentTime.ToShortTimeString();
MessageBox.Show ( message );
if ( ... )
{
// Do something
// ...
return false;
}
return true;
}

5. Deve haver uma e apenas uma nica linha em branco entre cada mtodo dentro da classe.

6. As chaves devem ser em uma linha separada e no na mesma linha, em if, for etc.
Bom:
if ( ... )
{
// Faz alguma coisa
}

Ruim:
if ( ... ){
// Faz alguma coisa
}

7. Use um nico espao antes e depois de cada operador e colchetes.
Bom:
if ( showResult == true )
{
for ( int i = 0; i < 10; i++ )
{
//
}
}
Ruim:
if(showResult==true)
{
for(int i=0;i<10;i++)
{
//
}
}



Padres de codificao e boas prticas de programao

8. Mantenha variveis membro privadas, propriedades e mtodos no topo do arquivo e membros pblicos abaixo.



9. Configurando Visual Studio 2008/2010 para manter endentao e espaos automaticamente
Abra o Visual Studio -> Tool -> Options -> Text Editor -> C# -> Formatting

Neste local possvel configurar o Visual Studio para manter a formatao de indentao e espaamento definidos no
documento de padres automaticamente.

6. Boas Prticas
1. Evite escrever mtodos muito longos, um mtodo deve ter entre 1 25 linhas de cdigo. Se um mtodo tem mais de 25
linhas de cdigo voc deve considerar a refatorao desse mtodo em mtodos separados.

2. O nome do mtodo deve dizer o que ele faz. No use nomes ocultos que s voc entende. Se o nome do mtodo
obvio no h necessidade de documentao explicando o que ele faz.

Bom:
public void SavePhoneNumber ( string phoneNumber )
{
// Salva o nmero do telefone
}

Ruim:
// Esse mtodo salva o nmero do telefone
void SaveDetails ( string phoneNumber )


Padres de codificao e boas prticas de programao

{
// Salva o nmero do telefone.
}
3. Um mtodo deve fazer apenas "uma tarefa ". No deve existir mais de um emprego em um nico mtodo, mesmo que
esses empregos sejam muito pequenos SRP Single Responsability Principle.




Bom:


SaveAddress ( address );


SendEmail ( address, email );


public void SaveAddress ( string address )
{
// Salva o endereo.
// ...
}

public void SendEmail ( string address, string email )
{
// Envia um e-mail para o supervisor notificando a atualizao do endereo.
// ...
}

Ruim:

// Salva o endereo e envia um e-mail para o supervisor notificando a
// atualizao do endereo.
SaveAddress ( address, email );

void SaveAddress ( string address, string email )
{
// Trabalho 1.
// Salva o endereo.
// ...

// Trabalho 2.
// Envia um e-mail para o supervisor notificando a atualizao do endereo.
// ...
}


4. Use tipos especficos do C # ou VB.NET (aliases), em vez dos tipos definidos no namespace System.

int age; (no Int16)
string name; (no String)
object contactInfo; (no Object)

5. Sempre preste ateno para valores inesperados. Por exemplo, se voc estiver usando um parametro com dois valores
possveis, nunca assuma que algum no est combinando esses valores, ento a nica possibilidade o outro valor.

Bom:
if ( memberType == eMemberTypes.Registered )
{
// Usurio registrado. faa alguma coisa.


Padres de codificao e boas prticas de programao

}
else if ( memberType == eMemberTypes.Guest )
{
// Usurio convidado. faa alguma coisa.
}
else
{
// Tipo de usurio no esperado. Lana uma exceo
throw new Exception (Un expected value + memberType.ToString() + '.)

// Se introduzirmos um tipo novo usurio no futuro, podemos facilmente.
// encontrar o problema aqui.
}

Ruim:
if ( memberType == eMemberTypes.Registered )
{
// Usurio registrado. faa alguma coisa.
}
else
{
// Usurio convidado . faa alguma coisa

// Se introduzir outro tipo de usurio no futuro, este cdigo vai falhar.
// e no sera notado
}

6. No use nmeros hardcoding. Use constantes em seu lugar. Declare constantes no inicio do arquivo e use em seu
cdigo.

No entanto, o uso contnuo de constantes tambm no recomendado. Voc deve usar as constantes no arquivo de
configurao ou banco de dados para que voc possa alter-los posteriormente. Declar-las como constantes somente
se voc estiver certo de que este valor nunca precisar ser alterado.

7. No use strings hardcoding. Use resource files.

8. Converta strings para minsculas ou maisculas antes de comparar. sso ira assegurar que a string ir corresponder,
mesmo que a string comparada tenha um case diferente.

if ( name.ToLower() == john )
{
//.
}

9. Use string.Empty ao invs de ".
Bom:
if ( name == String.Empty )
{
// faa algo
}

Ruim:
if ( name == )
{
// faa algo


Padres de codificao e boas prticas de programao

}

10. Evite o uso de variveis membros. Declare variveis locais sempre que necessrio e passe-as a outros mtodos ao
invs de compartilhar um varivel membro entre vrios mtodos. Se voc compartilhar uma varivel membro entre
diversos mtodos, ser difcil rastrear quando qual mtodo altera seu valor.

11. Use enum sempre que necessrio. No use nmeros ou strings para indicar valores discretos.

Bom:
enum MailType
{
Html,
PlainText,
Attachment
}

void SendMail (string message, MailType mailType)
{
switch ( mailType )
{
case MailType.Html:
// Faz alguma coisa
break;
case MailType.PlainText:
// Faz alguma coisa
break;
case MailType.Attachment:
// Faz alguma coisa
break;
default:
// Faz alguma coisa
break;
}
}


Ruim:
void SendMail (string message, string mailType)
{
switch ( mailType )
{
case "Html":
// Faz alguma coisa
break;
case "PlainText":
// Faz alguma coisa
break;
case "Attachment":
// Faz alguma coisa
break;
default:
// Faz alguma coisa
break;
}
}

12. No crie variveis membro como pblicas. Mantenha-as privadas e exponha propriedades pblicas/protegidas.


Padres de codificao e boas prticas de programao


13. O manipulador de eventos no deve conter o cdigo para executar a ao necessria. Ao invz, deve chamar outro
mtodo para executar a ao.

14. No clicar em um boto para executar a mesma ao que voc escreveu no evento clique de outro boto. Em vez
disso, chamar o mesmo mtodo que chamado pelo manipulador de eventos de clique de boto.

15. Nunca codificar um caminho ou nome da unidade no cdigo. Obter o caminho do aplicativo programaticamente e usar
caminho relativo.

16. Nunca assuma que seu cdigo ser executado a partir da unidade "C:". Voc nunca podera saber, alguns usurios
podem execut-lo da rede ou de um "Z".

17. No inicializar da aplicao, faa algum tipo de "auto check para garantir que todos os arquivos necessrios e
dependncias esto disponveis nos locais esperados. Verifique se h conexo com o banco na fase carregamento, se
necessrio. Exibir uma mensagem amigvel para o usurio em caso de problemas.

18. Se o arquivo de configurao necessrio no for encontrado, a aplicao deve ser capaz de criar um com valores
padro.

19. Se valores errados forem encontrados no arquivo de configurao do aplicativo, deve ser lanando um erro ou dar uma
mensagem e tambm deve ser informamado ao usurio quais so os valores corretos.

20. Mensagens de erro devem ajudar o usurio a resolver o problema. Nunca dar mensagens de erro como "Erro na
Aplicao", "No um erro", etc. Em vez disso, dar mensagens especficas, como "Falha ao atualizar banco de dados.
Verifique se o D de login e senha esto corretos..

21. Ao exibir mensagens de erro, alm de contar o que est errado, a mensagem tambm deve dizer o que o usurio deve
fazer para resolver o problema. Em vez de uma mensagem como "Falha ao atualizar banco de dados", elas devem
sugerir o que o usurio deve fazer: "Falha ao atualizar banco de dados Por favor, verifique se o D de login e senha
esto corretos.".

22. Mostrar uma mensagem de erro curta e amigvel para o usurio. Mas salvar o log de erro real com todas as
informaes possveis. sso vai ajudar muito a diagnosticar problemas.

23. No ter mais do que uma classe por arquivo.

24. Voc pode ter seus prprios modelos para cada um dos tipos de arquivo do Visual Studio. Voc pode incluir
nome da empresa, informaes de direitos reservados, etc. no arquivo. Voc pode visualizar ou editar
os modelos de arquivo do Visual Studio na pasta C:\Program Files\Microsoft Visual Studio
8\Common7\IDE\ItemTemplatesCache\CSharp\1033.( Esta pasta contem os modelos para C#, mas voc pode
facilmente encontrar as pastas correspondentes para qualquer outra linguagem).

25. Evite arquivos muito grandes, se um arquivo tem mais de 1000 linhas um forte candidato a ser refatorado. Divida-o
logicamente em duas ou mais classes.



Padres de codificao e boas prticas de programao

26. Evite mtodos e propriedades pblicas, a menos que eles realmente precisem ser acessados de fora da classe. Use
"internal" se eles so acessados somente dentro do mesmo assmbly.

27. Evite passar muitos parmetros para um mtodo. Se voc tiver mais de 4 parmetros (funces polades), ele um bom
candidato para definir uma classe ou estrutura.

28. Se voc tem um mtodo que retorna uma coleo, retorne uma coleo vazia ao invs de "null" se voc no tiver
dados para retornar. Por exemplo, se voc tem um mtodo retornando um ArrayList, sempre retorne um ArrayList
vlido. Se voc no tem itens para retornar, em seguida, retorne um ArrayList vlido com 0 itens. sto tornar mais
fcil para quem chama o metodo apenas verificar a "quantidade de itens" em vez de fazer uma verificao adicional
para "null".

29. Use o arquivo AssemblyInfo para preencher informaes como nmero de verso, descrio, nome da empresa,
aviso de direitos autorais, etc.

30. Organize logicamente todos os seus arquivos dentro de pastas adequadas. Use 2 hierarquias de nvel de pastas.
Voc pode ter at 10 pastas na pasta raiz e cada pasta pode ter at 5 subpastas. Se voc tiver muitas pastas que
no podem ser acomodados com a hierarquia de 2 nveis acima referido, voc pode precisar refatorar em vrios
assemblies.

31. Verifique se voc tem uma boa classe de log que pode ser configurada para registrar erros de advertncia, ou
rastreamento. Se voc configurar para registrar erros, s deve registrar erros. Mas se voc configurar para log de
rastreamento, ela deve registrar todos os (erros, avisos e rastreamento). Sua classe de log deve ser escrita de forma
a que no futuro voc possa mud-la facilmente para o Log de eventos do Windows, SQL Server, ou E-mail para o
administrador ou a um arquivo, etc. sem qualquer alterao em qualquer outra parte da aplicao. Use a classe de log
extensivamente em todo o cdigo para registrar erros de advertncia, isso o ajudara a identificar possiveis problemas.

Abaixo alguns frameworks de log para .NET:
NLOG: http://nlog-project.org/
LOG4NET: http://logging.apache.org/log4net/
DOTNETLOG: http://www.theobjectguy.com/dotnetlog

32. Se voc est abrindo conexes de banco de dados, sockets file stream, etc. sempre fech-las no bloco finally. sso ir
garantir que mesmo se uma exceo ocorre aps a abertura da conexo, ser fechado com segurana no bloco finally.
Se o recurso utilizado implementa a interface IDisposable voc pode usar o comando using.

33. Declare variaveis o mais proximo possivel de onde ela usada pela primeira vez. Use uma declarao por linha.

34. Use a classe StringBuilder em vez de String quando voc tem que manipular objetos string em um loop. O objeto String
funciona de maneira estranha no. NET. Cada vez que voc acrescenta uma string, ela descartar o objeto string atual e
recria um novo objeto, o que uma operao relativamente cara.

Considere o senguine exemplo:




Padres de codificao e boas prticas de programao


public string ComposeMessage (string[] lines)
{
string message = String.Empty;

for (int i = 0; i < lines. Length; i++)
{
message += lines [i];
}

return message;
}

No exemplo acima, pode parecer que estamos apenas acrescentando a "mensagem ao objeto string. Mas o que est
acontecendo na realidade o objeto string descartado em cada iterao e recriado e acrescentando a linha para ele.
Se o seu ciclo tem vrias iteraes, ento uma boa idia, usar a classe StringBuilder em vez de objeto String.
Veja o exemplo em que o objeto String substitudo com StringBuilder.
public string ComposeMessage ( string[] lines )
{
String Builder message = new String Builder();

for ( int i = 0; i < lines. Length; i++ )
{
message. Append( lines[i] );
}

return message.ToString();
}


Padres de codificao e boas prticas de programao

7. Arquitetura
1. Sempre usar arquitetura multi camada (n-tier).

2. Nunca faa o acesso ao banco de dados direto das pginas U. Sempre tenha uma classe da camada de dados que
executa todas as tarefas relacionadas com banco de dados. sso ir ajud-lo a manuteno ou quando migrar para
outro banco de dados back-end com facilidade.

3. Use try-catch em sua camada de dados para capturar todas as excees do banco de dados. Este manipulador
de exceo deve registrar todas as excees do banco de dados. Os detalhes registrados devem incluir o nome do
comando executado, o nome do procedimento armazenado, parmetros, string de conexo usada, etc. Depois de
gravar a exceo, ela pode ser jogada para outra camada na aplicao que possa captura-la e tomar as medidas
adequadas.

4. Separe sua aplicao em vrios assemblies. Agrupe todas as classes de utilitrios independentes em uma biblioteca
de classes separada. Todos os arquivos relacionados com seu banco de dados podem estar em outra biblioteca de
classes.

8. ASP.NET
1. No use as variveis de sesso em todo o cdigo. Use variveis de sesso somente dentro de classes que expe
mtodos para acessar o valor armazenado nas variveis de sesso. Uma classe pode acessar a sesso usando
System.Web.HttpCOntext.Current.Session

Exemplo:
static class SessionWrapper
{
public static string Variable
{
get { return Session["variable"]; }
set { Session["variable"] = value; }
}
}

2. No armazenar objetos grandes na sesso. Armazenar objetos grandes em sesso pode consumir muita memria do
servidor, dependendo do nmero de usurios.

3. Sempre use folha de estilo para controlar a aparncia das pginas. Nunca especifique o nome e tamanho da fonte em
qualquer uma das pginas. Use uma classe de estilo apropriada. sso ajudar voc a mudar a interface do usurio de
sua aplicao facilmente no futuro. Alm disso, se voc gosta de personalizar a interface do usurio para cada cliente,
apenas uma questo de desenvolver outra folha de estilo para cada um deles.








9. Comentrios


Padres de codificao e boas prticas de programao

Comentrios compensam um cdigo ruim.
Uma das motivaes mais comuns para criar comentrios um cdigo ruim. Construmos um modulo e
sabemos que est confuso e desorganizado. Estamos cientes da baguna. Ns mesmos dizemos 'Oh,
melhor inserir um comentrio!". No! E melhor limp-lo.
Cdigos claros e expressivos com poucos comentrios so de longe superiores a um amontoado e complexo
com muitos comentrios. Ao invs de gastar seu tempo criando comentrios para explicar a baguna que voc
fez, use-o para limpar essa zona.

1. No escreva comentrios para cada linha de cdigo e cada varivel declarada.

2. Use / / ou / / / para comentrios. Evite usar / * ... * /

3. Escreva comentrios sempre que necessrio. Mas um cdigo bom e legvel exigir muito menos comentrios. Se todas
as variveis e nomes de mtodos forem auto-explicativos, o cdigo se torna muito mais legvel e a necessidade de
comentrios diminui significativamente.

4. No escreva comentrios se o cdigo facilmente compreensvel sem comentrios. A desvantagem de ter muitos
comentrios , se voc alterar o cdigo e esquecer-se de mudar o comentrio, ele ir levar a mais confuso.

5. Menos linhas de comentrios vo tornar o cdigo mais elegante. Mas se o cdigo no estiver limpo / legvel e existirem
poucos comentrios, ainda pior.

6. Se voc inicializar uma varivel numrica com um nmero especial diferente 0, documente o motivo para a escolha
desse valor.

7. Escreva cdigo limpo e legvel de tal forma que ele no precisa de quaisquer comentrios para ser entendido.

8. Verifique a ortografia e a pontuao dos seus comentrios, j que o seu cdigo est confuso e ruim necessitando de
comentrios para ser entendido, pelo menos escreva os comentrios corretamente.

10. ManipuIando Excees
1. Nunca faa uma "captura exceo e no faz nada". Se voc ocultar uma exceo, voc nunca vai saber se a exceo
aconteceu ou no. Muitos dos desenvolvedores usam esse mtodo til para ignorar erros no significativos. Voc deve
sempre tentar evitar excees, verificando todas as condies de erro de programao. Em qualquer caso, pegando uma
exceo e no fazer nada no permitido. No pior dos casos, voc deve registrar um log da exceo e prosseguir.

2. Em caso de excees, dar uma mensagem amigvel para o usurio, mas log o erro real com todos os detalhes possveis
sobre o erro, incluindo a data e hora que ocorreu, o nome do mtodo, o nome da classe, etc.

3. Sempre capturar apenas uma exceo especfica, e no exceo genrica.





Padres de codificao e boas prticas de programao


Bom:
public void ReadFromFile ( string fileName )
{
try
{
// L do arquivo.
}
catch ( FileIOException ex )
{
// faz o log de erro .
// re-throw exceo dependendo do seu caso.
throw;
}
}

Ruim:
void ReadFromFile ( string fileName )
{
try
{
// L do arquivo.
}
catch ( Exception ex )
{
// Capturar a exceo geral ruim... Nunca saberemos se
// foi um erro do arquivo ou algum outro erro.
// Aqui voc esta escondendo uma exceo.
// Nesse caso ningum vai saber que uma exceo ocorreu.

return "";
}
}


4. No h necessidade de capturar todas as exees gerais de seus mtodos. Deixe-as em aberto e deixe que a aplicao
lance. sso ir ajud-lo a encontrar a maioria dos erros durante o ciclo de desenvolvimento. Voc pode ter um nvel da
aplicao (thread level) manipulador de erro, onde voc pode lidar com todas as excees gerais. No caso de um "erro
inesperado geral", este manipulador de erro deve capturar a exceo e deve registrar o erro alm de dar uma mensagem
amigvel para o usurio antes de fechar o aplicativo, ou permitindo que o usurio ignore e prossiga.

5. Quando voc relanar uma exceo, use a instruo throw sem especificar a exceo original. Desta forma, a pilha de
chamada original ser preservada.

Bom:
catch
{
throw;
}




Ruim:
catch (Exception ex)
{


Padres de codificao e boas prticas de programao

throw ex;
}

6. No escreva try-catch em todos os seus mtodos. Use-os apenas se houver uma possibilidade de que uma exceo
especfica possa ocorrer e no podera ser impedida por qualquer outro meio. Por exemplo, se voc quiser inserir um
registro na base de dados, voc deve tentar selecionar o registro usando sua chave para verificar se ele ja existe e
depois inserir na base de dados. Alguns desenvolvedores tentam inserir um registro sem verificar se ele j existe. Se
ocorrer uma exceo, eles vo assumir que o registro j existe. sto no permitido. Voc deve sempre explicitamente
verificar se h erros em vez de esperar excees ocorrerem. Por outro lado, voc sempre deve usar manipuladores
de exceo, enquanto voc se comunica com sistemas externos, como rede, sistemas de dispositivos de hardware,
etc. Tais sistemas externos esto sujeitos a falhas a qualquer hora e a verificao de erros geralmente no confivel.
Nesses casos, voc deve usar manipuladores de exceo e tentar se recuperar de erro.

7. No escreva blocos try-catch muito grande. Se necessrio, escreva blocos try-catch separados para executar
cada tarefa e coloque apenas uma parte especfica do cdigo dentro do try-catch. sso ajudar voc a descobrir qual
parte do cdigo esta gerando a exceo e voc pode dar a mensagem de erro mais especfica para o usurio.

8. Extraia os blocos try-catch. Esses blocos no tem o direito de serem feios. Eles confundem a estrutura do cdigo e
misturam o tratamento de erro com o processamento normal do cdigo. Portanto, melhor colocar as estruturas try e
catch em suas propria funes.

Exemplo:

public void Delete( Page page )
{
try
{
DeletePageAndAllReferences( page );
}
catch( Exception ex )
{
LogError( ex )
}
}

private void DeletePageAndAllReferences ( Page page )
{
deletePage( page );
registry.DeleteReference( page.Name );
configKeys.DeleteKey( page.Name.MakeKey() );
}

private void LogError ( Exception ex )
{
Logger.Log( ex.Message );
}

A funo Delete acima s faz tratamento de erro. E facil entend-la e seguir adiante. A funo
DeletePageAndAllReferences s trata de processos que excluem uma pgina. Pode-se ignorar o tratamento de
erro. sso oferece uma boa separao que facilita a compreenso e alterao do cdigo.



Padres de codificao e boas prticas de programao

9. No passe null. Retornar null dos mtodos ja ruim, mas passar null ainda pior. A menos que esteja trabalhando com
uma AP que espere receber null, voc deve evitar passa-lo em seu cdigo sempre que possvel.

10. Escreva suas prprias classes de excees personalizadas se necessrio em sua aplicao. No derivar suas excees
personalizadas da classe base SystemException. Em vez disso, herdar de ApplicationException.
11. Sistema de controIe de verso (Version controI system)
1. Ao utilizar SVN com Tortoise, configure o Tortoise para que ignore extenses de arquivos que no so uteis ao projeto. V
em TortoiseSVN -> Setting e em Global ignore pattern adicione a seguinte linha abaixo:

*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store *\bin* *\obj* *\debug* *.suo *.user *.pdb
*.exe* *.scc *.vspscc *.ReSharper** **\_ReSharper.**