Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Healthy Code, Happy Code

Healthy Code, Happy Code

Do you do things like exercise, eat good, don't smoke, don't drink, or get regular checkups so that you stay healthy and function properly? What about your code? You may do unit test, acceptance testing, or other things to make sure the code runs properly, but do you take care of the code itself? In this session, you will learn about how to care for code in ways other than testing. We will discuss version control, coding standards, code reviews, static code analysis, and other practices that will keep your code healthy and happy.

Craig Berntson

May 19, 2016
Tweet

More Decks by Craig Berntson

Other Decks in Programming

Transcript

  1. EGO STUFF AUTHOR Continuous Integration in .NET Manning Publishing MICROSOFT

    MVP 20+ years, currently for Developer Tools .NET ARCHITECT TECHNICAL SPEAKER 20+ years as international speaker AUTHOR Software Gardening column DNC Magazine COMMUNITY INFLUENCER Grape City / ComponentOne
  2. WHAT IS HEALTHY CODE?  Has zero bugs  Easy

    to debug  Easy to modify  Easy to extend  Plays well with others  Is performant
  3. TYPES OF TESTING  Unit  Performance  Integration 

    Regression  Load  Security  Functional  Usability  Compatibility  Compliance  User Acceptance  System
  4. AN OUNCE OF PREVENTION IS WORTH A POUND OF CURE

    Stage Introduced Requirements Coding/Unit Testing Integration Beta Testing Production Requirements 1.2 8.8 14.8 15.0 18.7 Coding/Unit Testing NA 3.2 9.7 12.2 14.8 Integration NA NA 6.7 12.0 17.3 Stage Found http://www.fullstory.com
  5. WRITE ONCE, READ MANY  Does the job well 

    Easy to maintain  Easy to debug
  6. Write code as if the person who will modify it

    is a crazy lunatic that knows where you live. That person is probably you. - Unknown
  7. WHAT CAN YOU COVER INDENTATION • Use four spaces to

    indent, not tabs COMMENTS • Should appear by themselves on a line • Explain why not what DECLARATIONS • One per line
  8. WHAT CAN YOU COVER STATEMENTS • One per line WHITESPACE

    • Open curly brace on its own line • Blank lines NAMING CONVENTIONS • Pascal casing for classes and method names (GetCustomerDataset) • Camel casing for local variables (invoiceLineItems) • Field names start with an underscore • Only use well known abbreviations (Xml, Id). Do not use unknown or difficult to know (Number: num, no)
  9. FRAMEWORK DESIGN GUIDELINES Naming assemblies, namespaces, types, and members in

    class libraries. Naming Using static and abstract classes, interfaces, enumerations, structures, and other types. Type Design Designing and using properties, methods, constructors, fields, events, operators, and parameters. Member Design https://msdn.microsoft.com/en-us/library/ms229042(v=vs.110).aspx
  10. FRAMEWORK DESIGN GUIDELINES Extensibility mechanisms such as subclassing, using events,

    virtual members, and callbacks, and explains how to choose the mechanisms that best meet your framework's requirements. Extensibility Designing, throwing, and catching exceptions. Exceptions Common types such as arrays, attributes, and collections, supporting serialization, and overloading equality operators. Usage Choosing and implementing dependency properties and the dispose pattern. Common Design Patterns https://msdn.microsoft.com/en-us/library/ms229042(v=vs.110).aspx
  11. WHY CODE REVIEWS?  Identified as #1 way to ensure

    software quality (SmartBear Software survey 2016)  Ensures coding guidelines are being followed  Helps identify potential problems  Training time
  12. A BIONIC CULTURAL HAMMER Promotes openness Raises team standards Propels

    teamwork Keeps security top of mind Shapes the culture http://www.fullstory.com
  13. TYPES OF CODE REVIEWS FORMAL • Reviewers get code and

    read it before review meeting • All parties meet to go through code INFORMAL • Reviewers get code and email comments to author AUTOMATED • Software flags suspect code that doesn’t follow guidelines • Human reviewers enter additional comments PULL REQUEST • Reviewers look at code before merge
  14. THE BAD  Developer often feels it’s an attack on

    her design  It adds time to the schedule  Can become a battle of who is the better coder
  15. WHEN YOU’RE THE REVIEWER • You didn’t follow the coding

    guidelines • What was the reasoning behind your approach? Ask questions rather than make statements • Why didn’t you follow the coding guidelines Avoid the why questions • People want to be praised for what they did good, not just shown their faults Give praise
  16. WHEN YOU’RE THE REVIEWER • Coding guidelines are the foundation

    of the code review Have good coding guidelines • Keeps the review from becoming personal Stay focused on the code, not the coder • If the solution gives the correct result, it is right. It may not be maintainable or performant. There is more than one way to approach a solution
  17. WHAT TO LOOK FOR  Does the code do the

    job is was supposed to do  Does the code follow coding guidelines  Are there just enough comments (none?)  Are there unit tests for this code  Can I understand this code from just reading it  Does this code belong here or in its on method/class (SRP)  Is code being replaced commented out or removed
  18. WHEN YOU’RE THE DEVELOPER • We get attached to our

    code, but can learn from the reviewers, even when they’re less experienced Remember the code isn’t you • Items the reviewers tend to look for • Do your own review with the checklist before submitting the code for review Have a checklist of review items • Are things missing? • Do things need to be updated? • Do things need to be removed? Help maintain the coding guidelines
  19. HOW OFTEN SHOULD YOU REVIEW CODE  Depends on the

    team  General rule: no code should be checked in / merged without a code review
  20. RECOMMENDATIONS  Not all coders are created equal. It’s about

    the code, not the coder  Don’t take it personally
  21. WHAT IS STATIC CODE ANALYSIS  Testing looks at the

    output from running code for correct results  Static code analysis looks at the actual code for common issues
  22. WHAT DOES STATIC ANALYSIS LOOK FOR •Potential design flaws. •These

    coding errors typically do not affect execution of your code DESIGN •Missing or incorrect usage of information related to globalization and localization GLOBALIZATION •Incorrect casing, cross language keyword collisions, and other issues related to the names of types, members, parameters, namespaces, and assemblies NAMING •Elements in your assemblies that will degrade performance PERFORMANCE
  23. WHAT DOES STATIC ANALYSIS LOOK FOR • Programming elements that

    leave assemblies vulnerable to malicious users or code SECURITY • Potential flaws in assemblies that can affect code execution USAGE • Maintenance issues MAINTAINABILITY • Portability issues PORTABILITY • Incorrect memory and thread issues RELIABILITY
  24. THE BAD  Tools take too long to run 

    Tools can generate spurious warnings that are ignored • Turn down the analysis
  25. HOW DO YOU DO STATIC CODE ANALYSIS  FxCop 

    Visual Studio Analyzers  SonarQube
  26. CODING GUIDELINES WRITE ONCE, READ MANY • Crazy lunatic DON’T

    WRITE YOUR OWN • Framework Guidelines • Team Guidelines