Start Over Please hold this item Export MARC Display Return To Browse
 
     
Limit search to available items
Record: Previous Record Next Record
Title 97 things every programmer should know : collective wisdom from the experts / edited by Kevlin Henney.
Publication Info Sebastopol : O'Reilly Media, 2010.
Edition 1st ed.



Descript 1 online resource (257 p.)
Edition 1st ed.
Note Description based upon print version of record.
Contents 97 Things Every Programmer Should Know -- Dedication -- Preface -- Permissions -- How to Contact Us -- Safari® Books Online -- Acknowledgments -- 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
Note 325 annual accesses. UkHlHU
ISBN 9781449388676
Click on the terms below to find similar items in the catalogue
Subject Computer programming.
Alt author Henney, Kevlin.
Descript 1 online resource (257 p.)
Edition 1st ed.
Note Description based upon print version of record.
Contents 97 Things Every Programmer Should Know -- Dedication -- Preface -- Permissions -- How to Contact Us -- Safari® Books Online -- Acknowledgments -- 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
Note 325 annual accesses. UkHlHU
ISBN 9781449388676
Subject Computer programming.
Alt author Henney, Kevlin.

Subject Computer programming.
Descript 1 online resource (257 p.)
Note Description based upon print version of record.
Contents 97 Things Every Programmer Should Know -- Dedication -- Preface -- Permissions -- How to Contact Us -- Safari® Books Online -- Acknowledgments -- 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
Note 325 annual accesses. UkHlHU
Alt author Henney, Kevlin.
ISBN 9781449388676

Links and services for this item: