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