by Robert C. Martin
https://www.goodreads.com/book/show/3735293-clean-code
(These are quotes curated and slightly edited by @agami)
You must gain the knowledge of principles, patterns, practices, and heuristics that a crafts[person] knows, and you must grind that knowledge into your fingers, eyes, and gut by working hard and practicing.
We’ve all looked at the mess we’ve just made and then have chosen to leave it for another day. We’ve all felt the relief of seeing our messy program work and deciding that a working mess is better than nothing. We’ve all said we’d go back and clean it up later. Later equals never.
Keeping your code clean is not just cost effective; it’s a matter of professional survival.
The only way to make the deadline—the only way to go fast—is to keep the code as clean as possible at all times.
The [child] scout rule: Leave the campground cleaner than you found it.
Choosing good names takes time but saves more than it takes. Change them when you find better ones. The name should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.
Avoid leaving false clues that obscure the meaning of code. Avoid words whose entrenched meanings vary from our intended meaning. Beware of using names which vary in small ways. Using inconsistent spellings is disinformation. It is very helpful if names for very similar things sort together alphabetically.
If names must be different, then they should also mean something different.
Make your names pronounceable.
Use searchable names. The length of a name should correspond to the size of its scope.
Classes and objects should have noun or noun phrase names. Avoid words like Manager, Processor, Data, or Info.
Methods should have verb or verb phrase names. Accessors, mutators, and predicates should be names for their value and prefixed with get, set, and is.
Pick one word for one abstract concept and stick with it. Avoid using the same word for two purposes.
Place names in context by enclosing them in well-named classes, functions, or namespaces. When all else fails, then prefixing the name may be necessary as a last resort.
Shorter names are generally better than longer ones, so long as they are clear. Add no more context to a name than is necessary.