Defensive programming for better future

1. Defensive programmingfor better future

2. Andnowforsomethingcompletelydifferent …

3. Defensive Programming IGNORE it, FIGHT it, MOCK it … just THINK about it! My personal view

4. “Defensive Programming” = A collection of programming techniques + A collection of stylerecommendations https://en.wikipedia.org/wiki/Defensive_programming

5. Defense in Depth

6. 1. Data Checking first line of defense 2. Future Proofing never-sleeping guards 3. Readable Code help your future self

7. Data Checking SANITIZE THE DATA!

8. Data Checking SQL parameters Buffer size checking Function result checking

9. Future Proofing SET UP GUARDS

10. invariant expect precondition maintain Design by Contract guarantee postcondition http://www.elementscompiler.com/elements/oxygene/language.aspx https://en.wikipedia.org/wiki/Design_by_contract

11. Postcondition Precondition

12. Use Descriptive Errors!

13. Check data even when IT CANNOT BE WRONG

14. “Million-to-one chances ... crop up nine times out of ten.” - Terry Pratchett

15. “Million-to-one chances ... crop up nine times out of ten.” - Terry Pratchett

16. Check data even when IT CANNOT BE WRONG Especially then!

17. unexpected values can appear … and they will! Expect the Unexpected! case enumerations be alert when dealing with constants else ifchain

18. Better Unsafe!

19. Assert vs. raise vs. Log Will unhandled unexpected value hurt customer? Will the potential problem be caught in the develop/test cycle?

20. “It is better to crash than to corrupt the data.” - me

21. “It is better to crash than to corrupt the data.” - me

22. Programmers do it with TestInsight Unit Tests https://bitbucket.org/sglienke/testinsight

23. Unit Tests • Test error paths!

24. Write readable code HELP YOUR FUTURE SELF

25. Readable code = Maintainable code

26. Readable code = Maintainable code

27. Readable code = • Good design • Good semantics • Good formatting = global strategy = implementation details = look & understand

28. “A good design is like a good house – dry and solid.” “A good design is like a good house – dry and solid.” “A good design is like a good house – dry and solid.” - me Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle Don’t Repeat Yourself

29. So … what is good code?

30. Simpler task: What is BAD code?

31. “So I took little bad with a good, It ain’t all black and white …” - Iggy Pop

32. “It ain’t that bad!” (at first glance)

34. KevlinHenney He’s DA MAN! Look him up on YouTube!

35. https://github.com/gabr42/GpDelphiCode

40. “Don’t be a smartass!”

41. “And who will support that?”

42. “Did you measure it?” - me

43. “Did you measure it?” - me

44. “But look, it is soooo beautiful!”

45. “My <insert>, does this ever end?” deity 1769 lines!

46. What to do? Turn it into a class • local methods ⇒ class methods • shared variables ⇒ class fields

47. StyleGuide

48. “We can't expect bad programmer to write good comments. We may be able to force them to use a coding style, though.” - KevlinHenney(paraphrased)

49. WhatIconsiderbeautifulthesedays

50. Coding Style Suggestions