Small things matter

Responsible professionals give some time to thinking and planning at the outset of a project

In software, 80% or more of what we do is quaintly called “maintenance”: the act of repair

The 5S philosophy: Sort (organize, naming is crucial), Systematize (tidiness, a piece of code should be where you expect to find it—and if not, you should re-factor to get it there), Shine (cleaning, get rid of comments and waste), Standardization (consistent coding style and practices), and Self-discipline (follow the practices, reflect on one's work, and be willing to change)

Re-do major software chunks from scratch every seven years or so

Cleanliness is next to godliness

A stitch in time saves nine. The early bird catches the worm. Don't put off until tomorrow what you can do today

You should name a variable using the same care with which you name a first-born child

Quality is the result of a million selfless acts of care

LeBlanc's law: Later equals never

Clean code's logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

Clean code has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal depen- dencies, which are explicitly defined, and pro- vides a clear and minimal API

Simple code runs all the tests, contains no duplication, and minimizes the number of entities such as classes, methods, functions, and the like

The next time you write a line of code, remember you are an author, writing for readers who will judge your effort

Leave the campground cleaner than you found it

Choosing good names takes time but saves more than it takes

Names should reveal intent

The name of a variable, function, or class, should tell you why it exists, what it does, and how it is used

We should choose a name that specifies what is being measured and the unit of that measure- ment

A class name should have a noun or noun phrase, no verbs

Methods should have verb or verb phrase names

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that

Functions should do one thing. They should do it well. They should do it only

Statements within our function should all be at the same level of abstraction

Switch statements should appear only once and create polymorphic objects

Passing a boolean into a function is a truly terrible practice. It loudly proclaims that this function does more than one thing

Don't comment bad code—rewrite it

Variables should be declared as close to their usage as possi- ble

If one function calls another, they should be vertically close, and the caller should be above the callee

We keep variables private so no one depends on them and so we keep the freedom to change their type or implementation when we. want

Hiding information is about abstractions. It exposes abstract interfaces that allow its users to manipulate the essence of. the data. without having to. know its implementation

The Three Laws of TDD

1. You may not write production code until you have written a failing unit test.

2. You may not write more of a unit test than is sufficient to fail, and not com-

piling is failing.

3. You may not write more production code than is sufficient to pass the cur- rently failing test.

One assert per test

One concept per test

Class order: public static constants, private static variables, private instance variables, public functions, private utilities

The single responsibility principle states that a class or module should have one, and only one, reason to change

It is best to postpone decisions until the last possible moment. This isn’t lazy or irresponsible; it lets us make informed choices with the best possible information

A premature decision is a decision made with suboptimal knowledge

ake a little pride in your workmanship. Spend a little time with each of your func- tions and classes. Choose better names, split large functions into smaller functions, and generally just take care of what you’ve created. Care is a precious resource

Comments should be reserved for technical notes about the code and design

A comment worth writing is worth writing well. Choose your words carefully. Use correct grammar and punctuation. Don’t ramble. Don’t state the obvious. Be brief.

When you see commented-out code, delete it

Building a project should be a single trivial operation

You should be able to run all the unit tests with just one command

Functions should have a small number of arguments

Boolean arguments loudly declare that the function does more than one thing. They are

confusing and should be eliminated

Following “The Principle of Least Surprise,”2 any function or class should implement the behaviors that another programmer could reasonably expect

Look for every boundary condition and write a test for it.

Find and eliminate duplication wherever you can

base classes should know nothing about their derivatives

Variables and function should be defined close to where they are used

If you do something a certain way, do all similar things in the same way

Keep your source files clean, well organized, and free of clutter

Function names should say what they do

A cod- ing standard should specify things like where to declare instance variables; how to name classes, methods, and variables; where to put braces; and so on

Replace magic numbers with named constants

Encapsulate conditionals

Avoid negative conditionals

Names in software are 90 percent of what make software readable