TwosWrite things down

Clean Code by Robert Martin

Clean Code by Robert Martin

by Parker · 64 things on Twos

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 measurement
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