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.

008c45c68ff49184796deda5faca4126?s=128

Craig Berntson

May 19, 2016
Tweet

Transcript

  1. Healthy Code, Happy Code Craig Berntson

  2. 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
  3. WHAT MAKES CODE HEALTHY AND HAPPY

  4. IMPACT OF BAD CODE -3.75% =-$2.3 Billion! Research by Parasoft

  5. WHAT IS HEALTHY CODE?  Has zero bugs  Easy

    to debug  Easy to modify  Easy to extend  Plays well with others  Is performant
  6. IF TESTS PASS IS CODE HEALTHY? MAYBE! ?

  7. INPUT OUTPUT

  8. TYPES OF TESTING  Unit  Performance  Integration 

    Regression  Load  Security  Functional  Usability  Compatibility  Compliance  User Acceptance  System
  9. 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
  10. TODAY’S AGENDA  Coding guidelines  Code reviews  Static

    code analysis
  11. CODING GUIDELINES

  12. Java Basic C++ Python Ruby PHP C# Javascript F# Erlang

    html CSS XML json
  13. Standards vs Guidelines

  14. WRITE ONCE, READ MANY  Does the job well 

    Easy to maintain  Easy to debug
  15. 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
  16. 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
  17. 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)
  18. None
  19. 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
  20. 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
  21. None
  22. None
  23. TEAM GUIDELINES Class Design Member Design Miscellaneous Design Maintainability Naming

    Performance Framework Documenation Layout
  24. RECOMMENDATIONS  Don’t create your own coding guidelines

  25. CODE REVIEWS

  26. 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
  27. A BIONIC CULTURAL HAMMER Promotes openness Raises team standards Propels

    teamwork Keeps security top of mind Shapes the culture http://www.fullstory.com
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. HOW OFTEN SHOULD YOU REVIEW CODE  Depends on the

    team  General rule: no code should be checked in / merged without a code review
  35. WALK-THROUGH: THE PULL REQUEST REVIEW Origin Remote Developer Fork Reviewers

    Developer
  36. RECOMMENDATIONS  Not all coders are created equal. It’s about

    the code, not the coder  Don’t take it personally
  37. STATIC CODE ANALYSIS

  38. 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
  39. 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
  40. 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
  41. THE BAD  Tools take too long to run 

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

    Visual Studio Analyzers  SonarQube
  43. DEMO Visual Studio Analyzers

  44. DEMO SonarQube

  45. RECOMMENDATIONS  Use VS Code Analyzers during coding  Run

    SonarQube nightly
  46. WRAP UP

  47. CODING GUIDELINES WRITE ONCE, READ MANY • Crazy lunatic DON’T

    WRITE YOUR OWN • Framework Guidelines • Team Guidelines
  48. CODE REVIEWS WHEN • Before every check-in / merge

  49. STATIC CODE ANALYSIS TESTS ACTUAL CODE • Automated

  50. CONTACT / QUESTIONS craig@craigberntson.com @craigber www.craigberntson.com blogs.msmvps.com/craigber www.dotnetcurry.com www.speakerdeck.com/craigber speakerrate.com/craigber

  51. None