com um sistema apropriado. Uma excecao a regra e quando ha motivos legais para assegurar o autor do codigo, entao pode existir um cabecalho com o autor. Nao comente o obvio, coisas muito simples ou muito bem estabelecidas. Se um comentario obvio se faz necessario, entao na verdade e necessario renomear seu metodo para um nome que expresse seu proposito. Quando necessario, comente em uma linha separada (geralmente acima) e nao na linha do codigo Comece o comentario com letra maiuscula e termine com um ponto Insira um espaco entre o // e o inicio do comentario Comentarios de documentacao Comentarios de documentacao sao precedidos por /// e servem para definir a estrutura e uso de classes, metodos e propriedades para geracao de documentacao automatica com ferramentas como Doxygene, NDoc e SandCastle. Como seu objetivo e documentar uma interface implicita ou API para uso de outros programadores, comente apenas metodos e propriedades publicos e nunca comente membros privados. Porque: Isso esta de acordo com o Principio SOLID de programar voltado a interfaces e nao implementacao. Voce nao quer que outros programadores usem os metodos privados, entao nao ha necessidade deles aparecerem na documentacao. Assim voce encapsula e protege o source em um nivel adicional e esta livre para mudar a implementacao contanto que mantenha a mesma interface e funcionalidade. Try ... Finally Use o using sempre que seu bloco try ... finally servir apenas para chamar dispose em um recurso nao gerenciado. Exemplo:// This try-finally statement only calls Dispose in the finally block.Font font1 = new Font("Arial", 10.0f);try{ byte charset = font1.GdiCharSet;}finally{ if (font1 != null) { ((IDisposable)font1).Dispose(); }}// You can do the same thing with a using statement. using (Font font2 = new Font("Arial", 10.0f)){ byte charset = font2.GdiCharSet;} Refactoring Refactorings sao saudaveis e devem ser feitos. Sempre que achar que um codigo pode ser melhorado quanto a legibilidade melhore-o. Sempre que algo pode ser feito de maneira mais rapida, mais facil, mais elegante ou mais correta, refaca. Sempre que algo soar estranho, parecer "cheirar", troque. Use a regra do escoteiro e deixe o codigo mais limpo do que quando voce encontrou. Gambiarras Toda gambiarra no codigo se volta contra voce uma hora ou outra. Gambiarras causam infernos de manutencao, horas extras e expedientes de fim de semana. Toda gambiarra clama em alta voz por um refactoring. Um codigo ruim pode ter bad smells que sao fruto de desconhecimento, limitacoes tecnologicas, cansaco ou erro humano, MAS gambiarras sao sinais de relaxo, falta de etica e desorganizacao pessoal. O prazo nao e desculpa para se fazer uma gambiarra. Se ha uma forma mais elegante de se escrever um codigo procure melhora-lo, mas se ha uma forma definitivamente correta de se escrever um codigo, entao use essa forma. Excessoes a regra Widgets demasiadamente usados como Button e Textbox tem padroes de nomenclatura derivados da notacao hungara fortemente entrincheiradas em nosso dia - a - dia, por isso sao aceitaveis coisas como botoes precedidos de btn (btnSalvar) e inputs precedidos de txt (txtNome). Isso esta em conformidade com as praticas da Microsoft, pois os