1. BASICS OF CODE DESIGN

2.  Modular  Reusable  Easy to Read  Maintainable  Testable  Easy to Change  Easy to Understand THE GOAL

3.  S = Singletons  T  U  P  I  D DON’T WRITE STUPID CODE

4.  The anti-pattern  Means Global State  Hard-coded dependencies  “Spooky Action at a Distance”  The functionality of my method changed,  … but my function’s code did not! SINGLETONS

5.  S = Singletons  T = Tight Coupling  U  P  I  D DON’T WRITE STUPID CODE

6.  2 pieces of code are intertwined  Effects:  Code reuse  Code modification  Fixing Bugs  Testing  Each piece of code should have only 1 responsibility TIGHT COUPLING

7.  checkForm:  make sure 1 st 3 characters are digits  make sure 4 th is a dash  make sure characters 5-6 are digits  make sure 7 th is a dash  make sure characters 8-11 are digits  make sure the SSN created appears in the registry table  make sure the SSN created matches the name in the name database EXAMPLE

8.  Previous code couples the SSN format, the registry table, and the name database  Separate functionality to de-couple COUPLING

9.  S = Singletons  T = Tight Coupling  U = Untestable Code  P  I  D DON’T WRITE STUPID CODE

10.  Globals  Tight coupling  Doing too much! Long methods and Complex code  If it isn’t (easily) testable, it will not be maintainable. WHAT MAKES CODE UNTESTABLE?

11.  S = Singletons  T = Tight Coupling  U = Untestable Code  P = Premature Optimization  I  D DON’T WRITE STUPID CODE

12.  Code Optimization is at odds with Code Design  Three “rules” of optimization:  Don’t.  Don’t yet.  If you are an optimization expert, then okay, but only if you run profiles first.  "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." -- W.A. Wulf  “Premature optimization is the root of all evil” -- Don Knuth OPTIMIZATION

13.  S = Singletons  T = Tight Coupling  U = Untestable Code  P = Premature Optimization  I = Indescriptive Naming  D DON’T WRITE STUPID CODE

14.  Use naming conventions  Be consistent  It’s not easy  Favor clarity over brevity  Code is read far more often than it is written NAMING

15.  S = Singletons  T = Tight Coupling  U = Untestable Code  P = Premature Optimization  I = Indescriptive Naming  D = Duplication DON’T WRITE STUPID CODE

16.  DRY = Don’t Repeat Yourself!  Duplication makes code hard to reuse, debug, and change DUPLICATION

17.  (Largely for object-oriented code, but still…)  S = Single Responsibility Principle  O = Open/Closed Principle  L = Liskov Substitution Principle  I = Interface Substitution Principle  D = Dependency Inversion Principle SOLID CODE

18.  Code should be open to extension, closed to modification  It should be easy to add functionality  Adding functionality should minimize changing existing code OPEN/CLOSED

19.  Symptoms that are easily identified in code that point to a violation of the principles  Not bugs  Sign that REFACTORING is needed CODE SMELLS

20.  Duplicated code  Large pieces of code  Too many parameters  Freeloader – a piece of code that does too little  Magic Numbers  Cyclomatic Complexity – loops within loops  Long if statements  Too few comments/ too many comments  Any piece of code that looks one way but functions another (ints used as booleans, for example) CODE SMELLS

21.  Remember this? typedef enum {START, PLAY, FINISH} game_state_t; game_state_t gameState; void (*stateFunction[])() = { startState, playState, finishState }; C FIXES

22. typedef enum {START, PLAY, FINISH} game_state_t; game_state_t gameState; They are just ints: for(game_state_t x = START; x <= FINISH; x++) int x = array[gameState]; ENUMERATED TYPES

23.  Consider function: void foo(int x){ }  Pointer to function: void (*ptr) (int); // Means ptr is a pointer to a // function that takes an int // and returns void  Initialize it: ptr = &foo;  Call it: ptr(3); // Calls foo(3); Can also write (*ptr)(3); POINTERS TO FUNCTIONS

24. void (*stateFunction[])() = { startState, playState, finishState }; void loop(){ stateFunction[gameState](); } ARRAYS OF FUNCTION POINTERS

25. void setBottom(int pin){ if (pin == SHORTS){ digitalWrite(SHORTS, HIGH); digitalWrite(PANTS, LOW); } if (pin == PANTS){ digitalWrite(SHORTS, LOW); digitalWrite(PANTS, HIGH); } EXAMPLE 1: WHAT’S THE CODE SMELL?

26. void setBottom(int pin){ if (pin == SHORTS){ digitalWrite(SHORTS, HIGH); digitalWrite(PANTS, LOW); } if (pin == PANTS){ digitalWrite(SHORTS, LOW); digitalWrite(PANTS, HIGH); } EXAMPLE 1: WHY IS IT A PROBLEM?

27. void setBottom(int pin){ if (pin == SHORTS){ digitalWrite(SHORTS, HIGH); digitalWrite(PANTS, LOW); } if (pin == PANTS){ digitalWrite(SHORTS, LOW); digitalWrite(PANTS, HIGH); } EXAMPLE 1: WHAT’S A FIX?

28. void setState(String condition){ if (condition == “cloud”){ weatherState = CLOUDY; } else if (condition == “sun”){ weatherState = SUNNY; } … } EXAMPLE 2

29.  String myScoreMyWin = “0”;  String myScoreOtherWin = “1”;  String myScoreTie = “2”;  … EXAMPLE 3

30. int convertWasher(String command){ int num = WASHERTIME – washer1Timer; wLeft = convertToMins(num); return 1; } int convertDryer(String command){ int num = DRYERTIME – dryer1Timer; dLeft = convertToMins(num); return 1; } EXAMPLE 4

31. int update(String sTemp){ int temp = atoi(sTemp); if(temp > highThreshold){ digitalWrite(tshirt_light, LOW); digitalWrite(cold_light, LOW); digitalWrite(hot_light, HIGH); } else if (temp - lowThreshold){ digitalWrite(tshirt_light, HIGH); digitalWrite(cold_light, LOW); digitalWrite(hot_light, LOW); } else… EXAMPLE 5

32. void myWeather(String data){ if (data == “Rain” || data == “Light Rain” || data == “Showers” || data == “AM Showers || data == “PM Showers” || data == “Thunderstorms” || data == “Scattered Thunderstorms”){ digitalWrite(ledBlue, 255); } EXAMPLE 6

33. // this is called by IFTTT so can’t take more parameters. int teamOneInPlay(String param) if(param.equals(“in”)){ digitalWrite(LEDPIN1, HIGH); } else digitalWrite(LEDPIN1, LOW); } int teamTwoInPlay(String param) if(param.equals(“in”)){ digitalWrite(LEDPIN2, HIGH); } else digitalWrite(LEDPIN2, LOW); } EXAMPLE 6

34. tone(OUT,B6); digitalWrite(LED, HIGH); delay(400); noTone(OUT); digitalWrite(LED, LOW); delay(100); tone(OUT,Gsharp6); digitalWrite(LED, HIGH); delay(150); noTone(OUT); digitalWrite(LED, LOW); delay(5); etc… EXAMPLE 7