Op werkdagen voor 23:00 besteld, morgen in huis Gratis verzending vanaf €20

The Rules of Programming

How to write better code

Paperback Engels 2023 1e druk 9781098133115
Verwachte levertijd ongeveer 16 werkdagen

Samenvatting

This philosophy-of-programming guide presents a unique and entertaining take on how to think about programming. A collection of 21 pragmatic rules, each presented in a standalone chapter, captures the essential wisdom that every freshly minted programmer needs to know and provides thought-provoking insights for more seasoned programmers.

Author Chris Zimmerman, cofounder of the video game studio Sucker Punch Productions, teaches basic truths of programming by wrapping them in memorable aphorisms and driving them home with examples drawn from real code. This practical guide also helps managers looking for ways to train new team members.

The rules in this book include:
- As simple as possible, but no simpler
- Let your code tell its own story
- Localize complexity
- Generalization takes three examples
- Work backward from your result, not forward from your code
- The first lesson of optimization is don't optimize
- A good name is the best documentation
- Bugs are contagious
- Eliminate failure cases
- Code that isn't running doesn't work
- Sometimes you just need to hammer the nails

Specificaties

ISBN13:9781098133115
Trefwoorden:Programmeren
Taal:Engels
Bindwijze:paperback
Aantal pagina's:250
Uitgever:O'Reilly
Druk:1
Verschijningsdatum:23-12-2022
Hoofdrubriek:IT-management / ICT

Lezersrecensies

Wees de eerste die een lezersrecensie schrijft!

Inhoudsopgave

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

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

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

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

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

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

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 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

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

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 Don't 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
Don't Tell Stories That Aren't True
Make Sure There's 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
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

A. Reading C++ for Python Programmers
B. Reading C++ for JavaScript Programmers

Index
About the Author

Managementboek Top 100

Rubrieken

Populaire producten

    Personen

      Trefwoorden

        The Rules of Programming