programming styles

Neil Ernst

2025-11-05

Programming Styles

Derived from T. Latoza, SWE 621, GMU

Learning Objectives

  • understand some examples of different programming styles
  • compare and contrast the advantages of the different constraints
  • read code in Python that implements the styles
  • differentiate between architectural style, design pattern, and programming style
  • draw connections between styles and refactoring

Programming Style

A set of constraints on how code is written which help achieve specific requirements or quality attributes.

A style is creation under constraints.

Programming modalities:

  1. Write code to produce machine instructions via compiler/interpreter/linker
  2. Write code to help humans understand what the code should be doing.

In this sense modality 2 is like the HCI of software: how humans interact with the computer.

Programming Style:

Describe alternative ways in which code might be written

  • make it object-oriented (why)
  • lazily load data from input source (why)
  • give each element a separate thread (why)
  • make it functional (why)

Different Abstractions Levels

All three embody best/good practices to solving common problems and constraints.

Approach Breadth Abstraction Sources
Arch Tactic System/sub-system Expressed in natural language/models Textbook;
Design Pat. Module Diagram GoF book; OO
Progr Style File Code Languages

Book: Exercises In Programming Style

Presentation is centred around an example problem.

Each program offers the same baseline behavior (sometimes adding an additional feature)

Can directly compare and contrast how the same problem is solved each style

Directly illustrates the diversity of ways of programming

Book

Some are related to programming language features (e.g., OO, functional, reflection)

But many modern languages support a range of language features that support a diversity of styles

E.g. all examples written in Python

Working Problem: Term Frequency

  • Given a text file, print the 25 most frequent words and corresponding frequencies
  • Sort from most frequent to least frequent
  • Normalize for capitalization and ignore “stop” words (e.g., the, for, …)

Example

Input

Tigers live mostly in India 
Wild lions live mostly in Africa

Output

live - 2 
mostly - 2 
africa - 1 
india - 1 
lions - 1 
tigers - 1 
wild - 1

Variations

  1. How long the program is (LOC)
  2. How long the explanation is (complexity)
  3. How Python might have to be contorted to make the style work
  4. How such a style might exist as an Architecture Tactic or Design Pattern or language element.

Announcements

No class or labs next week

No CI requirement

Examples

Chapter 4, Monolithic

  • one piece of code, no abstractions, no library calls
  • “old school” (Basic) and GoTo
10 LET N=10
20 FOR I=1 TO N
30 PRINT "Hello, World!"
40 NEXT I

Compare with Monolithic architecture

Chapter 12 Letterbox

  • a variant of OO (ch 11)
  • common approach in Smalltalk and Objective C (iOS)
  • message dispatch is the way objects interact with one another
    • not method invocation (rectangle.getArea())
  • prefigures concurrency primitives and Actor models
  • why do we like (in a design sense) dispatching messages and letting the object pivot on message type?

Exercise

With your group, pick one of the example styles (ch 7 or later).

Post your choice on Teams so others don’t also do it.

You will learn the style, adapt it for Typescript, and present it to class.

Do not use AI to understand the style - spend the next 10 minutes doing that with your own human brain.

You may use AI to help with the translation into Typescript.

This is part of the Refactoring exercise coming up next week.

Next Class

Your presentation should include

  • summary of the style and constraints
  • walkthru of the Python version
  • demo of the Typescript version
  • your group’s quick thoughts on that style: why you picked it, problems you faced.
  • send me your group’s notes Wednesday

Other styles

Chapter 5, Cookbook

  • break program into chunks
  • use globals to share state
  • procedures each affect state and depend on state (idempotence)
  • early programs using structured programming
  • systems: common pattern with database access

Chapter 7, Infinite Mirror

  • aka induction
  • tail recursion optimization (constraints of Python)
  • maps naturally to many mathematical problems
  • where is this found in Systems?

Chapter 13 Abstract Things

  • depend on an abstraction not the thing itself
  • define abstract things to use, then implementations thereof
  • I<Name> syntax defines a Thing
  • Strongly typed
  • When do we need the abstractions vs the concrete classes?
  • Very common in Design Patterns and Tactics

Chapter 16, Introspective and 17, Reflective

  • Programs which “know themselves”
  • in Introspection, examine who the Caller is and restrict access
  • adds another layer of indirection and what you see may not be what is happening (cf operator overloading)
  • in Reflective, define function as a string and then call exec
  • useful when we expect to add new things to our code (i.e. dynamically)

Chapter 18, Aspects

  • leverage reflection to add functionality that cross-cuts primary functionality
  • (profiling)
  • a weaver uses reflection to add the new aspect
  • similar to Python’s decorator but without attaching directly to the function (which may be far away from the aspect code)

Chapter 25, Persistent Tables

  • constraint is to persist data beyond just this use
  • do not optimize data storage for a single use (relational)
  • very common in the shared-data style; this programming style is essentially an architecture style in one file.

Chapter 27, Lazy Rivers

  • we don’t know how much data we will be reading; or, we are reading from input larger than memory
  • make use of Python’s yield to return to where the fn left off
  • contrast with a Pipeline where data is passed entirely
  • Systems: quite common in event-based systems and the Command Query Responsibility Segregation style

Chapter 28, Actors

  • program elements are essentially inboxes that send/receive messages
  • actors have independent threads of execution
  • Python lacks native support - hence the extra code prefixed _
  • Systems: big part of distributed systems eg Erlang or Elixir which is built around Actors

Summary

  • Many choices about how to implement a solution
  • Programming styles offer a vocabulary for talking about alternative implementations
  • Makes explicit the constraints which lead to a specific style of programming
  • Can consider explicitly the consequences of following these constraints
  • Many styles map to equivalent tactics or patterns over more modules