The Rules of Programming

Spis treści książki

• Preface
  • Girls Who Code
  • Conventions Used in This Book
  • Using Code Examples
  • OReilly Online Learning
  • How to Contact Us
  • Acknowledgments
• The Story of the Rules
• How to Disagree with the Rules
• 1. As Simple as Possible, but No Simpler
  • Measuring Simplicity
  • But No Simpler
  • Sometimes Its Better to Simplify the Problem Rather than the Solution
  • Simple Algorithms
  • Dont Lose the Plot
  • One Rule to Rule Them All
• 2. Bugs Are Contagious
  • Dont Count on Your Users
  • Automated Testing Can Be Tricky
  • Stateless Code Is Easier to Test
  • Audit State You Cant Eliminate
  • Dont Trust the Caller
  • Keeping Your Code Healthy
• 3. A Good Name Is the Best Documentation
  • Dont Optimize for Minimal Keystrokes
  • Dont Mix and Match Conventions
  • Dont Shoot Yourself in the Foot
  • Dont Make Me Think
• 4. Generalization Takes Three Examples
  • YAGNI
  • An Obvious Objection to This Strategy, in Response to Which I Double Down
  • Its Actually Worse than YAGNI
  • This Is Not What Success Looks Like
• 5. The First Lesson of Optimization Is Dont 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 Theres 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
• 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
• 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 Compilers 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
• 8. Code That Isnt Running Doesnt 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
• 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
• 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
• 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
• 12. Big Teams Need Strong Conventions
  • Formatting Conventions
  • Language Usage Conventions
  • Problem-Solving Conventions
  • Effective Teams Think Alike
• 13. Find the Pebble That Started the Avalanche
  • The Lifecycle of a Bug
  • Minimizing State
  • Dealing with Unavoidable State
  • Dealing with Unavoidable Delay
• 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 Dont Work
  • Hard Problem, Somewhat Complicated Solution
  • Hard Problem, Simple Solution
• 15. Pull the Weeds
  • Weed Identification
  • How Code Gets Weedy
• 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
• 17. Sometimes the Bigger Problem Is Easier to Solve
  • Jumping to Conclusions
  • Finding a Clear Path Forward
  • Recognizing the Opportunity
• 18. Let Your Code Tell Its Own Story
  • Dont Tell Stories That Arent True
  • Make Sure Theres a Point to the Story
  • Telling Good Stories
• 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
• 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
• 21. Sometimes You Just Need to Hammer the Nails
  • A New Argument
  • Theres 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
• 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
• B. Reading C++ for JavaScript Programmers
  • Types
  • Arrays
  • Classes
  • Declarations and Definitions
  • Function Overloading
  • Templates
  • Pointers and References
• Index

pokaż cały spis treści

ukryj recenzje