Download - Práticas de Programação em .NET
Práticas de programação em .NETRicardo Alves
http://netponto.org15ª Reunião Presencial - 23/10/2010
Ricardo AlvesLicenciado do Instituto Superior de Engenharia de Lisboa (ISEL)4 anos de experiência profissionalC#, WCF, ASP.NET, SQL, VS LightSwitch, Agile methodologies
Agenda
• Naming Conventions
• Coding Practices
• Unit Tests Practices
Também disponível em vídeo...
Assista!http://www.vimeo.com/16498136
Naming Conventions
• Código tem de reflectir a sua intenção
• Código claro e objectivo
• Meio caminho andado para documentação
Naming Conventions• Naming Conventions da .Net Framework
http://msdn.microsoft.com/en-us/library/ms229045.aspx
– Escolher nomes facilmente legíveis e claros
– Dar preferência a legibilidade sobre brevidade
– Não usar underscore, hífenes, ou qualquer caracter não alfanumérico
– Não usar abreviações como identificadores
Naming Conventions• Naming Conventions da .Net Framework
http://msdn.microsoft.com/en-us/library/ms229045.aspx
– Só usar acrónimos que sejam bem conhecidos• Regra do Bing
– Fazer uma pesquisa no Bing pelo acrónimo, se o acrónimo aparecer nos primeiros resultados então podemos usar
– Regra não se aplica a acrónimos do negócio
– Usar nomes comuns, como value ou item, em casos onde o identificador e o seu tipo não têm qualquer valor semântico• Usado em parâmetros ou variáveis de iteração
– Não usar “Hungarian notation”
Naming Conventions• Naming Conventions da .Net Framework
http://msdn.microsoft.com/en-us/library/ms229045.aspx
– Pascal Case• A primeira letra é maiúscula e as restantes primeiras letras de cada palavra são maiúsculas
ObjectContext, BackColor
– Camel Case• A primeira letra é minúscula e as restantes primeiras letras de cada palavra são maiúsculas
numberOfDays, isValid
– Uppercase• Todas as letras são maiúsculas
PI, ID
Naming Conventions• Namespaces
– Pascal Case, não usar underscores– Acrónimos de 3 ou mais letras devem usar Pascal Case– Seguir padrão:
• <Nome da Empresa/Developer>.<Tecnologia>
AppliedIS.TimeCard.BusinessRules IrritatedVowel.ControllersPeteBrown.DotNetTraining.InheritanceDemoPeteBrown.DotNetTraining.Xml
Naming Conventions• Classes e estruturas
– Pascal Case, não usar underscores– Não usar nomes começados por “I” a não ser que a próxima letra seja minúscula, para não confundir com
interfaces– Acrónimos de 3 ou mais letras devem usar Pascal Case– Não devem usar o mesmo nome que o Namespace a que pertencem
WidgetInstanceManagerXmlDocumentMainFormDocumentFormHeaderControl
Naming Conventions• Interfaces– Usar as mesmas convenções que para as classes, mas o nome
deve começar com um “I” e a próxima letra deve ser maiúscula
IWidgetIComponent
Demo #1: Validar Naming Conventions através do FxCop
demonstração
Coding PracticesPrincípios S.O.L.I.D.
Coding Practices
• SOLID–Single Responsibility Principle
–Open/Closed Principle
–Liskov Substitution Principle
–Interface Segregation Principle
–Dependency Inversion Principle
Coding PracticesSingle Responsibility Principle
Coding Practices
• Single Responsibility Principle– Uma classe não deve ter mais que uma razão para ser
alterada
Demo #2: Single Responsability Principle
demonstração
Coding PracticesOpen/Closed Principle
Coding Practices
• Open/Closed Principle– Deve ser possível alterar o comportamento duma
classe sem a modificar
Demo #3: Open/Closed Principle
demonstração
Coding PracticesLiskov Substitution Principle
Coding Practices
• Liskov Substitution Principle– Classes derivadas devem ser substituíveis pelas suas
classes base
Demo #4: Liskov Substitution Principle
demonstração
Coding PracticesInterface Segregation Principle
Coding Practices
• Interface Segregation Principle– Classes não devem ser forçadas a implementar
interfaces que não usam
Demo #5: Interface Segregation Principle
demonstração
Coding PracticesDependency Inversion Principle
Coding Practices
• Dependency Inversion Principle– Módulos não devem depender de outros Módulos,
devem depender de abstracções
– Abstracções não devem depender dos detalhes, os detalhes é que devem depender das abstracções
Demo #6: Dependency Inversion Principle
demonstração
Coding Practices
• YAGNI– You ain’t gonna need it
• DRY– Don’t repeat yourself
• KISS– Keep it simple, stupid!
Unit Tests Practices• Ser o mais simples possível
• Ser independentes entre si
• Devem testar uma unidade de código de cada vez
• Usar Mocks para simular componentes externos
• Não testar configurações
• Não devem fazer asserções desnecessárias
Unit Tests Practices• Devem ter nomes claros e concisos
• Testar comportamentos e não métodos
• Testar apenas classes e métodos com visibilidade publica
• Criar testes para reproduzir bugs encontrados
• Assegurar que as excepções que são lançadas têm testes associados
Demo #6: Unit Tests Practices
demonstração
Dúvidas?
ReferênciasThe Principles of OOD
– http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Design Guidelines for Developing Class Libraries– http://msdn.microsoft.com/en-us/library/ms229042.aspx
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries
– http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613
Patrocinadores desta reunião
Obrigado!
Ricardo [email protected] http://pt.linkedin.com/in/rmalves/ http://twitter.com/rmalves