Clean Code for East Bay .NET User Group


Published on

Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs. Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code.

At this talk, you will be presented design patterns and best practices which will make you write better and more easily maintainable code. You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2010. However, the demonstrated patterns and practice can be applied to every other programming language too.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • A object or any type implementing subtype or a certain interface can be replaced with another object implementing the same base type or interface.
  • Clean Code for East Bay .NET User Group

    1. 1. East Bay .NET User Group Clean CodeWhy Clean Code matters Berkeley, February 9nd 2012
    2. 2. Theo Jungeblut• Senior Software Developer at AppDynamics in San Francisco• Has been designing and implementing .NET based applications , components and frameworks for more than 8 years• Previously worked in healthcare and factory automation with focus on component based software and framework development for 3 ½ years• Degree in Software Engineering and Network Communications
    3. 3. Overview• Why Clean Code• Tools • Resharper • FxCop, StyleCop & StyleCop plugin for Resharper • GhostDoc & Spell Checker • Code Contracts, Pex & Moles• Clean Code Developer Initiative• Principles and Practices• Code Comparison• Q&A
    4. 4. Does writing Clean Codemake us more efficient?
    5. 5. What is Clean Code?
    6. 6. Clean Code is maintainable Source code must be: • readable & well structured • extensible • testable
    7. 7. Software Engineering vs.Craftsmanship
    8. 8. The “Must Read”-Book(s) by Robert C MartinA Handbook of AgileSoftwareCraftsmanship“Even bad code canfunction. But if codeisn’t clean, it can bring adevelopmentorganization to itsknees.”
    9. 9. Code Maintainability * Principles Patterns Containers Why? How? What? Extensibility Clean Code Tool reuse* from: Mark Seemann’s “Dependency Injection in .NET” presentation Bay.NET 05/2011
    10. 10. .NET Tools and their ImpactTool name Positive Impact Negative ImpactResharper compiling ++++ VS responsiveness --FxCop code quality ++ compiling time -StyleCop code consistency +++ compiling time -StyleCop plugin compiling time +++ VS responsiveness --for ResharperGhost Doc automated docs potentially worse docSpell Checker fewer spelling errors ++ performance --Code Contracts testability, quality ++ compiling time --Pex & Moles automated test ++ compiling time --
    11. 11. Resharper“The single most impacting development addition to Visual Studio” Features: – Code Analysis – Quick Fixes – Code Templates – Code Generation – Code Cleanup – Many, many more…
    12. 12. FxCop / Static Code Analysis Code Analysis: – Correctness – Library design – Internationalization and localization – Naming conventions – Performance – Security
    13. 13. Style Cop with R# Integration Code Consistency & Readability: – Automated check of C# coding standard – Enforceable at check-in with TFS check-in Policy – Full Integration in Resharper with Style Cop plugin: – Code Analysis – Quick Fixes – Code Cleanup
    14. 14. Ghost Doc• Save keystrokes and time• Simplify documenting your code• Benefit of the base class documentation
    15. 15. Spell Checker • Spelll chicking for literals and comments in VS
    16. 16. • Design-by-Contract programming• Improved testability• Static verification• API documentation integration with Sandcastle
    17. 17. Microsoft Pex & Moles• Pex automatically generates test suites with high code coverage.• Moles allows to replace any .NET method with a delegate.
    18. 18. Graphic by Michael Hönnig
    19. 19. Clean Code Developer – 1st Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.deGraphic by Michael Hönnig
    20. 20. Keep it simple, stupid (KISS)
    21. 21. KISS-Principle – “Keep It Simple Stupid” by Kelly Johnson
    22. 22. The Power of Simplicity Graphic by Nathan Sawaya courtesy of brickartist.comGraphic by Nathan Sawaya courtesy of
    23. 23. Graphic by Nathan Sawaya courtesy of
    24. 24. Don’t repeat yourself (DRY)
    25. 25. Don’t repeat yourself (DRY) by Andy Hunt and Dave Thomas in their book “The Pragmatic Programmer”// Code Copy and Paste Method // DRY Methodpublic Class Person public Class Person { { public string FirstName { get; set;} public string FirstName { get; set;} public string LastName { get; set;} public string LastName { get; set;} public Person(Person person) public Person(Person person) { { this.FirstName = string.IsNullOrEmpty(person.FirstName) this.FirstName = person.FirstName.CloneSecured(); ? string.Empty : (string) person.FirstName.Clone(); this.LastName = person.LastName.CloneSecured(); } this.LastName = string.IsNullOrEmpty(person.LastName) ? string.Empty : (string) person.LastName.Clone(); public object Clone() } { return new Person(this); public object Clone() } { } return new Person(this); }} public static class StringExtension { public static string CloneSecured(this string original) { return string.IsNullOrEmpty(original) ? string.Empty : (string)original.Clone(); } }
    26. 26. Clean Code Developer – 2nd Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.deGraphic by Michael Hönnig
    27. 27. Separation of Concerns (SoC) Single Responsibility Principle (SRP)
    28. 28. The Product
    29. 29. Component / Service
    30. 30. Class, Struct, Enum etc.
    31. 31. Separation of Concerns (SoC) probably by Edsger W. Dijkstra in 1974• “In computerscience, separation of concerns(SoC) is the process of separatinga computer program into distinctfeatures that overlap infunctionality as little as possible.•A concern is any piece ofinterest or focus in a program.Typically, concerns aresynonymous with features orbehaviors. “ on_of_Concerns
    32. 32. Single Responsibility Principle (SRP) by Robert C Martin“Every object should have a single responsibility, and thatresponsibility should be entirely encapsulated by the class.” class Logger : ILogger{ public Logger(ILoggingSink loggingSink) {} public void Log(string message) {}}
    33. 33. Source Code Conventions
    34. 34. “Clean Code” –Guidelines * by Robert C. Martin• use meaningful, pronounceable, searchable Names• write code readable top to bottom (Journal Style)• prefer Exceptions over returning Error Codes• explain yourself in Code• avoid redundant, misleading and noise Comments• don’t use a Comment when you can use a Method or Variable• Avoid commented-out code and Javadocs in NonPublic Code• Don’t Return or Pass Null• Keep Tests Clean and have only One Assert per Test• Classes and Methods should be small• Limit the scope of Data and use Copies of Data• Builds and Tests should only require 1 Step * Chapter extract: Robert C. Martin –” Clean Code”, Parson Education, Inc. 2008
    35. 35. The “Must Read”-Book(s) by Robert C MartinA Handbook of AgileSoftwareCraftsmanship“Even bad code canfunction. But if codeisn’t clean, it can bring adevelopmentorganization to itsknees.”
    36. 36. TheKrzysztof Cwalina,Read”-Book(s) by “Must Brad AbramsFramework DesignGuidelines“teachesdevelopers thebest practices fordesigning reusablelibraries for theMicrosoft .NETFramework.”
    37. 37. Clean Code Developer – 3rd Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.deGraphic by Michael Hönnig
    38. 38. Information Hiding Principle (IHP)
    39. 39. Information Hiding Principle (IHP) by David Parnas (1972)“.. information hiding is the principle ofsegregation of the design decisions on acomputer program that are most likely tochange, ..”
    40. 40. Liskov Substitution Principle (LSP)
    41. 41. Liskov Substitution Principle (LSP)by Barbara Liskov, Jannette Wing (1994)“Liskov’s notion of a behavioral subtypedefines a notion of substitutability formutable objects”
    42. 42. Interfaces / Contracts• Decouple Usage and Implementation through introduction of a contract• Allows to replace implementation without changing the consumerpublic interface ILogger public class Logger : ILogger{ { void Log(string message); public Logger(ILoggingSink loggingSink)} {} public void Log(string message) {} }
    43. 43. Dependency Inversion Principle (DIP)
    44. 44. Dependency Inversion Principle (DIP) by Robert C. Martin• “High-level modules should not depend on low-level modules. Both should depend on abstractions.• Abstractions should not depend upon details. Details should depend upon abstractions.”
    45. 45. Clean Code Developer – 4th Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.deGraphic by Michael Hönnig
    46. 46. Open Closed Principle (OCP)
    47. 47. Open/Closed Principle (OCP)by Bertrand Meyer (1988)An implementation is open for extensionbut closed for modification
    48. 48. Law of Demeter (LoD)
    49. 49. Law of Demeter (LoD) Northeastern University (1987)“• Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.• Each unit should only talk to its friends; don’t talk to strangers• Only talk to your immediate friends.”
    50. 50. S Single Responsibility Principle O Open/Closed Principle L Liskov Substitution Principle I Interface Segregation Principle D Dependency Inversion PrincipleRobert C Martin:
    51. 51. Clean Code Developer – 5th Iteration by Ralf Westphal & Stefan Lieser – http://www.clean-code-developer.deGraphic by Michael Hönnig
    52. 52. Component-Oriented Programming (CoP)
    53. 53. Different Ways of doing something similar and-sam-action-figures/
    54. 54. Why Reusable Components rock
    55. 55. Inversion of Control (IoC)
    56. 56. Inversion of Control (IoC)by Martin Fowler 1994 Logger logger = new Logger();
    57. 57. Inversion of Control (IoC)by Martin Fowler 1994 Logger logger = new Logger();
    58. 58. Inversion of Control –Constructor Injection public class ContactManager : IContactManager { public ContactManager(ILogger logger, IContactPersistence contactPersistence) { this.logger = logger; if (logger == null) { throw new ArgumentNullException("logger"); } … } }
    59. 59. Dependency Injection Container & more• Typically support all types of Inversion of Control mechanisms • Constructor Injection • Property (Setter) Injection • Interface Injection • Service Locator•.NET based DI-Container • Unity • Castle Windsor • StructureMap Related Technology: • Spring.NET • Managed Extensibility Framework (MEF) • Autofac • Windows Communication Foundation (WCF) • Puzzle.Nfactory • Ninject • PicoContainer.NET • and more
    60. 60. The “Must Read”-Book(s) by Mark SeemannDependencyInjection is a set ofsoftware designprinciples andpatterns thatenable us todevelop looselycoupled code.
    61. 61. Summary Clean CodeMaintainability is achieved through:• Readability (Coding Guidelines)• Simplification and Specialization (KISS, SoC, SRP, OCP, )• Decoupling (LSP, DIP, IHP, Contracts, LoD, CoP, IoC or SOA)• Avoiding Code Bloat (DRY, YAGNI)• Quality through Testability (all of them!)
    62. 62. Q&A Downloads, Feedback & Comments: by Nathan Sawaya courtesy of
    63. 63. References…
    64. 64. … more ReferencesResharper / Code Analysis Contracts & Mole Lego (trademarked in capitals as LEGO)
    65. 65. Please fill out thefeedback, and…… thanks for you attention! And visit and support the User Group
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.