GOTO considered harmful

1: 
2: 
3: 
4: 

10: I = 1
20: PRINT "HI"
30: I = I + 1
40: IF I <= 10 THEN GOTO 20

1: 
2: 
3: 

FOR I = 1 TO 10 DO
  PRINT "HI"
NEXT

David Parnas (1972)

How to structure large programs

Procedural approach

• Programs that run top-to-bottom
• Break program into smaller steps
• But what data is passed between?

Logical abstraction

• Identify logical components
• Hide implementation details
• How data is represented, stored, ...

Barbara Liskov (1974)

Object oriented programming

Origins of objects

• Simulating real-world systems
• World consists of objects
• Created according to a scheme

Object-oriented abstraction

• Class defines a template for object
• Multiple instances of a class
• Objects hide implementation details

Keeping program logic simple

Is there an easier way to write this?

1: 
2: 

if (isAdministrator(user) || isOwner(user)) return true;
else return false;

1: 

return isAdministrator(user) || isOwner(user);

Keeping program logic ... logical (1/2)

When does the following return a product page?

1: 
2: 
3: 
4: 
5: 
6: 
7: 

if (isAvailable(product)) {
  if (isHidden(product))
    return null;
  return getProductPage(product);
} else {
  return null;
}

Keeping program logic ... logical (2/2)

Keep the happy path branches consistent!

1: 
2: 
3: 
4: 
5: 

if (isAvailable(product)) {
  if (!isHidden(product)) {
    return getProductPage(product);
  } else return null;
} else return null;

1: 
2: 
3: 

if (!isAvailable(product)) return null;
if (isHidden(product)) return null;
return getProductPage(product);

Program logic

Encoding logic in a readable way

Use appropriate language constructs

Make sure you're not complicating things

Keep "happy path" through code clear

Do not use unnecessary nesting of logic

Writing useful comments

1: 
2: 
3: 

// Return product page if product is available
if (isAvailable(product))
  return getProductPage(product);

1: 
2: 
3: 
4: 

/**
 * Returns the product price
 */
float getProductPrice(Product product)  { /* ... */ }

Comments and structure

Making code easy to read and understand

Don't use comments if you have nothing to add

Comments should add history, motivation, context

Use consistent spacing and indentation

Keep nesting and length of functions sensible

Any product that is sufficiently big or urgent to require the effort of many minds thus encounters a peculiar difficulty: the result must be conceptually coherent to the single mind of the user and at the same time designed by many minds.

Fred Brooks (1995 [1975])

DEMO: Fun 3D
www.fun3d.net

Object-oriented model of shapes

 1: 
 2: 
 3: 
 4: 
 5: 
 6: 
 7: 
 8: 
 9: 
10: 
11: 
12: 
13: 
14: 

class Shape {
  abstract public void Render(Scene scene);
}
class Combine extends Shape {  
  public void Render(Scene scene) {
    s1.Render(scene);
    s2.Render(scene);
  }
}
class Cube extends Shape {
  public void Render(Scene scene) {
    // Render cube onto the scene
  }
}

Two ways of modelling 3D worlds

Object-oriented class hierarchy

1: 
2: 
3: 
4: 

type Shape =
  | Cube
  | Move of Shape * float * float * float
  | Combine of Shape list

Two ways of modelling 3D worlds

Object-oriented class hierarchy

• Abstract method in the base class
• Implementation in each shape
• Easy to add new shapes

Domain-specific languages

Domain Specific Languages (DSLs)

Functional and object-oriented DSLs

Functional languages
Custom operators and function composition

1: 
2: 

(Fun.cone |> Fun.color Color.red) $
(Fun.cylinder |> Fun.move (0, -1, 0))

1: 
2: 

fun.cone().withColor(color.red).
  combineWith(fun.cylinder().moveBy(0, -1, 0))

From objects and beyond

Many ways to express problems in code

Object-oriented - decompose into entities

Functional - separate data and functions

Domain specific languages - for a specific problem

Event sourcing - state as a list of events

Microservices - system as independent servers

Maintaining code quality

Code smells

Hints that code has poor quality

Long parameter list (bloaters)

Switch statement (OO abuse)

Speculative generality (dispensables)

Improving code quality

Refactoring

Is a code transformation that

Example of refactoring (1/2)

The name of the function and input argument are poor

1: 
2: 
3: 

function conv(x) {
  return x * 9 / 5 + 32;
}

1: 
2: 
3: 

function celsiusToFahrenheit(temperature) {
  return temperature * 9 / 5 + 32;
}

Example of refactoring (2/2)

What is wrong with this function?

Comment indicates it does two separate things
In reality it would be very long

1: 
2: 
3: 
4: 
5: 
6: 
7: 
8: 

function printOwing(invoice) {
  printBanner();
  var outstanding = calculateOutstanding();

  // Print details
  print("name: $" + invoice.customer);
  print("amount: $" + outstanding);
}

Example of refactoring (2/2)

Improve quality using extract function refactoring

 1: 
 2: 
 3: 
 4: 
 5: 
 6: 
 7: 
 8: 
 9: 
10: 

function printDetails(invoice, outstanding) {
  print("name: $" + invoice.customer);
  print("amount: $" + outstanding);
}

function printOwing(invoice) {
  printBanner();
  let outstanding = calculateOutstanding();
  printDetails(invoice, outstanding);
}

Note that comment becomes a function name!

Code quality

What is code quality and why it matters
More time is spent reading code than writing it
Extreme programming - simplicity & shared understanding

Understandability on small and large scale
Keeping the happy path clear
Conceptually coherent code structure

Maintaining and improving code quality
Social and technological approaches to quality
Refactoring and red-green-refactor methodology

CO886: Understandable code

What you should remember from this lecture

• The idea of a happy path
• Conceptual coherence of structure
• Refactoring and red-green-refactor

Tomas Petricek
t.petricek@kent.ac.uk | @tomaspetricek

Academic papers

• David Parnas (1972). On The Criteria To Be Used in Decomposing Systems into Modules
• Barbara Liskov, Stephen Zilles (1974). Programming with Abstract Data Types
• Alan Kay (1993). The Early History of Smalltalk

Tools, books and articles

• Domain Specific Languages: The Functional Way
• The Expression Problem