Pruning your code

Pruning your code
COP – Session 3
20 April 2018
FR van Biljon

Gardening 101 - Pruning
 When you plant prune 2 thirds of the plant.
 If in times of drought – prune your plants, will make them use less water.
 Pruning will encourage plants to bush – more flowers.
 Pruning will yield more fruit.
 Maintenance is easier.
 Enhance overall aesthetics.
 Improve shaping of plants.
 Dead leaves are easier to spot and get rid of.
 Layout of garden becomes easier to understand.

The best investment you can make in your
garden is pruning
~Ouma Phia Venter

How does this translate to coding?
 We forget to "prune" our code -
 We are allowing our code to branch freely
 We need to remove unnecessary branching
 We are overusing if- and switch-statements
 We are using conditional statements for business logic
 Maintenance is more complex
 Code becomes more difficult to understand

What's your view?
 Most programmers will agree that properly written, well-structured, code
doesn't require the use of goto.
 Use of goto can lead to programs that are extremely difficult to comprehend
and analyse, and possibly to unspecified behavior.
 Lead to spaghetti code

Spot the GoTo:
private boolean processTransaction(Transaction trans) {
// do some session security checking
User user = trans.user;
log("security check for user " + user.name);
if ( user.loggedIn() == false)
return false;
if ( user.sessionTimeout() == true )
return false;
boolean success = true;
// process transaction here
return success;
}

The prisoner falls in love with his
chains...
~Dijkstra

Why is branching bad?
 Branches are GOTO statements at heart – telling the CPU where the next
instruction is. (IF condition THEN goto label)
 Branching is expensive on the CPU.
 It can lead to the arrow-antipattern

if
if
if
if
do something
endif
endif
endif
endif
Arrow Anti-Pattern

Why is branching bad?
 When the processor sees a branch instruction appear in its pipeline, it needs
to figure out how to continue to fill up its pipeline.
 In order to figure out what instructions come after the branch in the program
stream, it needs to know two things:
 if the branch will be taken and
 the target of the branch.
 Figuring this out is called branch prediction, and it's a challenging problem.
 If the processor guesses correctly, the program continues at full speed.
 If instead the processor guesses incorrectly, it just spent some time
computing the wrong thing.
 It now has to flush its pipeline and reload it with instructions from the correct
execution path.
 Bottom line: a big performance hit.

Benefits of pruning your code
 Easier to read
 Easier to understand
 Easier to test
 Easier to maintain
 Easier to extend
 Performance gain
 ...

Over-pruning
 Like plants – don't over prune
 Can use conditional statements for primitives e.g.:
 <, >, ==, !=
 Be pragmatic – you will still have some here and there

Challenge accepted?
Create a project without IF- or SWITCH-statements

When to get rid of IF-Statements
 State Based Behavior
 Condition chooses behavior based on type or value of object
 Repeated Conditions
 Same conditional statement appears multiple times in your code

With Conditionals:
class Node{
char operator;
double value;
Node left;
Node right;
double evaluate(){
switch(operator){
case '#':return value;
case '+':return left.evaluate() + right.evaluate();
case '*':return left.evaluate() * right.evaluate();
case ... //All other operators.
}
}
}

With Polymorphism:
abstract class Node{
abstract double evaluate();
}
class ValueNode extends Node{
double value;
double evaluate(){
return value;
}
}

With Polymorphism:
abstract class OpNode extends Node{
Node left;
Node right;
abstract double evaluate();
}
class AdditionNode extends OpNode{
double evaluate(){
return left.evaluate() + right.evaluate();
}
}
class MultiplicationNode extends OpNode{
double evaluate(){
return left.evaluate() * right.evaluate();
}
}

With Switch-statement:
class Bird {
//...
double getSpeed() {
switch (type) {
case EUROPEAN:
return getBaseSpeed();
case AFRICAN:
return getBaseSpeed() - getLoadFactor() * numberOfCoconuts;
case NORWEGIAN_BLUE:
return (isNailed) ? 0 : getBaseSpeed(voltage);
}
throw new RuntimeException("Should be unreachable");
}
}

With Polymorphism:
abstract class Bird {
//...
abstract double getSpeed();
}

With Polymorphism:
class European extends Bird {
double getSpeed() {
return getBaseSpeed();
}
}
class African extends Bird {
double getSpeed() {
return getBaseSpeed() - getLoadFactor() * numberOfCoconuts;
}
}
class NorwegianBlue extends Bird {
double getSpeed() {
return (isNailed) ? 0 : getBaseSpeed(voltage);
}
}
// Somewhere in client code
speed = bird.getSpeed();

Take note:
 Polymorphism is often better
 Can add new behavior without having source code.
 You don't always have to recompile the whole code base.
 Each concern is separated (improves testability/readability/easier to understand)

Example:
class Update(){
execute(){
if(FLAG_i18n_ENABLED){
//DO A
}else{
//DO B
}
}
}

Example Extended:
class Update(){
execute(){
//DO A
}else{
//DO B
}
}
render(){
//render A
}else{
//render B
}
}
}

Example Extended:
class Update(){
execute(){
//DO A
}else{
//DO B
}
}
render(){
//render A
}else{
//render B
}
}
}
void testExecuteDoA{
FLAG_i18n_ENABLED = true;
Update u = new Update();
e.execute();
assertX();
}
void testExecuteDoB{
FLAG_i18n_ENABLED = false;
Update u = new Update();
e.execute();
assertX();
}
How do we test this?

How to solve this?
 Replace conditionals with a polymorphic design
 Behavior is dictated by the type of an object
 Move each leg of the conditional to an overriding method or subclass. Make
original methods abstract.

Example Extended:
abstract class Update{//..}
class I18NUpdate extends Update{
execute(){
// Do A
}
render(){
// Do A
}
}
class NonI18NUpdate extends Update{
execute(){
// Do B
}
render(){
// Do B
}
}

Testing simplified:
void testExecuteDoA{
Update u = new I18NUpdate();
u.execute();
assertX();
}
void testExecuteDoB{
Update u = new NonI18NUpdate();
u.execute();
assertX();
}

What happened to the ifs?
 In this case an if is not easily avoidable.
 We still need to know which version to instantiate?
 We can move it from being inline.
 Can we use dependency injection to solve this?
class Consumer{
Consumer(Update u){...}
}

Consider your app in two piles
 Responsible for:
 Business logic
 Domain logic
 Abstractions
Pile of Objects Pile of Construction
 Responsible for:
 Building objects
 Building Object Graph
 How components work together to
solve a custom problem

Testing simplified:
class Factory{
Consumer build(){
Update u = FLAG_i18n_ENABLED ? new I18NUpdate() : new NonI18NUpdate();
return u;
}
}

What are the benefits?
 Conditionals are moved to one place
 Conditional duplication was removed
 Separated the concerns
 Removed the global dependency
 Opened up our application for extension

Other examples:
Let's count how many integers are odd in this array:
const arrayOfIntegers = [1, 4, 5, 9, 0, -1, 5];
let counter = 0;
arrayOfIntegers.forEach((integer) => {
const remainder = Math.abs(integer % 2);
if (remainder === 1) {
counter++;
}
});
console.log(counter);

Other examples:
Let's count how many integers are odd in this array:
const arrayOfIntegers = [1, 4, 5, 9, 0, -1, 5];
let counter = 0;
arrayOfIntegers.forEach((integer) => {
const remainder = Math.abs(integer % 2);
counter += remainder;
});
console.log(counter);
Note: the examples above use forEach and mutate the counter variable. It is cleaner and
safer to use immutable methods instead. This if-less solution would only work for
integers while the if-based solution has the advantage of handling any number
including decimal ones

Other examples:
Write a function that takes a date object argument (like new Date()) and
returns the string “weekend” or “weekday”.
const weekendOrWeekday = (inputDate) => {
const day = inputDate.getDay();
if (day === 0 || day === 6) {
return 'weekend';
}
return 'weekday';
};
console.log(weekendOrWeekday(new Date()));

Other examples:
Write a function that takes a date object argument (like new Date()) and
returns the string “weekend” or “weekday”.
weekendOrWeekday.labels = {
0: 'weekend',
6: 'weekend',
default: 'weekday'
};
const weekendOrWeekday = (inputDate) => {
const day = inputDate.getDay();
return weekendOrWeekday.labels[day]|| weekendOrWeekday.labels['default']
;
};
console.log(weekendOrWeekday(new Date()));

Pruning your code

More Related Content

What's hot (13)

Similar to Pruning your code (20)

Recently uploaded (20)

Pruning your code