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.

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)
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
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