Este documento resume uma apresentação sobre práticas de programação em .NET. A apresentação discute convenções de nomenclatura, princípios de design como SOLID e práticas de testes unitários. Exemplos de código demonstram cada tópico.

1. http://netponto.org15ª Reunião Presencial - 23/10/2010Práticas de programação em .NETRicardo Alves

2. Ricardo AlvesLicenciado do Instituto Superior de Engenharia de Lisboa (ISEL)4 anos de experiência profissionalC#, WCF, ASP.NET, SQL, VS LightSwitch, Agilemethodologies

3. AgendaNamingConventionsCodingPracticesUnitTestsPractices

4. Também disponível em vídeo...Assista!http://www.vimeo.com/16498136

5. NamingConventionsCódigo tem de reflectir a sua intençãoCódigo claro e objectivoMeio caminho andado para documentação 

6. Naming ConventionsNamingConventions da .Net Frameworkhttp://msdn.microsoft.com/en-us/library/ms229045.aspxEscolher nomes facilmente legíveis e clarosDar preferência a legibilidade sobre brevidadeNão usar underscore, hífenes, ou qualquer caracter não alfanuméricoNão usar abreviações como identificadores

7. Naming ConventionsNamingConventions da .Net Frameworkhttp://msdn.microsoft.com/en-us/library/ms229045.aspxSó usar acrónimos que sejam bem conhecidosRegra do BingFazer uma pesquisa no Bing pelo acrónimo, se o acrónimo aparecer nos primeiros resultados então podemos usarRegra não se aplica a acrónimos do negócioUsar nomes comuns, como value ou item, em casos onde o identificador e o seu tipo não têm qualquer valor semânticoUsado em parâmetros ou variáveis de iteraçãoNão usar “Hungariannotation”

8. Naming ConventionsNamingConventions da .Net Frameworkhttp://msdn.microsoft.com/en-us/library/ms229045.aspxPascal CaseA primeira letra é maiúscula e as restantes primeiras letras de cada palavra são maiúsculasObjectContext, BackColorCamel CaseA primeira letra é minúscula e as restantes primeiras letras de cada palavra são maiúsculasnumberOfDays, isValidUppercaseTodas as letras são maiúsculasPI, ID

9. Naming ConventionsNamespacesPascal Case, não usar underscoresAcrónimos de 3 ou mais letras devem usar Pascal CaseSeguir padrão:<Nome da Empresa/Developer>.<Tecnologia>AppliedIS.TimeCard.BusinessRulesIrritatedVowel.ControllersPeteBrown.DotNetTraining.InheritanceDemoPeteBrown.DotNetTraining.Xml

10. Naming ConventionsClasses e estruturasPascal Case, não usar underscoresNão usar nomes começados por “I” a não ser que a próxima letra seja minúscula, para não confundir com interfacesAcrónimos de 3 ou mais letras devem usar Pascal CaseNão devem usar o mesmo nome que o Namespace a que pertencemWidgetInstanceManagerXmlDocumentMainFormDocumentFormHeaderControl

11. Naming ConventionsInterfacesUsar 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úsculaIWidgetIComponent

12. Demo #1: Validar NamingConventions através do FxCopdemonstração

13. CodingPracticesPrincípios S.O.L.I.D.

14. CodingPracticesSOLIDSingle ResponsibilityPrincipleOpen/ClosedPrincipleLiskovSubstitutionPrincipleInterface SegregationPrincipleDependencyInversionPrinciple

15. CodingPracticesSingle ResponsibilityPrinciple

16. CodingPracticesSingle ResponsibilityPrincipleUma classe não deve ter mais que uma razão para ser alterada

17. Demo #2: Single ResponsabilityPrincipledemonstração

18. CodingPracticesOpen/ClosedPrinciple

19. CodingPracticesOpen/ClosedPrincipleDeve ser possível alterar o comportamento duma classe sem a modificar

20. Demo #3: Open/ClosedPrincipledemonstração

21. CodingPracticesLiskovSubstitutionPrinciple

22. CodingPracticesLiskovSubstitutionPrincipleClasses derivadas devem ser substituíveis pelas suas classes base

23. Demo #4: LiskovSubstitutionPrincipledemonstração

24. CodingPracticesInterface SegregationPrinciple

25. CodingPracticesInterface SegregationPrincipleClasses não devem ser forçadas a implementar interfaces que não usam

26. Demo #5: Interface SegregationPrincipledemonstração

27. CodingPracticesDependencyInversionPrinciple

28. CodingPracticesDependencyInversionPrincipleMódulos não devem depender de outros Módulos, devem depender de abstracçõesAbstracções não devem depender dos detalhes, os detalhes é que devem depender das abstracções

29. Demo #6: DependencyInversionPrincipledemonstração

30. CodingPracticesYAGNIYouain’tgonnaneeditDRYDon’trepeatyourselfKISSKeepitsimple, stupid!

31. Unit Tests PracticesSer o mais simples possívelSer independentes entre siDevem testar uma unidade de código de cada vezUsar Mocks para simular componentes externosNão testar configuraçõesNão devem fazer asserções desnecessárias

32. Unit Tests PracticesDevem ter nomes claros e concisosTestar comportamentos e não métodosTestar apenas classes e métodos com visibilidade publicaCriar testes para reproduzir bugs encontradosAssegurar que as excepções que são lançadas têm testes associados

33. Demo #6: UnitTestsPracticesdemonstração

34. Dúvidas?

35. ReferênciasThePrinciplesof OODhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOodDesign Guidelines for Developing Class Librarieshttp://msdn.microsoft.com/en-us/library/ms229042.aspxFramework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613

36. Patrocinadores desta reunião

37. Obrigado!Ricardo Alvesricardoloboalves@gmail.comhttp://pt.linkedin.com/in/rmalves/http://twitter.com/rmalves