Keep It Local

Or: (part of) what “reasoning about your code” really means

Chris Krycho

March 2021

The C Programming Language cover by Prentice Hall

Code Complete 2 cover by Pearson

function doSomething(anArg) {
  let i, total = 0, max, min;
  max = getMax(anArg);
  min = max < 100 ? 0 : 100;

  for (i = min; i < max; i++) {
    total += i;
  }
}

function doSomething(anArg) {
  let max = getMax(anArg);
  let min = max < 100 ? 0 : 100;

  let total = 0;
  for (let i = min; i < max; i++) {
    total += i;
  }
}

function doSomething(anArg) {
  let max = getMax(anArg);
  let min = max < 100 ? 0 : 100;

  let total = getTotal(min, max);
}

function getTotal(min, max) {
  let total = 0;
  for (let i = min; i < max; i++) {
    total += i;
  }
  return total;
}

Rust!

Two fundamental rules:

Data has one owner
No shared mutable data
- infinite read access OR
- exactly one write access

Pure functional programming!

Purity: when a function—

only has access to its arguments
- no global state
- no global functions (console.log)
cannot mutate values
- not its arguments
- not other state (no access!)

Pure functional programming!

Benefits:

consistent results: same input→same output
no mutating arguments or global state
“referential transparency”

Purity: when a function—

only has access to its arguments
- no global state
- no global functions (console.log)
cannot mutate values
- not its arguments
- not other state (no access!)

“Reasoning about your code”?

“Computer Science” reasoning:

Algorithmic complexity
Space (memory) usage

“Reasoning about your code”?

“Computer Science” reasoning:

Algorithmic complexity
Space (memory) usage

“Code change” reasoning:

fixing bugs
improving performance
adding new features
changing existing feature

“Reasoning about your code”?

“Computer Science” reasoning:

Algorithmic complexity
Space (memory) usage

“Code change” reasoning:

fixing bugs
improving performance
adding new features
changing existing feature

The most important reasoning:

does it actually work?

Local Reasoning!

“Reasoning about your code”?

Local Reasoning!

“Reasoning about your code”?

Shrink the radius of thought!

Local Reasoning!

“Reasoning about your code”?

Shrink the radius of thought!

Local Reasoning!

Code Complete 2

Local Reasoning!

variable scope

comprehensibility
refactoring

Code Complete 2

Local Reasoning!

variable scope

comprehensibility
refactoring

Code Complete 2

Rust

Local Reasoning!

variable scope

comprehensibility
refactoring

control over mutability

comprehensibility
refactoring
elimination of bugs

Code Complete 2

Rust

Local Reasoning!

variable scope

comprehensibility
refactoring

control over mutability

comprehensibility
refactoring
elimination of bugs

Code Complete 2

Rust

Pure functional

Local Reasoning!

variable scope

comprehensibility
refactoring

control over mutability

comprehensibility
refactoring
elimination of bugs

Code Complete 2

Rust

Pure functional

purity & immutability → referential transparency

comprehensibility
refactoring
elimination of bugs

Local Reasoning!

“Reasoning about your code”?

Shrink the radius of thought!

Case studies

…our intellectual powers are rather geared to master static relations and… our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

“

—Edgar Djikstra, “Go To Considered Harmful”, 1968

: GOTO

Case studies

“

—Edgar Djikstra, “Go To Considered Harmful”, 1968

shorten the conceptual gap between the

static program and the dynamic process,

“

between the program

in text space

and the process

in time

: GOTO

Case studies

“

—Edgar Djikstra, “Go To Considered Harmful”, 1968

shorten the conceptual gap between the

static program and the dynamic process,

“

between the program

in text space

and the process

in time

…

: GOTO

Case studies

: GOTO

global reasoning

GOTO:

Case studies

: GOTO

local reasoning

structured programming:

Case studies

: GOTO

local reasoning

structured programming:

global reasoning

GOTO:

reasoning about control flow

Case studies

: Global Mutable State

local reasoning

explicit argument passing:

global reasoning

global mutable variables:

reasoning about data change

Case studies

: Encapsulation

reasoning about class methods

encapsulated data:

reasoning about any function

shared mutable data:

reasoning about data change

Case studies

: SOLID

reasoning about interfaces

Case studies

: SOLID

Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Case studies

: The Actor Model

Case studies

: The Actor Model

reasoning about fault tolerance

independent failure & recovery

actor-based systems:

system-wide failure & recovery

monolithic systems:

Case studies

: Types

class User {
  constructor(
    name: string,
    age: number,
    email: string,
    state: State,
  ) {}
}

Case studies

: Types

class User {
  constructor(
    name: string,
    age: number,
    email: string,
    state: State,
  ) {}
}

function describe(user: User): string {
  return `${user.name} is ${user.age} years old`;
}

Case studies

: Types

class User {
  constructor(
    name: string,
    age: number,
    email: string,
    state: State,
  ) {}
}

function describe(person: { name: string; age: number }): string {
  return `${person.name} is ${person.age} years old`;
}

Case studies

: Types

reasoning about a

describe(user: User) {...}

whole class

Case studies

: Types

describe(person: { name: string, age: number }) {...}

reasoning about

structured data

Case studies

: Types

describe(user: User) {...}

describe(person: { name: string, age: number }) {...}

reasoning about data coupling

reasoning about

structured data

reasoning about a

whole class

Case studies

: Autotracking

Case studies

: Autotracking

consumer-driven

Observable-based systems:

Classic computed properties
- computed(...)
- get and set
- two-way-binding
Observers and observer-likes
- arbitrary further “pushes”
- observer(...), didReceiveAttrs, etc.

Case studies

: Autotracking

owner-managed

Autotracking:

@tracked root state
1-way data flow
- no 2-way binding
- no observers

→ no arbitrary reactivity

→ no arbitrary “pushes”

Case studies

: Autotracking

reasoning about reactivity

consumer-driven

Observable-based systems:

owner-managed

Autotracking:

Local Reasoning!

“Reasoning about your code”?

Shrink the radius of thought!

Local Reasoning!

“Reasoning about your code”?

Shrink the radius of thought!

Keep It Local

Keep it Local (EmberConf 2021)

By Chris Krycho

Keep it Local (EmberConf 2021)

What do Steve McConnell’s variable scoping guidelines in Code Complete 2, pure functional programming, the data ownership system in Rust, classical object-oriented programming, the actor model in Erlang, and autotracking in Glimmer all have in common? Every one of them is aiming at the same key ingredient of robust, reliable software: the ability to “reason about your code.” But what does that actually mean?

Chris Krycho

A follower of Christ, a husband, and a dad. I’m a software engineer by trade; a theologian by vocation; and a writer, runner, podcaster, and composer by hobby.