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