e mantenha elas alinhadas. Sempre abra e feche as chaves em novas linhas. Certo: public virtual void setMensagemExplicacao( string mensagem) { MensagemExplicacao = mensagem; lgdExplicacao.Visible = true; lgdExplicacao.InnerText = mensagem; } Errado: public virtual void setMensagemExplicacao( string mensagem){ MensagemExplicacao = mensagem; lgdExplicacao.Visible = true; lgdExplicacao.InnerText = mensagem; } public virtual void setMensagemExplicacao( string mensagem){ MensagemExplicacao = mensagem; lgdExplicacao.Visible = true ; lgdExplicacao.InnerText = mensagem;} Porque: Chaves abertas ou fechadas no final de uma linha de codigo passam despercebidas e nao sao legiveis. O codigo pode ser confundido como parte do codigo acima. Espacos em branco Deixe espacos em branco entre os operadores e seus operandos. Isso facilita a leitura. Deixe espacos em branco entre um if, for ou foreach e sua expressao. Exemplo: if (UmFuncionario.Equals(EsteFuncionario)) Quebra de linhas Quebre linhas antes de abertura e fechamento de chaves, quebre linhas para separar ideias, agrupar conceitos relacionados, separar conceitos nao relacionados, separar a declaracao de variaveis de seu uso, quebrar cadeias longas de caracteres ou encadeamentos longos de chamadas de metodos ou propriedades. Tambem e bom quebrar as linhas em chamadas de funcoes com listas de parametros muito longas, e edentar esses parametros. Quebre linhas antes e depois de regions, antes e depois de um using, e separando os fornecedores na lista de usings. Regions Use regions para agrupar conceitos e separar interface de implementacao, eventos de metodos e de variaveris. Nao use regions aninhadas pois isso impoe complexidade desnecessaria. Nao use regions para esconder codigo comentado, sujeira e gambiarras. Indentacao/Recuo Use a indentacao padrao do C# no visual studio (um tab = 4 espacos). Indente conceitos subordinados. Se precisar separar cadeias longas de chamadas em linhas, ou cadeias longas de parametros quebradas em linhas. Quebre as linhas de uma sentenca SQL e Intente o SQL. Exemplo: ChamadaDeFuncao( par1, par2, par3, par4, par5, par6); { //codigo } Modulo obj = session .CreateCriteria< Modulo>() .SetTimeout(120) .SetLockMode( LockMode.None) .SetCacheable( true) .Add( Restrictions.Eq("Nome" , nome)) .UniqueResult< Modulo>(); Comentarios Algumas definicoes dos nossos padroes foram feitas para VB antigo e se chocam diretamente com os padroes da microsoft, por exemplo o padrao de comentarios:"Do not create formatted blocks of asterisks around comments." Ha comentarios que prejudicam a legibilidade do codigo, nao sao atualizados no mesmo ritmo do codigo, sujam o mesmo e poderiam facilmente ser substituidos por nomes significativos Ha comentarios que simplesmente perdem o sentido pouco tempo depois de terem sido colocados, simplesmente porque o codigo logo abaixo deles ou o objetivo do sistema em si foi mudado. Nao comente o codigo simplesmente para desativa-lo esperando que um dia va precisar dele. Antes de dar check-in, delete o codigo comentado. Codigo comentado apenas emporcalha o sistema, deteriorando-o mais rapido. Outros programadores acharao que e importante e evitarao remove-lo. Se um dia, quando ele nao for mais util, ele acidentalmente for descomentado ele pode comprometer todo o funcionamento do sistema. Confie no seu sistema de versionamento. Nao coloque cabecalhos com informacoes de autor, versionamento, changelog e bugtracking em comentarios. Confie no seu sistema de versionamento, faca os comentarios de changelog ao dar check-in no sistema, controle o bugtracking