O'Reilly logo

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

97 Things Every Programmer Should Know

Book Description

Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you'll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice.

With contributions from some of the most experienced and respected practitioners in the industry--including Michael Feathers, Pete Goodliffe, Diomidis Spinellis, Cay Horstmann, Verity Stob, and many more--this book contains practical knowledge and principles that you can apply to all kinds of projects.

A few of the 97 things you should know:

  • "Code in the Language of the Domain" by Dan North
  • "Write Tests for People" by Gerard Meszaros
  • "Convenience Is Not an -ility" by Gregor Hohpe
  • "Know Your IDE" by Heinz Kabutz
  • "A Message to the Future" by Linda Rising
  • "The Boy Scout Rule" by Robert C. Martin (Uncle Bob)
  • "Beware the Share" by Udi Dahan

Table of Contents

  1. Dedication
  2. Preface
    1. Permissions
    2. How to Contact Us
    3. Safari® Books Online
    4. Acknowledgments
  3. 1. Act with Prudence
  4. 2. Apply Functional Programming Principles
  5. 3. Ask, “What Would the User Do?” (You Are Not the User)
  6. 4. Automate Your Coding Standard
  7. 5. Beauty Is in Simplicity
  8. 6. Before You Refactor
  9. 7. Beware the Share
  10. 8. The Boy Scout Rule
  11. 9. Check Your Code First Before Looking to Blame Others
  12. 10. Choose Your Tools with Care
  13. 11. Code in the Language of the Domain
  14. 12. Code Is Design
  15. 13. Code Layout Matters
  16. 14. Code Reviews
  17. 15. Coding with Reason
  18. 16. A Comment on Comments
  19. 17. Comment Only What the Code Cannot Say
  20. 18. Continuous Learning
  21. 19. Convenience Is Not an -ility
  22. 20. Deploy Early and Often
  23. 21. Distinguish Business Exceptions from Technical
  24. 22. Do Lots of Deliberate Practice
  25. 23. Domain-Specific Languages
  26. 24. Don’t Be Afraid to Break Things
  27. 25. Don’t Be Cute with Your Test Data
  28. 26. Don’t Ignore That Error!
  29. 27. Don’t Just Learn the Language, Understand Its Culture
  30. 28. Don’t Nail Your Program into the Upright Position
  31. 29. Don’t Rely on “Magic Happens Here”
  32. 30. Don’t Repeat Yourself
  33. 31. Don’t Touch That Code!
  34. 32. Encapsulate Behavior, Not Just State
  35. 33. Floating-Point Numbers Aren’t Real
  36. 34. Fulfill Your Ambitions with Open Source
  37. 35. The Golden Rule of API Design
  38. 36. The Guru Myth
  39. 37. Hard Work Does Not Pay Off
  40. 38. How to Use a Bug Tracker
  41. 39. Improve Code by Removing It
  42. 40. Install Me
  43. 41. Interprocess Communication Affects Application Response Time
  44. 42. Keep the Build Clean
  45. 43. Know How to Use Command-Line Tools
  46. 44. Know Well More Than Two Programming Languages
  47. 45. Know Your IDE
  48. 46. Know Your Limits
  49. 47. Know Your Next Commit
  50. 48. Large, Interconnected Data Belongs to a Database
  51. 49. Learn Foreign Languages
  52. 50. Learn to Estimate
  53. 51. Learn to Say, “Hello, World”
  54. 52. Let Your Project Speak for Itself
  55. 53. The Linker Is Not a Magical Program
  56. 54. The Longevity of Interim Solutions
  57. 55. Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly
  58. 56. Make the Invisible More Visible
  59. 57. Message Passing Leads to Better Scalability in Parallel Systems
  60. 58. A Message to the Future
  61. 59. Missing Opportunities for Polymorphism
  62. 60. News of the Weird: Testers Are Your Friends
  63. 61. One Binary
  64. 62. Only the Code Tells the Truth
  65. 63. Own (and Refactor) the Build
  66. 64. Pair Program and Feel the Flow
  67. 65. Prefer Domain-Specific Types to Primitive Types
  68. 66. Prevent Errors
  69. 67. The Professional Programmer
  70. 68. Put Everything Under Version Control
  71. 69. Put the Mouse Down and Step Away from the Keyboard
  72. 70. Read Code
  73. 71. Read the Humanities
  74. 72. Reinvent the Wheel Often
  75. 73. Resist the Temptation of the Singleton Pattern
  76. 74. The Road to Performance Is Littered with Dirty Code Bombs
  77. 75. Simplicity Comes from Reduction
  78. 76. The Single Responsibility Principle
  79. 77. Start from Yes
  80. 78. Step Back and Automate, Automate, Automate
  81. 79. Take Advantage of Code Analysis Tools
  82. 80. Test for Required Behavior, Not Incidental Behavior
  83. 81. Test Precisely and Concretely
  84. 82. Test While You Sleep (and over Weekends)
  85. 83. Testing Is the Engineering Rigor of Software Development
  86. 84. Thinking in States
  87. 85. Two Heads Are Often Better Than One
  88. 86. Two Wrongs Can Make a Right (and Are Difficult to Fix)
  89. 87. Ubuntu Coding for Your Friends
  90. 88. The Unix Tools Are Your Friends
  91. 89. Use the Right Algorithm and Data Structure
  92. 90. Verbose Logging Will Disturb Your Sleep
  93. 91. WET Dilutes Performance Bottlenecks
  94. 92. When Programmers and Testers Collaborate
  95. 93. Write Code As If You Had to Support It for the Rest of Your Life
  96. 94. Write Small Functions Using Examples
  97. 95. Write Tests for People
  98. 96. You Gotta Care About the Code
  99. 97. Your Customers Do Not Mean What They Say
  100. A. Contributors
  101. Index
  102. Colophon
  103. Copyright