The Rules of Programming: How to Write Better Code

Cover
Copyright
Table of Contents
Preface
Girls Who Code
Conventions Used in This Book
Using Code Examples
O’Reilly Online Learning
How to Contact Us
Acknowledgments
The Story of the Rules
How to Disagree with the Rules
Rule 1: As Simple as Possible, but No Simpler
Measuring Simplicity
…But No Simpler
Sometimes It’s Better to Simplify the Problem Rather than the Solution
Simple Algorithms
Don’t Lose the Plot
One Rule to Rule Them All
Rule 2: Bugs Are Contagious
Don’t Count on Your Users
Automated Testing Can Be Tricky
Stateless Code Is Easier to Test
Audit State You Can’t Eliminate
Don’t Trust the Caller
Keeping Your Code Healthy
Rule 3: A Good Name Is the Best Documentation
Don’t Optimize for Minimal Keystrokes
Don’t Mix and Match Conventions
Don’t Shoot Yourself in the Foot
Don’t Make Me Think
Rule 4: Generalization Takes Three Examples
YAGNI
An Obvious Objection to This Strategy, in Response to Which I Double Down
It’s Actually Worse than YAGNI
This Is Not What Success Looks Like
Rule 5: The First Lesson of Optimization Is Don’t Optimize
The First Lesson of Optimization
The Second Lesson of Optimization
Putting the Second Lesson to the Test
Step 1: Measure and Attribute Processor Time
Step 2: Make Sure There’s Not a Bug
Step 3: Measure Your Data
Step 4: Plan and Prototype
Step 5: Optimize and Repeat
Applying the Five-Step Optimization Process
There Is No Third Lesson of Optimization
Interlude: In Which the Previous Chapter Is Criticized
Rule 6: Code Reviews Are Good for Three Reasons
Code Reviews Are About Sharing Knowledge
The Forbidden Code Review
The True Value of the Code Review
Code Reviews Are Inherently Social
Rule 7: Eliminate Failure Cases
A Function That Makes It Easy to Shoot Myself in the Foot
Shooting Myself in the Foot via a Ricochet
Enlisting the Compiler’s Aid to Avoid Shooting My Foot
Timing Is Everything
A More Complicated Example
Making Ordering Mistakes Impossible
Using Templates Instead of Method Chaining
Coordinated Control of State
Detecting Mistakes Is Good, but Making Them Impossible to Express Is Better
Rule 8: Code That Isn’t Running Doesn’t Work
Step 1: A Simple Beginning
Step 2: Generalizing a Common Pattern
Step 3: Adding Disguises
Step 4: The Chickens Return Home to Roost
Assigning Blame
The Limits of Testing
Rule 9: Write Collapsible Code
This Is What Failure Feels Like
The Role of Short-Term Memory
Where to Draw the Line
The Cost of Abstraction
Use Abstraction to Make Things Easier to Understand
The Role of Long-Term Memory
Common Knowledge Is Free; New Concepts Are Expensive
Putting It All Together
Rule 10: Localize Complexity
A Simple Example
Hiding Internal Details
Distributed State and Complexity
Capacitated?
Things Start to Get Foggy
Rethinking the Approach
Localized Complexity, Simple Interactions
Rule 11: Is It Twice as Good?
Three Paths Forward: Ignore, Tweak, or Refactor
Gradual Evolution Versus Continual Reinvention
A Simple Rule of Thumb
Dealing with Fuzzy Benefits
Rework Is a Good Opportunity to Fix Small Problems
Rule 12: Big Teams Need Strong Conventions
Formatting Conventions
Language Usage Conventions
Problem-Solving Conventions
Effective Teams Think Alike
Rule 13: Find the Pebble That Started the Avalanche
The Lifecycle of a Bug
Minimizing State
Dealing with Unavoidable State
Dealing with Unavoidable Delay
Rule 14: Code Comes in Four Flavors
Easy Problem, Simple Solution
Easy Problem, Three Complicated Solutions
The Cost of Complexity
The Four (But Really Three) Kinds of Programmers
Hard Problem, Somewhat Complicated Solutions That Don’t Work
Hard Problem, Somewhat Complicated Solution
Hard Problem, Simple Solution
Rule 15: Pull the Weeds
Weed Identification
How Code Gets Weedy
Rule 16: Work Backward from Your Result, Not Forward from Your Code
An Example
An Annoyance Appears
Choosing a Side of the Gap
Working Backward Instead
And Now for Something Completely Different
Working Forward and Working Backward
Rule 17: Sometimes the Bigger Problem Is Easier to Solve
Jumping to Conclusions
Finding a Clear Path Forward
Recognizing the Opportunity
Rule 18: Let Your Code Tell Its Own Story
Don’t Tell Stories That Aren’t True
Make Sure There’s a Point to the Story
Telling Good Stories
Rule 19: Rework in Parallel
Bumps in the Road
Build a Parallel System Instead
A Concrete Example
Stack Allocation in Practice
A Cloud on the Horizon
Making Stack Contexts a Little Smarter
Migrating from Old Stack Contexts to New Ones
Preparing to Migrate StackVector
Time to Migrate
Recognizing When Parallel Rework Is a Good Strategy
Rule 20: Do the Math
To Automate or Not to Automate
Look for Hard Limits
When the Math Changes
When the Math Problem Changes Back into a Word Problem
Rule 21: Sometimes You Just Need to Hammer the Nails
A New Argument
There’s Never Just One Bug
The Siren Call of Automation
Managing File Sizes
There Are No Shortcuts
Conclusion: Making the Rules Your Own
Use Your Best Judgment
Discuss Amongst Yourselves
Signing Off
Appendix A. Reading C++ for Python Programmers
Types
Formatting and Comments
Comments
Indentation and Split Lines
Boolean Operations
Lists
Increment Operators
Classes
Visibility
Declarations and Definitions
Function Overloading
Templates
Pointers and References
Appendix B. Reading C++ for JavaScript Programmers
Types
Arrays
Classes
Declarations and Definitions
Function Overloading
Templates
Pointers and References
Index
About the Author