reklama - zainteresowany?

The Rules of Programming - Helion

The Rules of Programming
ebook
Autor: Chris Zimmerman
ISBN: 9781098133078
stron: 346, Format: ebook
Data wydania: 2022-12-09
Księgarnia: Helion

Cena książki: 143,65 zł (poprzednio: 167,03 zł)
Oszczędzasz: 14% (-23,38 zł)

Dodaj do koszyka The Rules of Programming

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

Dodaj do koszyka The Rules of Programming

 

Osoby które kupowały "The Rules of Programming", wybierały także:

  • Windows Media Center. Domowe centrum rozrywki
  • Ruby on Rails. Ćwiczenia
  • DevOps w praktyce. Kurs video. Jenkins, Ansible, Terraform i Docker
  • Przywództwo w Å›wiecie VUCA. Jak być skutecznym liderem w niepewnym Å›rodowisku
  • Scrum. O zwinnym zarzÄ…dzaniu projektami. Wydanie II rozszerzone

Dodaj do koszyka The Rules of Programming

Spis treści

The Rules of Programming eBook -- spis treści

  • 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

Dodaj do koszyka The Rules of Programming

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2024 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.