BASICS OF CODE DESIGN.  Modular  Reusable  Easy to Read  Maintainable  Testable  Easy to Change  Easy to Understand THE GOAL.

Slides:



Advertisements
Similar presentations
When and How to Improve Code Performance? Ivaylo Bratoev Telerik Corporation
Advertisements

Test-First Programming. The tests should drive you to write the code, the reason you write code is to get a test to succeed, and you should only write.
Clean code. Motivation Total cost = the cost of developing + maintenance cost Maintenance cost = cost of understanding + cost of changes + cost of testing.
Written by: Dr. JJ Shepherd
1 University of Utah – School of Computing Computer Science 1021 "Programming with Style"
Internal Documentation Conventions. Kinds of comments javadoc (“doc”) comments describe the user interface: –What the classes, interfaces, fields and.
General OO Concepts and Principles CSE301 University of Sunderland Harry R. Erwin, PhD.
SOLID Object Oriented Design Craig Berntson
Software Construction and Evolution - CSSE 375 Bad Smells in Code Shawn Bohner & Steve Chenoweth.
Week 9: Methods 1.  We have written lots of code so far  It has all been inside of the main() method  What about a big program?  The main() method.
Software Engineering and Design Principles Chapter 1.
Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 4.0.
17-Jun-15 Which is better?. 2 Assume s1 and s2 are Strings: A.if (s1 == s2) {... } B.if (s1.equals(s2)) {... } ?
Designing Classes How to write classes in a way that they are easily understandable, maintainable and reusable.
Introduction to ML - Part 2 Kenny Zhu. What is next? ML has a rich set of structured values Tuples: (17, true, “stuff”) Records: {name = “george”, age.
Introduction to Refactoring Excerpted from ‘What is Refactoring?’ by William C. Wake and Refactoring: Improving the Design of Existing Code by Martin Fowler.
1 Introduction to Computers and Programming Quick Review What is a Function? A module of code that performs a specific job.
25-Jun-15 Refactoring III. General philosophy A refactoring is just a way of rearranging code Refactorings are used to solve problems If there’s no problem,
27-Jun-15 Profiling code, Timing Methods. Optimization Optimization is the process of making a program as fast (or as small) as possible Here’s what the.
30-Jun-15 Profiling. Optimization Optimization is the process of making a program as fast (or as small) as possible Here’s what the experts say about.
Guide To UNIX Using Linux Third Edition
Unit Testing Tips and Tricks: Database Interaction Louis Thomas.
General Issues in Using Variables
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
Style It's still hard to give rules, but we can give some examples. Remember: this is to some extent a matter of taste.
Ceg860 (Prasad)L6MR1 Modularity Extendibility Reusability.
Loosely Coupled Sakai Ray Davis University of California, Berkeley.
GENERAL GUIDELINES FOR CODING. RULE #1 The most important aspect of the code is the readability If your code is incorrect it can be fixed (if it is readable)
Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 3.0.
More Design. Next Tuesday First draft of architectural design –use cases –class diagrams for major classes with responsibilities –sequence diagrams for.
© 2004 Capgemini - All rights reserved SOLID - OO DESIGN PRINCIPLES Andreas Enbohm, Capgemini.
Improving the Quality of Existing Code Svetlin Nakov Telerik Corporation
Debugging Strategies from Software Carpentry. Agan's Rules Many people make debugging harder than it needs to be by: Using inadequate tools Not going.
28-Oct-15 Information Hiding A very short talk. Modularization Whenever a program is broken into two parts, there comes into being an interface between.
Designing classes How to write classes in a way that they are easily understandable, maintainable and reusable 5.0.
Design Patterns Façade, Singleton, and Factory Methods Team Good Vibrations (1)
Refactoring for Testability (or how I learned to stop worrying and love failing tests) Presented by Aaron Evans.
Incremental Design Why incremental design? Goal of incremental design Tools for incremental design  UML diagrams  Design principles  Design patterns.
Program Style Chapter 22 IB103 Week 12 (part 2). Modularity: the ability to reuse code Encapsulation: hide data access directly but may use methods (the.
Five design principles
Design and Planning Or: What’s the next thing we should do for our project?
1 COS 260 DAY 14 Tony Gauvin. 2 Agenda Questions? 6 th Mini quiz graded  Oct 29 –Chapter 6 Assignment 4 will be posted later Today –First two problems.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
Principles of Object Oriented Design
ICOM 4035 – Data Structures Dr. Manuel Rodríguez Martínez Electrical and Computer Engineering Department Lecture 2 – August 23, 2001.
Refactoring Agile Development Project. Lecture roadmap Refactoring Some issues to address when coding.
1 COS 260 DAY 12 Tony Gauvin. 2 Agenda Questions? 5 th Mini quiz –Chapter 5 40 min Assignment 3 Due Assignment 4 will be posted later (next week) –If.
Test Driven Development Introduction Issued date: 8/29/2007 Author: Nguyen Phuc Hai.
An array example: the transpose A 2-D array corresponds to a mathematical matrix: One simple matrix operation transposes the matrix.
SOLID PHP & Code Smell Wrap-Up
Beginning Software Craftsmanship Brendan Enrick Steve Smith
Design I. Properties of good design Minimize complexity Maintainable Loose coupling Extensibility Reusability High fan in Low to medium fan out Portability.
Nov String Algorithms, Q Algorithmic programming...and testing your suffix trees...
Mantas Radzevičius ifm-2/2
A bit of C programming Lecture 3 Uli Raich.
Java Course Review.
C++ coding standard suggestion… Separate reasoning from action, in every block. Hi, this talk is to suggest a rule (or guideline) to simplify C++ code.
CS1010 Discussion Group 11 Week 9 – Pointers.
Coding Design, Style, Documentation and Optimization
Objects First with Java
Refactoring III 27-Nov-18.
Which is better? 4-Dec-18.
Refactoring III 25-Dec-18.
Unit 6 Assignment 2 Chris Boardley.
DEBUGGING CS2110.
How to write good code Part 2
A (partial) blueprint for dealing with change
Which is better? 15-May-19.
Which is better? 28-May-19.
Notes on software design
Presentation transcript:

BASICS OF CODE DESIGN

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

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

 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

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

 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

 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

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

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

 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?

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

 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

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

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

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

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

 (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

 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

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

 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

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

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

 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

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

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?

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?

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?

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

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

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

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

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

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

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