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 Alvesricardoloboalves@gmail.com http://pt.linkedin.com/in/rmalves/ http://twitter.com/rmalves