What is good code?

We often discuss the principles we use to write what we consider good code - test-driven development, object-oriented programming, SOLID, DRY, Law of Demeter - the list goes on. Sometimes it’s useful to remind ourselves of the fundamentals.

What is the code for?

Code makes an application work for users. Getting tests passing or removing duplication is useful, but the code needs to be shipped so that users can use it.

What kind of code is good?

Code needs to work. Assuming that as a prerequisite…

When code is easy to understand, we can change or extend it faster and are less likely to make a mistake in the process. Readability counts.

When code is easy to change, we can iterate on user feedback faster.

When code is fun to work with, we’re happier. Building software is our full time job. If we go home every day feeling wrung dry, something is wrong with our process.

Does good code matter?

Yes. Following certain principles can result in shipping products faster with fewer bugs and more programmer happiness.

How do our principles result in good code?

Test-driven development helps us understand code because we state the reason for each line of application code in the test. It also makes us happy by providing a clear process for working.

An automated test suite helps us change code because we have an early warning system when we break an existing component. It is fun to work with because we’re more confident and less fearful.

Removing duplication helps us read code by introducing semantic concepts and abstracting details. It also helps us change code by reducing the amount of code that needs to be touched for each change.

SOLID principles create individual components that help us understand code. SOLID helps us change code because components are reusable, swappable, and small.

How do our principles result in bad code?

Slow or brittle tests make code harder to change. We have to be careful about writing the correct tests and the correct amount of tests.

Are we writing good code right now?

Code isn’t good when it’s tested, DRY, or SOLID. Code is good when it works and we can work with it. When our teammates can understand our code quickly, respond to change, and are relaxed and happy, we’re writing good code.