From S.T.U.P.I.D.

to S.O.L.I.D.
Language-Independent Best Practices

How to code like a S.T.U.P.I.D.

Really, we need to rearrange this a little bit

S T U P I D

How to code like a S.T.U.P.I.D.

Really, we need to rearrange this a little bit

S T P I D

How to code like a S.T.U.P.I.D.

Untestability (thematically connects all of the others)
Singleton
Tight Coupling
Premature Optimization
Indescriptive Naming
Duplication

Singleton

Introduces global state

Hides dependencies

Tight Coupling

When a change in one part of your code

requires updates elsewhere

Code becomes much more difficult to reuse

Premature Optimization
We should forget about small
efficiencies . . . premature
optimization is the root of all
evil.
-Donald Knuth
Im a big fan of good enough
for now. Often good enough for
now ends up being good
enough for shipping the thing.
-Jonathan Blow

Indescriptive Naming

For example:

Naming your variables v instead of velocity

Naming your function calculate() instead of

reticulateSplines()

Duplication

Affectionately referred to as copy / pasta

How to write S.O.L.I.D. code

There might be some terms here you havent seen before

S O L I D

How to write S.O.L.I.D. code

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

Single Responsibility
Principle

Any given class should have a single reason to

change

Not quite the same as only do one thing

I like to articulate this idea as separation of

concerns

Open / Closed Principle

Open for extension, closed for modification

A class that can have its behavior extended

without modifying the original code

Once completed, the only modifications to a

class should be to fix bugs

Liskov Substitution Principle

Any object should be able to replace an

instance of its own superclass

i.e. your Car class should not cause erroneous

behavior when inserted into a list of Vehicles

Interface Segregation
Principle

Many client-specific interfaces are better than

one

Avoid making someone implement or inherit from

a monolithic interface

Dependency Inversion
Principle

Abstractions should not depend on details,

details should depend on abstractions.

wat?

Dependency Inversion
Principle

The last time you wanted to turn on a lamp

Did you have to cut a hole in the wall and solder
the lamp directly into the wiring of the house?
The electrical outlet provides a standard
interface for such an occasion.

Additionally, no one expects to only be able to

plug in a lamp, to an outlet. We expect to plug in
lamps, computers, televisions

Dependency Inversion
Principle

Use interfaces instead of tightly coupling

Classes that use the interface only need to know

about the interface, not other classes

S.O.L.I.D.D. code?

Im going to add one more D

Law of Demeter

Only talk to your immediate friends

Avoid calling object.property.property

The Wizard Book

a.k.a. Structure and Interpretation of Computer Programs

Programs should be written

for people to read, and only
incidentally for machines to
execute.

Wise Words from Apple

John McCall (Swift compiler engineer) on overloading operators:

The key to doing this well is to make it

feel natural. Think about how someone
coming along and reading your code later is
going to understand it intuitively. Think about
what your syntax suggests about what it's
actually doing.

Further Reading

Original blog posts:

http://williamdurand.fr/2013/07/30/from-stupid-tosolid-code/

http://www.codemag.com/article/1001061

How to Program Independent Games presentation

by Jonathan Blow

Structure and Interpretation of Computer Programs,

MIT Press