Reading Notes : the practice of programming
Download as PPTX, PDF1 like733 views
This document summarizes a study group sharing on programming best practices. It discusses topics like style, design, interfaces, debugging, testing, performance, portability, and notation. The speaker, Juggernaut Liu, has 6 years of C# experience and focuses on ideas like using descriptive variable names, commenting code, designing for interfaces to hide implementations, and writing portable code to improve maintainability. Examples are provided throughout to illustrate techniques for writing clean, efficient code.
Reading Notes : the practice of programming
- 1. Study Group Sharing: The practice of programming Juggernaut Liu
- 2. Who is this sharing for? • Who wants to read this book • Who wants to be a good programmer • Who wants to know how to solve problems like the master • Who codes in C&C++
- 3. Who is the speaker? Programming Skills : •6 years experience in C# • Information Exchange • Internal API •3 years experience in JAVA • Real-time quotes server •2 years experience in C&C++ • WFBS 8.0 , WFBS 9.0 • OSCE 10.6 SP3, OSCE 11 Juggernaut Liu
- 4. Chapters • Style • Design • Interfaces • Debugging • Testing • Performance • Portability • Notation
- 5. STYLE
- 6. Style • Naming • Expressions and Statements • Define numbers • Comments
- 7. Style • Writing code that works well and is a pleasure to read –Programs are read not only by computers but also by programmers! • If you work on a program you didn’t write, preserve the style you find there. – The Boy Scout Rule : – Always leave the campground cleaner than you found it. • Once styling the program become automatic, your subconscious will take care of many of the details for you, and even the code you produce under pressure will be better!
- 8. Style – Naming(1) ● A name should be informative, concise, memorable, and pronounceable if possible. ● Use descriptive names for globals, short names for locals. ○brief comment with the declaration of each global variable ● Sample:
- 9. Style – Naming(2) • Use active names for functions. – Function names should be based on active verbs, perhaps followed by nouns.
- 10. Style – Naming(3) • Be accurate. – A name not only labels, it conveys information to the reader. A misleading name can result in mystifying bugs. • Bad Samples: – Originally, PhoneString phoneString – Now, PhoneNumber phoneString
- 11. Style – Expressions and Statements(1) • Use the natural form for expressions. – Write expressions as you might speak them aloud
- 12. Style – Expressions and Statements(2) • Parenthesize to resolve ambiguity. – Parentheses specify grouping and can be used to make the intent clear even when they are not required
- 13. Style – Expressions and Statements(3) • Be clear.
- 14. Style – Expressions and Statements(4) • Use else-ifs for multi-way decisions.
- 15. Style – Define numbers • Define numbers as constants, not macros • Effective C++ item 2: Prefer consts, enums, and inlines to #defines.
- 16. Style – Comments • Don’t belabor the obvious • Comment functions and global data • Don’t contradict the code
- 17. DESIGN
- 18. Design • "In the end, only familiarity with the tools and techniques of the field will provide the right solution for a particular problem, and only a certain amount of experience will provide consistently professional results.“ – Raymond Fielding. The Technique of Special Effects Cinematography
- 19. Design • A good algorithm or data structure might make it possible to solve a problem in seconds that could otherwise take years. • Assess potential algorithms and data structures. Consider how much data the program is likely to process. • It best to start detailed design with data structures, guided by knowledge of what algorithms might be used.
- 20. Design • Use a library or language feature if you can. • Write or borrow a short, simple, easy to understand implementation. • Production code takes much more effort than prototypes do.
- 21. INTERFACES
- 22. Interfaces - The issues to be worked out • Interfaces: – What services and access are provided? • Information hiding: – What information is visible and what is private? • Resource management: – Who is responsible for managing memory and other limited resources? • Error handling: – Who detects errors. who reports them, and how?
- 23. Interfaces – Principles(1) • Hide implementation details – The implementation behind the interface should be hidden from the rest of the program so it can be changed without affecting or breaking anything – Avoid global variables – Classes in C++ and Java are better mechanisms for hiding information
- 24. Interfaces – Principles(2) • Choose a small orthogonal set of primitives – An interface should provide as much functionality as necessary but no more, and the functions should not overlap excessively in their capabilities. – Narrow interfaces are to be preferred to wide ones – Do one thing, and do it well. – Don’t add to an interface just because it’s possible to do so
- 25. Interfaces – Principles(3) • Don't reach behind the user's back – A library function should not write secret files and variables or change global data, and it should be circumspect about modifying data in its caller.
- 26. Interfaces – Principles(4) • Do the same thing the same way everywhere. – Consistency and regularity are important.
- 27. Interfaces – Resource Management • Free a resource in the same layer that allocated it • C++ constructors and destructors help enforce this rule • The existence of automatic garbage collection does not mean that there are no memory-management issues in a design
- 28. Interfaces – Error handling ● Detect errors at a low level, handle them at a high level ● Use exceptions only for exceptional situations ○ Exceptions should not be used for handling expected return values
- 29. DEBUG
- 30. Debug ● Advice on Good Clues, Easy Bugs ● Advice on No Clues, Hard Bugs ● Non-reproducible Bugs
- 31. Debug - Advice on Good Clues, Easy Bugs • Look for familiar patterns – Ask yourself whether this is a familiar pattern • Examine the most recent change – Looking carefully at recent changes helps to localize the problem • Get a stack trace – Examine the state of a program after death. – Check improbable values of arguments • Explain your code to someone else – Read the code – Take a break
- 32. Debug - Advice on No Clues, Hard Bugs • Make the bug reproducible • Divide and conquer – Narrow down the possibilities – Proceed by binary search • Write self-checking code – Display messages – Logs – checking function • Keep records
- 33. Debug - Non-reproducible Bugs • Check whether all variables have been initialized • Does something depend on the external environment of the program?
- 34. TESTING
- 35. Testing ● Test as You Write the Code ● Tips for Testing
- 36. Testing - Test as You Write the Code(1) • Boundary condition testing – Off-by-one errors.
- 37. Testing - Test as You Write the Code(2) • Test pre- and post-conditions
- 38. Testing - Test as You Write the Code(3) • Program defensively
- 39. Testing - Tips for Testing • Write testing code temporarily –In Unit Test : Do not add any code in production code just for testing. –Remove testing code before publishing • Use 0xDEADBEEF rather than 0 • Clear Input / Output • Vary your test cases • Test on multiple machines, compilers, and operating systems.
- 40. PERFORMANCE
- 41. Performance ● Find the bottleneck ● Strategies for Speed ● Space Efficiency ● Basic cycle for performance optimization
- 42. Performance - Strategies for Speed(1) • Use a better algorithm or data structure • Collect common subexpressions – Bad samples: ?
- 43. Performance - Strategies for Speed(2) • Replace expensive operations by cheap ones • Unroll or eliminate loops
- 44. Performance - Strategies for Speed(3) • Cache frequently-used values – Re-use recently accessed • Precompute results – Trading space for time
- 45. Performance - Strategies for Speed(4) • Buffer input and output – String += VS String.Append • Use approximate values – If accuracy isn't an issue, use lower-precision data types • Rewrite in a lower-level language – Lower-level languages tend to be more efficient.
- 46. Performance - Space Efficiency • Save space by using the smallest possible data type • Don't store what you can easily recompute • However : – Major improvements are more likely to come from better data structures or algorithm – Space efficiency often comes with a cost in run-time
- 47. Basic cycle for performance optimization ● Measure ● Focus on the few places where a change will make the most difference ● Verify the correctness of your changes ● Measure again
- 48. PORTABILITY
- 49. Portability ● Why do we worry about portability? ● Language ● Headers and Libraries ● Program Organization ● Data Exchange ● Internationalization ● Summary
- 50. Portability – Why? Why do we worry about portability? •Less maintenance and more utility •Environments change •A portable program is a better designed program
- 51. Portability – Language ●Follow the standard and mainstream ●Hide system dependencies behind interfaces ○Good samples : The I/O libraries ●Sizes of data types ○sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long) ○sizeof (float) <= sizeof (double) ●Alignment of structure and class members ○sizeof (struct X) bytes, ○Not sizeof (char) + sizeof(int)
- 52. Portability – Headers and Libraries • Use standard libraries • Problems – Headers tend to be cluttered – Header files also can "pollute" the namespace by declaring a function with the same name • Solutions – Use a different header for each compiler or environment – Redefining the name
- 53. Portability – Program Organization • Union – Conditional compilation – Include a header which defines all • Intersection (Suggestion) – Use only features available everywhere – Avoid conditional compilation
- 54. Portability – Avoid conditional compilation(1) VS
- 55. Portability – Avoid conditional compilation(2) VS Log4XXX can do it too. !!!
- 56. Portability – Data Exchange • TEXT • Binary Data – little-endian vs big-endian – Sender and receiver agree on the byte order in transmission
- 57. Portability – Internationalization • Do not assume ASCII – Unicode – UTF-8 – Wide Characters (C/C++) • Do not assume English – L10N – UI
- 58. Portability - Summary • Portable code is an ideal that is well worth striving for, since so much time is wasted making changes to move a program from one system to another or to keep it running as it evolves and the systems it runs on changes. • The intersection approach is better than the union one. – Loss of efficiency and features – Z>B
- 59. NOTATION
- 60. Notation • Perhaps of all the creations of man language is the most astonishing. – Giles Lytton Strachey, Words and Poetry
- 61. Notation • If you find yourself writing too much code to do a mundane job, or if you have trouble expressing the process comfortably, maybe you're using the wrong language. • If the right language doesn't yet exist, that might be an opportunity to create it yourself.
- 62. Notation - Formatting Data(1) • Sample : Transit different format data. Type 1 Type 2
- 63. Notation - Formatting Data(2) • Pack one of the format data Each pack_type needs to implement its own logic !!
- 64. Notation - Formatting Data(3) • Define format string
- 65. Notation With the right notation, many problems become easier. Cool Sample : Cucumber
- 66. Reference • Reviews from Amazon – http://www.amazon.com/Practice-Programming-Addison-Wesley- Professional-Computing/dp/020161586X • All members’ power point in iShare • MSDN GC Class • My Blog – http://juggernaut-liu.blogspot.tw/2014/04/practice-of-programming-portability. html – http://juggernaut-liu.blogspot.tw/2014/05/practice-of-programming-notation. html
- 67. MSDN GC Class
- 68. Q & A