Este simples artigo foi construído com informações colhidas da ferramenta Microsoft Source Analysis. Esta ferramenta não está acessível para usuários que possuam versões Express do Visual Studio, então, esse foi um dos principais motivos que me impulsionaram para a criação deste “artigo compacto”. Algumas boas práticas relevantes que eu colhi ao longo do uso da ferramenta: 1. Boas práticas quanto aos métodos: a. Todos os métodos públicos precisam estar antes de todos os métodos - independentes do modificador de acesso deles. b. Todos os métodos private precisam estar depois de todos os protected c. Todos os métodos com modificador de acesso protected precisam ser colocados depois de todos os métodos com modificador de acesso internal. d. Métodos, independente do modificador de acesso, precisam iniciar com letras maiúsculas. e. Todos os métodos precisam estar depois de todos os construtores. Resumo da posição dos métodos em seu código: 1. Public Methods 2. Internal Methods 3. Protected Methods 4. Private Methods 2. Boas práticas quanto aos campos: a. Variáveis(campos) precisam ser declarados com o modificador de acesso private. Esses campos devem ser acessados através de propriedades. b. Variáveis com modificador de acesso private, precisam iniciar com letra minúscula. c. Caso não seja possível seguir a boa prática abordada acima no ponto 2.a, então, todos os campos com modificador de acesso public ou internal precisam começar com letra Maiúscula. d. Campos que sejam declarados como constantes(const), devem iniciar com letra maiúscula. 3. Boas práticas quanto ao código em geral: a. Todos os membros precisam ter um cabeçalho de documentação XML. b. Todo membro precisa ter um modificador de acesso explícito; quando omitido, o modificador de acesso é private, porém é uma boa prática explicitá-lo. c. Todo membro da classe quando referenciado nela própria, deve começar com o prefixo this d. A declaração condicional: IF. Quando contém, em seu corpo, uma única declaração para execução, ela deve estar envolvida com duas chaves: { ... } e. O seu código não precisa ter múltiplas linhas em branco após alguma instrução. f. Tipos built-in devem ser usados através de seu alias. g. Todas as propriedades precisam estar depois de todos os construtores. h. Todos os eventos precisam estar depois de todos os construtores, mas antes de todas as propriedades. Resumo da ordem dos membros: 1. Campos 2. Construtores 3. Eventos 4. Propriedades 5. Métodos(public, internal, protected e private) Demonstrando com alguns exemplos: O exemplos abaixo, serão abordado de acordo com os pontos listados acima. Exemplificando os pontos: 3.a e 3.b Quando um projeto XNA é criado, temos inicialmente o código a seguir: ///<summary> /// This is the main type for your game ///</summary> public class Game1 : Microsoft.Xna.Framework.Game { GraphicsDeviceManager graphics; SpriteBatch spriteBatch; Seguindo as boas práticas, temos: ///<summary> /// This is the main type for your game ///</summary> public class Game1 : Microsoft.Xna.Framework.Game { ///<summary> /// Algum comentario aqui ///</summary> private GraphicsDeviceManager graphics; ///<summary> /// Algum comentario aqui ///</summary> private SpriteBatch spriteBatch; Exemplificando o ponto 3.d Evite: if(Position1 > Position2) //alguma instrução Recomendado: if(Position1 > Position2) { //alguma instrução } Exemplificando o ponto 3.f Evite: ///<summary> /// Algum Comentário. ///</summary> private String minhaString; O recomendado: ///<summary> /// Algum Comentário. ///</summary> private string minhaString; Conclusão Existem inúmeras boas práticas a serem seguidas. Então, se você conhece alguma que não foi listada acima, fique a vontade em compartilhar conosco.
Referência:
Dúvidas, Críticas e Sugestões são bem-vindas.
Obrigado! |