Regras de Codificação Semi-Resumido

Arquitetura de Sistemas
Padro de Nomenclatura e Codificao .NET / C#
1. NOMENCLATURA C#
1.1.
Variveis Locais
Formato (regra da nomenclatura)

<Identificador>[<Complemento>]
Onde:
<Identificador>: utiliza regra Camel Case, ou seja, todos os caracteres deste
identificador devem estar em minsculo.
<Complemento>: utilizar o primeiro caractere em maisculo.
Exemplos de uso (correto)
public override int ProcessLine()
{
string codigoUsuario = null;
int codigoErro = 0;
Exemplos de uso (incorreto)

public override int ProcessLine()
{
string strCodUsuario = null;
int CodigoErro = 0;
1.2.
Variveis de Classe

_<Identificador>[<Complemento>]
Onde:
separadores de termos. (A diferenciao pode ser obtida pelo fato de cada termo utilizar
o primeiro caractere em maisculo).
18/8/2015
Pgina 1 de 35

public class Produto
{
#region Atributos privados
private int _colunaInicial;
private int _tamanhoLinha;
private string _identificadorCampo;
private string _nome;
#endregion

{
#region Atributos privados
private int colunaInicial = 0;
private int TamanhoLinha = 0;
private string _nomeProduto = "";
#endregion
1.3.
Parmetros de Mtodos

Onde:
separadores de termos. (A diferenciao pode ser obtida pelo fato de cada termo utilizar
o primeiro caractere em maisculo).
public int GetFieldRules(string codigoCampo)
{

public int GetFieldRules(string codigoCampo_)
{
18/8/2015
Pgina 2 de 35
1.4.
Constantes

<Identificador>[_<Complemento>]
Onde:
<Identificador>: Todas as letras devem estar em maisculas.
Caso seja necessrio adicionar um complemento ao nome da constante, com o objetivo
de clarificar sua funo, recomendamos o uso do _ como caractere separador.
<Complemento>: O primeiro caractere formador do complemento devem estar em
maisculo.
{
#region Constantes
private const string CODIGO_LINGUA = BRA;
private const string CODIGO_MOEDA = BRL;
#endregion

{
#region Constantes
private const string CODIGOLINGUA = BRA;
private const string codigoMoeda = BRL;
#endregion
18/8/2015
Pgina 3 de 35
1.5.
Classes

Onde:
<Identificador>: utiliza regra Pascal Case, ou seja, a primeira letra do identificador
deve estar em maiscula seguida das demais letras em minscula.
<Complemento>: utiliza o primeiro caractere em maisculo.
Outras informaes
Alm do formato descrito acima, vale reforar:
Na formao do nome da classe, evitar o uso de prefixos tais como cCliente, CCliente etc;
prefira Cliente.
No caso da classe for um controller devemos sempre deixar o aps o nome o sufixo
Controller.
Especificamente para o caso onde o identificador comea com a letra I, pode haver alguma
confuso com a nomenclatura adotada para a Interface. Porm deve-se ressaltar que na
nomenclatura de interfaces, a primeira letra I maiscula seguida de uma segunda letra
tambm em maiscula; diferentemente da declarao de classes, onde temos apenas o
primeiro caractere do identificador em maisculo.

{
#region Constantes
private const string
#endregion
...
public class ListaPreco
{
#region Constantes
18/8/2015
Pgina 4 de 35
CODIGO_LINGUA = BRA;
CODIGO_MOEDA = BRL;
CODIGO_MERCADORIA = 001;
CODIGO_MOEDA = BRL;
#endregion
public class PrecoController
{

public class produto
{
#region Constantes
private const string CODIGOLINGUA = BRA;
private const string codigoMoeda = BRL;
#endregion
...
public class item_venda
{
#region Constantes
private const string CODIGOMERCADORIA = 001;
...
public class listaPreco
{
#region Constantes
private const string CODIGOMOEDA = BRL;
1.6.
Propriedades

Onde:
<Identificador> : Os identificadores utilizam regra Pascal Case, ou seja, o primeiro
caractere deve ser grafado em maiscula seguido de caracteres em minsculo.
<Complemento> : utiliza o primeiro caractere em maisculo.
18/8/2015
Pgina 5 de 35
public string NomeProduto { get; set; }

private string _nomeProduto;
...
public string nome_Produto
{
get
{
return _nomeProduto;
}
set
{
_nomeProduto = value;
}
}
...
public string produtos_estocados
{
get
{
return _nomeProduto;
}
set
{
_nomeProduto = value;
}
}
1.7.
Exceo

Excecao<Identificador>[<Complemento>]
Onde:
Excecao: Constante que indica o tipo da classe.
18/8/2015
Pgina 6 de 35
<Identificador> : utiliza regra Pascal Case, ou seja, a primeira letra do identificador

deve estar em maiscula seguida das demais letras em minscula.
class ExcecaoArquivoNaoEncontrado : Exception
{
public ExcecaoArquivoNaoEncontrado (string str)
{
Console.WriteLine(Arquivo no encontrado);
}
}

class ArquivoNaoEncontrado : Exception
{
public ArquivoNaoEncontrado(string str)
{
}
}
...
class _arquivoNaoEncontrado: Exception
{
public _arquivoNaoEncontrado (string str)
{
}
}
1.8.
Mtodos

Onde:
18/8/2015
Pgina 7 de 35
<Identificador> : Os identificadores utilizam regra Pascal Case, ou seja, a primeira

letra do identificador deve estar em maiscula seguida das demais letras em minscula.
public class Cliente
{
private bool Incluir(string cpf)
{
...

{
private bool validar_Cliente(string cpf)
{
...
...
{
private bool validacaoCliente(string cpf_)
{
...
1.9.
Interfaces

<I><Identificador>[<Complemento>]
Onde:
<I> : Caractere I em maisculo como prefixo para definir que se trata de uma interface
Outras informaes
No utilize _ ou outro caractere de separao para declarao de um nome de interface.
18/8/2015
Pgina 8 de 35

interface INode
{
string Texto
{
get;
set;
}
}

interface Interface_Node
{
string Texto
{
get;
set;
}
}
...
interface MeuNode
{
string Texto
{
get;
set;
}
}
1.10. Enumeradores
Onde:
18/8/2015
Pgina 9 de 35

Outras informaes
Assim como o nome do Enum type, os nomes referentes ao Enum values type devem seguir a
mesma regra de nomenclatura.
No utilize abreveaes para definir um Enum, nem utilize o sufixo Enum para nomear um
enumeration.
Outro ponto importante: Evite prefixar os elementos do enum com o identificador do enum. Por
exemplo, se o tipo do Enum for DigitalResolution, evitar nomear os
membros como
DigitalResolution800, DigitalResolution1000, etc.
enum DiasSemana {Domingo = 0, Segunda, Terca, Quarta, Quinta, Sexta, Sabado};

enum dias_semana {Domingo = 0, Segunda, Terca, Quarta, Quinta, Sexta, Sabado};
enum _diasSemana {Domingo = 0, Segunda, Terca, Quarta, Quinta, Sexta, Sabado};
enum EnumDias {_domingo = 0, _segunda, _terca, _quarta, _quinta, _sexta,
_sabado};
enum TipoImagem {TipoImagemBitmap = 0, TipoImagemGIF, TipoImagemTIFF };
1.11. Namespaces
<CompanyName><Type><ApplicationName>[<Package>[<Feature>]]
Onde:
<CompanyName> : O CompanyName utiliza regra Pascal Case, ou seja, a primeira
<Type> : Tipo do namespace (Arquitetura ou Aplicao).
<ApplicationName> : Identificao do nome da aplicao (ou class library).
ApplicationName deve utilizar regra Pascal Case, ou seja, a primeira letra do
identificador deve estar em maiscula seguida das demais letras em minscula.
<Package> : Identifica um grupo de funcionalidades. Package utiliza regra Pascal
Case, ou seja, a primeira letra do identificador deve estar em maiscula seguida das
demais letras em minscula.
18/8/2015
Pgina 10 de 35
<Feature> : Identifica uma funcionalidade de aplicao (ou class library). Feature utiliza
regra Pascal Case, ou seja, a primeira letra do identificador deve estar em maiscula
seguida das demais letras em minscula.
Outras informaes
Para uso no exemplo abaixo temos:
CompanyName = Belagricola
Type = Arquitetura
ApplicationName = Cockpit
Package = Comunicacao (Conjunto de classes que implementam a Comunicao)

namespace Belagricola.Arquitetura.Cockpit.Comunicacao

namespace Belagricola.ARQUITETURA.cokpit.Comunicacao
namespace teste.comunicacao
1.12. Controles de Formulrios

<prefixo de tipo de elemento><Identificador>[<Complemento>]
Onde:
<Prefixo de tipo de elemento> : Prefixo nico de 3 caracteres usados como
identificador do tipo de controle.
<Identificador> utiliza
regra Pascal Case, ou seja, a primeira letra do identificador deve estar em maiscula
seguida das demais letras em minscula.
Prefixo
lbl
hpl
18/8/2015
Pgina 11 de 35
Elemento
Label
HyperLink
txt
opt
chk
pnl
img
dg
btn
ddl
cbo
msk
grp
uc
tela
controle
Texto Box
Radio Button
Check Box
Panel
Image
DataGrid
Button
DropDown List box
Combo Box
Masked Text Box
Group Box
User Control
ITela
IControle

imgIDTMUN, txtCodigoSistema, lblIDTMun
(*) Os nomes dos controles devem ser gerados usando a notao hngara com os prefixos
conforme definidos na tabela acima.
IDTMUN, IdtMun
18/8/2015
Pgina 12 de 35
2. REGRAS DE CODIFICAO
2.1.
Utilizao de constantes
Descrio
No utilize nmeros e strings hard-coded, prefira o uso de constantes.
Motivo
Como os valores desejados esto definidos em uma constante, torna-se mais fcil a manuteno
do cdigo caso seja necessrio alterar tais valores.
switch(tipoEmail)
{
case EMAIL_HTML:
...
break;
case EMAIL_TEXTO:
...
break;
}
...
if (produto.Moeda == CODIGO_REAL)
{
...
}

switch(tipoEmail)
{
case Html:
...
break;
case Texto:
...
break;
}
18/8/2015
Pgina 13 de 35
...
if (produto.Moeda == 21)
{
...
}
2.2.
Regies de cdigo
Descrio
Utilize sempre o bloco region para organizar o cdigo de uma classe.
Utilizar as seguintes regies
- Constantes para organizar as constantes;
- Atributos para organizar os atributos;
- Construtores para organizar os construtores;
- Mtodos Privados para organizar os mtodos privados;
- Mtodos Pblicos para organizar os mtodos pblicos;
- Mtodos Privados Estticos para organizar os mtodos privados e estticos;
- Mtodos Pblicos Estticos para organizar os mtodos pblicos e estticos;
Outras informaes
Caso o programador deseje utilizar um comentrio em uma determinada etapa de seu cdigo ele
poder realizar utilizando // acima do comando desejado.
Todos os comentrios devem ser feitos em Portugus.
#region Atributos
private string _nome = string.Empty;
#endregion
#region Constantes
private const string CODIGO_LINGUA = "BRA";
#endregion
#region Construtores
18/8/2015
Pgina 14 de 35
public Fornecedor()
{
}
#endregion
#region Mtodos Privados
private bool Incluir(string cpf)
{
return true;
}
#endregion
#region Mtodos Pblicos
public bool Persistir(string cpf)
{
return true;
}
#endregion
#region Mtodos Privados Estticos
private static bool Inserir()
{
return true;
}
#endregion
#region Mtodos Pblicos Estticos
public static bool Persistir(string cpf)
{
return true;
}
#endregion
18/8/2015
Pgina 15 de 35
2.3.
Comentrios
Descrio
Utilize sempre o bloco summary antes de uma classe ou um mtodo publico. O bloco summary
deve descrever o objetivo da classe ou mtodo e, utilizando a tag param quando necessrio, os
parmetros de entrada que possui.
Todavia, caso o programador no deseje adicionar um resumo a uma rotina especfica ele pode
utilizar a forma /* ... */ para realizar o comentrio desejado.
Motivo
Utilizando a tag de summary, o Visual Studio .NET interpreta internamente tal comentrio como
descrio da classe/mtodo.
Outras informaes
Caso o programador deseje utilizar um comentrio em uma determinada etapa de seu cdigo ele
poder realizar utilizando // acima do comando desejado.
Todos os comentrios devem ser feitos em Portugus.
/// <summary>
/// Descrio Descrio Descrio Descrio Descrio Descrio
/// </summary>
/// <param name="parametro1">Descricao</param>
/// <param name="parametro2">Descricao</param>
/// <returns>Descricao</returns>
private bool MyClass(string parametro1, string parametro2)
{
...
...
// Valida a existncia de um registro no array
if (myArray.Length > 0)
{
...

18/8/2015
Pgina 16 de 35
// Descrio Descrio Descrio Descrio Descrio

private bool MyClass(string parametro1, string parametro2)
{
...
...
///
///
///
///
<summary>
Valida a existncia de um registro no array
</summary>
<returns></returns>
if (myArray.Length > 0)
{
...
2.4.
Comentrios II
Descrio
No escreva comentrios para cada linha de cdigo ou para cada declarao de varivel.
Motivo
Escreva comentrios apenas onde necessrio, de tal forma que o cdigo no fique poludo e de
difcil leitura.
18/8/2015
Pgina 17 de 35
2.5.
Tabulao e espaamento
Descrio
Utilize sempre <TAB> (de 4 espaos) para alinhamento, nunca utilize <ESPAO> para definir
coluneamento.
Motivo
Utilizando <TAB> o programador mantm um padro para o coluneamento, tornando o cdigo mais
legvel e agradvel, principalmente a quem prestar manuteno.
private void MyClass()
{
if (...)
{
for (...)
{
//codigo ...
}
}
}

{
if (...)
{
for (...)
{
//codigo ...
}
}
}
18/8/2015
Pgina 18 de 35
2.6.
Marcadores de inicio de bloco
Descrio
Evite colocar o marcador de incio de bloco na mesma linha do comando (if, for, while, etc.). Nestas
construes, coloque o marcador em linha separada.
Motivo
O uso do marcador de incio de bloco em linhas separadas aumenta consideravelmente a
legibilidade do programa.
{
if (...)
{
for (...)
{
//codigo ...
}
}
}

{
if (...) {
for (...) {
//codigo ...
}
}
}
18/8/2015
Pgina 19 de 35
2.7.
Marcadores de inicio de bloco II
Descrio
Os blocos subseqentes ao comando if sempre devem sempre possuir os marcadores de bloco.
Motivo
Evitar erros de codificao por erros de compreenso durante a digitao/leitura do cdigo.
{
if (...)
{
for (...)
{
//codigo ...
}
}
}

{
if (...)
for (...) {
//codigo ...
}
}
18/8/2015
Pgina 20 de 35
2.8.
Tamanho de arquivos
Descrio
Evite a construo de arquivos fontes muito grandes. Se um arquivo de programa fonte estiver com
mais de 400 linhas, provavelmente ela no est bem estruturada.
Motivo
Arquivos muito grandes indicam que a classe nela contida tem muita lgica implementada e
provavelmente no est desenhada de forma a hierarquizar e estruturar os componentes de forma
organizada. Nestas situaes h fortes indcios de que a modelagem de objetos aplicada est
degenerada ou compondo mais de uma entidade numa s.
2.9.
Tamanho de mtodos
Descrio
Evite a construo de mtodos com mais de 30 linhas de cdigo.
Motivo
Mtodos com muitas linhas de cdigo tm sua legibilidade comprometida e provavelmente o ndice
de reutilizao de cdigo est comprometido.
18/8/2015
Pgina 21 de 35
2.10. Construes no autorizadas

Descrio
proibido utilizar nomes que coincidam com as palavras reservadas do .NET Framework.
Tambm vetada a utilizao de atributos pblicos dentro das classes, deve-se utilizar
propriedades.
Motivo
Criar variveis com nomes semelhantes s palavras reservadas do .NET pode confundir a
interpretao de campos. Esta prtica dificulta a identificao de se a varivel trata-se ou no de
uma definio de campo ou simplesmente uma varivel.
J o uso dos atributos pblicos no recomendvel devido ao comportamento destes que isola o
campo dentro da classe onde declarado, e possui o conceito de hereditariedade.
public string NomeProduto{ get; set; }

private string[] collections;
18/8/2015
Pgina 22 de 35
2.11. Comando Switch

Descrio
Ao utilizar a construo switch/case, deve-se sempre definir o tratamento padro (entrada default).
Motivo
A definio do tratamento padro obriga o desenvolvedor a pensar na situao de exceo j
durante a codificao, ao invs de adicionar o tratamento quando alguma condio de exceo e
inesperada ocorra e faa com que nenhuma das opes listadas no switch/case seja executada.

switch(condio)
{
case AAA:
{
...
break
}
case AAB:
{
...
break
}
default:
{
...
break
}
}

switch(condio)
{
case AAA:
{
...
break
}
case AAB:
18/8/2015
Pgina 23 de 35
{
...
break
}
}
2.12. Tratamento de exceo

Descrio
Ao utilizar a construo try/catch, nunca construa a lgica do catch com implementao vazia.
Motivo
Este tipo de construo realiza o tratamento da ocorrncia do erro que pode ser propagado para as
demais camadas da aplicao, tornando o programa instvel de difcil depurao.
try
{
executar logica
}
catch (System.Exception e)
{
// gravar o erro
// executar o tratamento para esta condio
}

try
{
executar logica
}
catch (System.Exception e)
{
// ignorar a ocorrncia do erro
Return;
}
18/8/2015
Pgina 24 de 35
2.13. Validao Local I

Descrio
As validaes funcionais de negcio das informaes inseridas pelo usurio durante a execuo de
um programa devero ser realizadas nas classes de negcio. Nenhuma validao de regra de
negcio deve existir na apresentao.
Motivo
Para maximizar a reutilizao das regras de negcio codificadas para uma aplicao, importante
que toda a regra de negcio seja codificada em uma mesma camada da arquitetura da soluo.
Alm disso, esta camada deve estar localizada na arquitetura de forma que sua reutilizao seja
realmente proveitosa. Neste sentido, se codificarmos regras de negcio na camada de
apresentao, estaremos eliminando a possibilidade de reutilizao desta regra em outras
aplicaes. Desta forma, as validaes funcionais devero ser realizadas nas classes do projeto de
negcio.

if (classeNegocio.ValidaPermicao(usuario))
{
Executar Mensagem de Erro
}

if (usuario.Permicao == 11)
{
Executar Regra de Negcio
}
18/8/2015
Pgina 25 de 35
2.14. Validao Local II

Descrio
Existem algumas validaes estruturais das informaes inseridas pelo usurio que devem fazer
parte da validao na apresentao, por exemplo, validaes de Formato de Data, CPF, CNPJ, email, Cdigo Conta Corrente, entre outros.
Motivo
Estas validaes devem ocorrer na apresentao para possibilitar uma maior performance do
sistema. Todas as informaes que possam ser inseridas por usurios em diferentes partes do
sistema e tenham sua estrutura previamente especificada, podero fazer parte desta validao. As
funes de validaes devero estar especificadas em uma mesma biblioteca facilitando sua
utilizao.
if (!(VerificarEmail(usuario.Email))
{
Executar Mensagem de Erro
}
18/8/2015
Pgina 26 de 35
3. BOAS PRTICAS
3.1.
Uso de sufixos proibidos
Descrio
Existem alguns sufixos que devem ter sua utilizao evitada por serem usados para outro
propsito. Desta forma, deve-se evitar o uso dos seguintes sufixos:
- Attribute
- Collection
- Dictionary
- EventArgs
- EventHandler
- Exception
- Queue
- Stack
- Stream
- Delegate
- Enum
- Flags
- Impl.
Motivo
Os sufixos listados acima j so usados por tipos bsicos do framework .net e desta forma o seu
uso pode causar confuso aos desenvolvedores.
18/8/2015
Pgina 27 de 35
3.2.
Variveis
Descrio
Sempre evite a declarao de mais de uma varivel do mesmo tipo em uma s linha. Sempre que
possvel, tabular um bloco lgico.
Sempre que possvel prefira o tipo implcito var como ele deixamos o cdigo mais limpo.
Motivo
Isso facilita a visualizao das variveis e seus respectivos tipos bem como seus valores iniciais.
Tambm evita que ocorra uma condio imprevista por falta de um contedo vlido atribudo
varivel.
Exemplos de uso
string nome;
string sexo;
int
idade;
string usuario;
var sobreNome;
3.3.
Espaamento
Descrio
Sempre utilize um espao simples para a separao de operadores e vrgulas/ponto e vrgula em
uma mesma instruo.
Motivo
Utilizando esta prtica, a interpretao da instruo fica mais simples e legvel.
Exemplos de uso
for(var i = 0; i < total; i++)
{
BuscaNome(param1, param2);
...
int total = valor1 + valor2;
18/8/2015
Pgina 28 de 35
18/8/2015
Pgina 29 de 35
3.4.
Abreviaes
Descrio
Evite o uso de abreviaes na formao de nomes, salvo quando sejam abreviaes bastante
conhecidas. Por exemplo: UI para User-Interface.
Motivo
Evitando a utilizao de abreviaes, o nome formado tem seu verdadeiro significado, evitando
causar dvidas durante a interpretao de sua funcionalidade.
Exemplos de uso
private bool ObtemCredito()
{
...
...
string NomeCliente = Joao;
private const string TIPO_CREDITO = 001;
3.5.
Uso de caixa alta/baixa
Descrio
Evite o uso de nomes que requerem diferenciao entre maisculas e minsculas, ou seja, no
criar elementos cujos nomes, se convertidos todos os caracteres para maisculas tornam-se
iguais. O mesmo vale para a criao de namespaces.
Motivo
Algumas linguagens no fazem diferenciao entre letras maisculas e minsculas e isto pode
dificultar a reutilizao de componentes entre estes ambientes.
Exemplo
void Analyser()
18/8/2015
Pgina 30 de 35
{
...
...
}
void analyser()
{
...
...
}
18/8/2015
Pgina 31 de 35
3.6.
Construo de mais de um comando na mesma linha
Descrio
Evite a codificao de mais de um comando na mesma linha.
Motivo
Este tipo de construo dificulta a legibilidade do programa, sem trazer qualquer outro benefcio.
Exemplo (Correto)
userAge++;
userName += CONST_VALUE;
Exemplo (Incorreto)
userAge++; userName = += CONST_VALUE ;
18/8/2015
Pgina 32 de 35
3.7.
Especializao de mtodos
Descrio
Ao definir a funcionalidade de um mtodo, cuidar para que o mesmo realize apenas uma tarefa.
Evite a construo de mtodos que fazem mais de uma atividade.
Motivo
Ao construir mtodos que realizam uma nica tarefa, mesmo que ela seja muito simples, estamos
implicitamente promovendo a reusabilidade do mesmo.
Exemplo (Correto)
public int SendMail(string address, string msg);
public int SendSMS(string address, string msg);
Exemplo (Incorreto)
public int SendMailSMS(string address, string msg, int tipo);
18/8/2015
Pgina 33 de 35
3.8.
Evitar a declarao de parmetros no usados em mtodos
Descrio
Ao definir a assinatura de um mtodo, assegurar que todos os parmetros definidos em sua lista
sejam referenciados pela lgica interna do mtodo.
Motivo
Parmetros no utilizados internamente implicam em consumo desnecessrio de memria e CPU,
consequentemente degradando a performance do programa.
18/8/2015
Pgina 34 de 35
4. GLOSSRIO
A seguir temos a descrio de alguns dos termos utilizados neste documento.
Pascal Case: Termo normalmente usado para definir uma prtica de nomear identificadores. A
regra consiste em escrever palavras compostas ou frases onde as palavras so concatenadas
sem espao e cada palavra tem a primeira letra em maiscula e as demais em minscula.
Camel Case: Termo normalmente usado para definir uma prtica de nomear identificadores. A
regra consiste em escrever palavras compostas ou frases onde as palavras so concatenadas
sem espao e cada palavra (com a exceo da primeira) tem a primeira letra em maiscula e as
demais em minscula. A primeira palavra deve ter todas as letras em minsculas.
Notao Hngara: Termo normalmente usado para definir a conveno usada para nomear
objetos utilizando seu tipo como prefixo do nome. Nesta notao, os nomes de variveis comeam
com uma ou mais letras cujo mnemnico representa o tipo da varivel seguido de outra palavra
usada para identificar a funo da mesma.
18/8/2015
Pgina 35 de 35

Regras de Codificação Semi-Resumido

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Regras de Codificação Semi-Resumido

Enviado por

Direitos autorais:

Formatos disponíveis

Arquitetura de Sistemas

Padro de Nomenclatura e Codificao .NET / C#

Formato (regra da nomenclatura)

Exemplos de uso (incorreto)

Formato (regra da nomenclatura)

Exemplos de uso (correto)

Exemplos de uso (incorreto)

Formato (regra da nomenclatura)

Exemplos de uso (incorreto)

Formato (regra da nomenclatura)

Exemplos de uso (incorreto)

Formato (regra da nomenclatura)

Exemplos de uso (correto)

Exemplos de uso (incorreto)

Formato (regra da nomenclatura)

public string NomeProduto { get; set; }

Exemplos de uso (incorreto)

Formato (regra da nomenclatura)

<Identificador> : utiliza regra Pascal Case, ou seja, a primeira letra do identificador

Exemplos de uso (incorreto)

Formato (regra da nomenclatura)

<Identificador> : Os identificadores utilizam regra Pascal Case, ou seja, a primeira

Exemplos de uso (incorreto)

Formato (regra da nomenclatura)

Exemplos de uso (correto)

Exemplos de uso (incorreto)

<Complemento> : utiliza o primeiro caractere em maisculo.

Exemplos de uso (incorreto)

Package = Comunicacao (Conjunto de classes que implementam a Comunicao)

Exemplos de uso (correto)

Exemplos de uso (incorreto)

1.12. Controles de Formulrios

Exemplos de uso (correto)

Exemplos de uso (incorreto)

Exemplos de uso (incorreto)

// Descrio Descrio Descrio Descrio Descrio

Exemplos de uso (incorreto)

Marcadores de inicio de bloco

Exemplos de uso (incorreto)

Marcadores de inicio de bloco II

Exemplos de uso (incorreto)

2.10. Construes no autorizadas

Exemplos de uso (incorreto)

2.11. Comando Switch

Exemplos de uso (correto)

Exemplos de uso (incorreto)

2.12. Tratamento de exceo

Exemplos de uso (incorreto)

2.13. Validao Local I

Exemplos de uso (correto)

Exemplos de uso (incorreto)

2.14. Validao Local II

Uso de sufixos proibidos

Uso de caixa alta/baixa

Construo de mais de um comando na mesma linha

Evitar a declarao de parmetros no usados em mtodos

Você também pode gostar