<<The Art of Readable Code>>

Code Should Be Easy to Understand

1. What Makes Code "Better"
2. The Fundamental Theorem of Readability
3. Is Small Always Better
4. Does Time-Till-Understanding Conflict with Other Goals? like efficient, well-architected, easy to test
5. The hard part is it requires extra work to constantly think about whether an imaginary outsider would find your code easy to understand.

Surface-Level Improvements.

  Packing information into your names.

1. Choose specific, concrete names, not generic and abstract names.
2. Attach important details
3. Use longer names for larger scope
4. Actively scrutinize your names by asking yourself "what other meanings could someone interpret from this name"
5. Names That Can't Be Misconstrued
6. Why Do Aesthetics Matter
7. Pick a Meaningful Order, and Use it Consistently
8. Organize declarations into Blocks
9. Break Code into "Paragraphs"

  Comment

1. Knowing what to comment
2. What not to comment
3. Don't Comment Just for the Sake of Commenting
4. Don't Comment Bad Names - Fix the Names instead
5. Recording Your Thoughts
6. Include Director Commentary
7. Comment the Flaws in Your Code
8. Comment on Your Constants
9. Put Yourself in the Reader's Shoes
10. "Big Picture" Comments
11. Summary Comments
12. Final Thoughts --- Getting Over Writer's Block
13. Describe Function Behavior Precisely
14. Use Input/Output Examples that illustrate Corner Cases
15. State the intent of Your Code
16. Use Information-Dense Words

Simplifying the Loops and Logic

  Making Control Flow Easy to Follow

1. The Order of Arguments in Conditionals
2. The Order of if/else Blocks
3. Returning Early from a Function
4. Minimize Nesting

  Breaking Down Giant Expressions

1. Explaining Variables
2. Summary Variables
3. Using De Morgan's Laws
4. macro functions

  Variables and Readability

1. Eliminating Variables
2. Shrink the Scope of Your Variables
3. Prefer Write-Once Variables

Reorganizing Your Code

  Extracting Unrelated Subproblems.

1. Pure Utility/ General-Purpose Code
2. Project-Specific Functionality
3. Simplifying an Existing Interface
4. Reshaping an interface to Your Needs

  One Task at a Time

1. Brea down your giant expression into more digestible pieces
2. Code should be organized so that it's doning only one task at a time

  Turning Thoughts into Code

1. Describing Logic Clearly 
2. Knowing Your Libraries Helps

  Writing Less Code

1. The most readable code is no code at all
2. Don't Bother Implementing That Feature -- Your won't need it
3. Question and Break Down Your Requirements
4. Be Familiar with the Libraries Around You

Testing and Readability

1. Test code should be readable so that other coders are comfortable changing or adding tests
2. In general, you should pick the simplest set of inputs that completely exercise the code
3. Prefer clean and simple test values that still get the job down.
4. Creating the Minimal Test Statement
5. Implementing Custom "Minilanguages"
6. Choose Good Test Inputs
7. Naming Tests Functions
8. Multiple Tests of Functionality

Key Idea

  General about What's good code

1. Code should be easy to understand
2. Code should be written to minimize the time it would take for someone else to understand it
3. It's better to be clear and precise than to be cute
4. Consistent Style is more important than the "right" style
5. Instead of minimizing the number of lines, a better metric is to minimize the time needed for someone to understand it.
6. Beaware of "clever" nuggets of code ---- they're often confusion when others read the code later
7. Code should be organized so that it's doing only one task at a time
8. The most readable code is no code at all

  Specific about How to write good code

1. Pack information into your name
2. Actively scrutinize your names by asking yourself, "what other meaning could someone interpret from this name
3. The purpose of commenting is to help the reader known as much as the writer did
4. Don't comment on facts that can be derived quickly from the code itself
5. Comments should have a high information-to-space ratio
6. Make all your conditionals, loops, and other changes to control flow as "natural" as possible ---- written in a way that doesn't make the reader stop and reread your code!
7. Breaking down your giant expression into more digestible pieces
8. Make your variable visible by as few lines of code as possible
9. The more places a variable is manipulated, the harder it is to reason about its current value

  Test/Refactory your code

1. Looking at your code from a fresh perspective when you're making changes. Step back and look at it as a whole
2. Test should be readable so that other coders are comfortable changing or adding tests
3. In general, you should pick the simplest set of inputs that completely exercise the code
4. Prefer clean and simple test values that still get the job done