Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

高品質軟體的基本動作 101 + 102 for NUU

261 views

Published on

高品質軟體的基本動作 101 + 102 for NUU

Published in: Engineering
  • Be the first to comment

高品質軟體的基本動作 101 + 102 for NUU

  1. 1. ⾼高品質軟體的基本動作
 - 如何寫 "好的" 程式 Guidelines in How to Create High Quality Code bookjan ⾃自由軟體鑄造場 蘇展 2015/04/15 Code Complete 101 + 102
  2. 2. bookjan Linkedin:https://www.linkedin.com/in/bookjan E-mail:johnsonsu@iis.sinica.edu.tw TEL: (02) 2788-3799 ext. 1478
  3. 3. In This Talk • We will discuss • How to use Code Complete • What is high code quality • How to create high quality code • Basic concepts of Software Construction • We will not discuss • Part VI - Software Craftsmanship • Detail of any programing language • Detail of how to deal with code • Any useful tools
  4. 4. Agenda 1. What is High Quality Code? 2. Variables (Good and Bad Examples) 3. Statements (Good and Bad Examples) 4. Self-Documenting code 5. How to create High Quality Code?
  5. 5. Before we start…
  6. 6. Have you ever thought…? • What are others’ code doing? • Why others’ code looks like so dirty? • How to improve/create more readable and High quality code? • and more…?
  7. 7. Have you ever thought…? • 看不懂別⼈人的 Code 在做什麼? • 為什麼別⼈人寫的 Code 很凌亂? • 如何寫出 “品質好”, “可讀性⾼高” 的 Code? • Or more…?
  8. 8. Here’s your answer.
  9. 9. Guidance Code Complete 2nd If you are… • Junior Developer • Chapter 11, 18 • Senior Developer • Chapter 4~9 • Project Manager • Chapter 2, 33 • Standard Maker • Chapter 32
  10. 10. Guidance Code Complete 2nd If you are… • Junior Developer • Chapter 11, 18 • Senior Developer • Chapter 4~9 • Project Manager • Chapter 2, 33 • Standard Maker • Chapter 32 THE REFEERENCE BOOK
  11. 11. Guidance Code Complete 2nd THE REFEERENCE BOOK
  12. 12. • Complete software-construction reference • Ready-to-use checklists • Larger perspective on software development • Absence of hype • Concepts applicable to most common language • Numerous code examples • Access to other sources of information THE REFEERENCE BOOK Key Benefits of This Handbook
  13. 13. Agenda 1. What is High Quality Code? 2. Variables (Good and Bad Examples) 3. Statements (Good and Bad Examples) 4. Self-Documenting Code 5. How to create High Quality Code? 6. Tips to improve Code Quality
  14. 14. What is 
 High Quality Code?
  15. 15. Software Quality?
  16. 16. Software Quality External • Correctness • Usability • Efficiency • Reliability • Integrity • Adaptability • Accuracy • Robustness Internal • Maintainability • Flexibility • Portability • Reusability • Readability • Testability • Understandability
  17. 17. This talk, we focus on
 Code Quality
  18. 18. Software Quality External • Correctness • Usability • Efficiency • Reliability • Integrity • Adaptability • Accuracy • Robustness Internal • Maintainability • Flexibility • Portability • Reusability • Readability • Testability • Understandability
  19. 19. Code Quality Understandability Maintainability Flexibility Portability Reusability Readability Testability
  20. 20. Code Quality Flexibility Portability Reusability Testability Self-documenting
  21. 21. Self-documenting Code Quality Construction
  22. 22. Self-documenting Code Quality Construction
  23. 23. Self-documenting Code Quality Construction
  24. 24. Agenda 1. What is High Quality Code? 2. Variables (Good and Bad Examples) 3. Statements (Good and Bad Examples) 4. Self-Documenting Code 5. How to create High Quality Code?
  25. 25. Variables Good and Bad Examples Code Complete 2nd Part III Variables
  26. 26. Variables Good and Bad Examples Code Complete 2nd Part III Variables Good Bad
  27. 27. Making Variable Declarations Easy • Turn off implicit declarations • Declare all variables • Use naming conventions • Check variable names Chapter 10
  28. 28. Initializing Variables Chapter 10
  29. 29. Initializing Variables Chapter 10
  30. 30. Keep Variables “Live” for as Short a Time as Possible Chapter 10
  31. 31. Group related statements Chapter 10
  32. 32. Group related statements Chapter 10
  33. 33. Use each variable for one purpose only Chapter 10
  34. 34. Use each variable for one purpose only Chapter 10
  35. 35. Considerations in Choosing Good Names Chapter 11
  36. 36. Chapter 11
  37. 37. Naming Loop Indexes Chapter 11
  38. 38. Naming Loop Indexes Chapter 11
  39. 39. Naming Loop Indexes Chapter 11
  40. 40. Naming Status Variables Chapter 11Chapter 11
  41. 41. Naming Status Variables Chapter 11
  42. 42. Naming Temporary Variables Chapter 11
  43. 43. Naming Temporary Variables Chapter 11
  44. 44. Kinds of Names to Avoid • Avoid misleading names or abbreviations • e.g. FALSE, TRUE • Avoid names with similar meanings • e.g. Input and inputValue; 
 recordNum and numRecords; 
 fileNumber and fileIndex • Avoid variables with different meanings but similar names • Bad: clientRecs and clientReps • Better: clientRecords and clientReports • Avoid names that sound similar, such as wrap and rap Chapter 11
  45. 45. Kinds of Names to Avoid Chapter 11 • Avoid numerals in names • Avoid file1 and file2, or total1 and total2 • Avoid misspelled words in names • Avoid misspelling highlight as hilite • Was it highlite? hilite? hilight? hilit? jai-a-lai-t? Who knows? • Avoid words that are commonly misspelled in English • e.g. Absense, acummulate, acsend, calender, concieve, defferred, definate, independance, occassionally
  46. 46. Kinds of Names to Avoid Chapter 11 • Don’t differentiate variable names solely by capitalization • Names are unique • Avoid to use frd for fired, 
 FRD for final review duty, 
 and Frd for full revenue disbursal. • Avoid multiple natural languages • Avoid “color” or “colour” and “check” or “cheque” • Avoid the names of standard types, variables, and routines

  47. 47. Kinds of Names to Avoid Chapter 11 • Don’t use names that are totally unrelated to what the variables represent • Bad: margaret and pookie. Who know? • Better: boyfriend, wife, and favoriteBeer are superior! • Avoid names containing hard-to-read characters
  48. 48. Avoid “magic numbers” Chapter 12
  49. 49. Avoid “magic numbers” Chapter 12
  50. 50. Boolean Variables Chapter 12
  51. 51. Boolean Variables Chapter 12
  52. 52. Boolean Variables Chapter 12
  53. 53. Boolean Variables Chapter 12
  54. 54. Use enumerated types for readability Chapter 12
  55. 55. Use enumerated types for readability Chapter 12
  56. 56. Avoid literals, even “safe” ones Chapter 12Chapter 12
  57. 57. Avoid literals, even “safe” ones Chapter 12Chapter 12
  58. 58. Avoid literals, even “safe” ones Chapter 12Chapter 12
  59. 59. Avoid literals, even “safe” ones Chapter 12
  60. 60. Use structures to clarify data relationships Chapter 12
  61. 61. Use structures to clarify data relationships Chapter 12
  62. 62. Agenda 1. What is High Quality Code? 2. Variables (Good and Bad Examples) 3. Statements (Good and Bad Examples) 4. Self-Documenting Code 5. How to create High Quality Code?
  63. 63. Statements Good and Bad Examples Code Complete 2nd Part IV – Statements Good Bad
  64. 64. Making Code Read from Top to Bottom Chapter 12
  65. 65. Making Code Read from Top to Bottom Chapter 12
  66. 66. Grouping Related Statements Chapter 12
  67. 67. Chapter 15 Follow the if clause with a meaningful statement Chapter 12
  68. 68. Chapter 15 Follow the if clause with a meaningful statement Chapter 12
  69. 69. Chapter 15 Follow the if clause with a meaningful statement
  70. 70. Don’t make up phony variables to be able to use the case statement Chapter 15
  71. 71. Don’t make up phony variables to be able to use the case statement Chapter 15
  72. 72. In C++ and Java, avoid dropping through the end of a case statement Chapter 15
  73. 73. 73 In C++, clearly and unmistakably identify flow-throughs at the end of a case statement
  74. 74. Abnormal Loop-With-Exit Loops Chapter 16
  75. 75. Don’t monkey with the loop index of a for loop to make the loop terminate Chapter 16
  76. 76. Use meaningful variable names to make nested loops readable Chapter 16
  77. 77. Use meaningful variable names to make nested loops readable Chapter 16
  78. 78. Don’t use recursion for factorials or Fibonacci numbers Chapter 17
  79. 79. Don’t use recursion for factorials or Fibonacci numbers Chapter 17
  80. 80. Using true and false for Boolean Tests Chapter 19
  81. 81. Using true and false for Boolean Tests Chapter 19
  82. 82. Using true and false for Boolean Tests Chapter 19
  83. 83. Agenda 1. What is High Quality Code? 2. Variables (Good and Bad Examples) 3. Statements (Good and Bad Examples) 4. Self-Documenting Code 5. How to create High Quality Code?
  84. 84. Self-Documenting Code Good and Bad Examples Code Complete 2nd Part VII Good Bad
  85. 85. Programming Style as Documentation Chapter 32
  86. 86. Programming Style as Documentation Chapter 32
  87. 87. Commenting Style - Hard to Maintain Chapter 32
  88. 88. Commenting Style - Easy to Maintain Chapter 32
  89. 89. Endline Comment Chapter 32
  90. 90. Endline Comment Chapter 32
  91. 91. Good Comment & Good Code Chapter 32
  92. 92. Good Comment & Good Code Chapter 32
  93. 93. Don’t comment tricky code, rewrite it Chapter 32
  94. 94. Commenting Routines Chapter 32
  95. 95. Commenting Routines - input and output Chapter 32
  96. 96. Agenda 1. What is High Quality Code? 2. Variables (Good and Bad Examples) 3. Statements (Good and Bad Examples) 4. Self-Documenting Code 5. How to create High Quality Code?
  97. 97. How to create High Quality Code? Code Complete 2nd Part II – Creating High-Quality Code
  98. 98. Before we start… Let’s talk about Software Construction first.
  99. 99. What Is Software Construction? http://www.newhealthguide.org/images/10421225/mental%20retardation.jpg
  100. 100. Software Construction Activities 100
  101. 101. This book focuses on… 101
  102. 102. Specific Tasks in Construction • Verifying that the groundwork has been laid so that construction can proceed successfully 102
  103. 103. Specific Tasks in Construction • Verifying that the groundwork has been laid so that construction can proceed successfully • Determining how your code will be tested 103
  104. 104. Specific Tasks in Construction • Verifying that the groundwork has been laid so that construction can proceed successfully • Determining how your code will be tested • Designing and writing classes and routines 104
  105. 105. Specific Tasks in Construction • Verifying that the groundwork has been laid so that construction can proceed successfully • Determining how your code will be tested • Designing and writing classes and routines • Creating and naming variables and named constants 105
  106. 106. Specific Tasks in Construction • Verifying that the groundwork has been laid so that construction can proceed successfully • Determining how your code will be tested • Designing and writing classes and routines • Creating and naming variables and named constants • Selecting control structures and organizing blocks of statements 106
  107. 107. Specific Tasks in Construction • Verifying that the groundwork has been laid so that construction can proceed successfully • Determining how your code will be tested • Designing and writing classes and routines • Creating and naming variables and named constants • Selecting control structures and organizing blocks of statements • Unit testing, integration testing, and debugging your own code 107
  108. 108. Specific Tasks in Construction • Reviewing other team members’ low-level designs and code and having them review yours 108
  109. 109. Specific Tasks in Construction • Reviewing other team members’ low-level designs and code and having them review yours • Polishing code by carefully formatting and commenting it 109
  110. 110. Specific Tasks in Construction • Reviewing other team members’ low-level designs and code and having them review yours • Polishing code by carefully formatting and commenting it • Integrating software components that were created separately 110
  111. 111. Specific Tasks in Construction • Reviewing other team members’ low-level designs and code and having them review yours • Polishing code by carefully formatting and commenting it • Integrating software components that were created separately • Tuning code to make it faster and use fewer resources 111
  112. 112. Why Software Construction Is So Important?
  113. 113. Here’s Why • Construction is a large part of software development 113
  114. 114. Here’s Why • Construction is a large part of software development • Construction is the central activity in software development 114
  115. 115. Here’s Why • Construction is a large part of software development • Construction is the central activity in software development • With a focus on construction, the individual programmer’s productivity can improve enormously 115
  116. 116. Here’s Why • Construction is a large part of software development • Construction is the central activity in software development • With a focus on construction, the individual programmer’s productivity can improve enormously • Construction’s product, the source code, is often the only accurate description of the software 116
  117. 117. Here’s Why • Construction is a large part of software development • Construction is the central activity in software development • With a focus on construction, the individual programmer’s productivity can improve enormously • Construction’s product, the source code, is often the only accurate description of the software • Construction is the only activity that’s guaranteed to be done 117
  118. 118. OK! I got it… Should I need to care about before the construction?
  119. 119. Most Important of All - Problem Definition 119
  120. 120. Wrong Problem Definition 120
  121. 121. Right Problem Without Good Requirements 121
  122. 122. Right Problem Without Good Software Architecture 122
  123. 123. 123 DVCS(Distributed Version Control System ) Made by Linus Torvalds for Linux He spent about 10 DAYS to commit kernel code using git… He said that it all depended on getting the basic ideas right… I'd seen the problems others had, and I wanted to avoid doing. http://www.linux.com/news/featured-blogs/185-jennifer-cloer/821541-10-years-of-git-an-interview-with-git-creator-linus-torvalds
  124. 124. One more thing…
  125. 125. Construction is an… Iterative process Chapter 5
  126. 126. 126 https://www.flickr.com/photos/j_sherman/6128691125/ Design Mental Picture
  127. 127. Design is … • A Wicked Problem • A Sloppy Process (Even If it Produces a Tidy Result) • About Tradeoffs and Priorities • A Heuristic Process • And more… Chapter 5
  128. 128. Desirable Characteristics of a Design • Minimal complexity • Ease of maintenance • Loose coupling • Extensibility • Reusability • High fan-in • Low-to-medium fan-out • Portability • Leanness • Stratification • Standard techniques Chapter 5
  129. 129. Form Consistent Abstractions Chapter 5
  130. 130. Software’s Primary Technical Imperative: Managing Complexity Accidental and Essential Difficulties Importance of Managing Complexity Chapter 5
  131. 131. Hide Secrets (Information Hiding) A good class interface is like the tip of an iceberg, leaving most of the class unexposed. Chapter 5
  132. 132. Hide Secrets (Information Hiding) Hiding ComplexityHiding Sources
  133. 133. Value of Information Hiding Chapter 5 • Asking “What does this class need to hide?” If you can put a Function or Data into the class’s public interface without compromising its secrets, do. Otherwise, don’t.
  134. 134. Encapsulate Implementation Details Chapter 5
  135. 135. Levels of Design 1.Software system 2.Subsystem/packages 3.Classes within packages 4.Data and routines within classes 5.Internal routine design Chapter 5
  136. 136. Top-Down and Bottom-Up Design Approaches Argument for Bottom Up Argument for Top Down Chapter 5
  137. 137. Top-Down and Bottom-Up Design Approaches Argument for Bottom UpArgument for Top Down No Argument, Really Chapter 5
  138. 138. Design also is an… Iterative process Chapter 5
  139. 139. How to create High Quality Code? Code Complete 2nd Part II – Creating High-Quality Code Let’s beginning~
  140. 140. 140 Packages & Classes & Functions Package Class add() contains() equals() getBounds2d() … getSize() isEmpty() … Functions
  141. 141. Reasons to Create a Class • Model real-world objects • Model abstract objects • Reduce complexity • Isolate complexity • Hide implementation details • Limit effects of changes • Hide global data • Streamline parameter passing • Make central points of control • Facilitate reusable code • Plan for a family of programs • Package related operations • Accomplish a specific refactoring Chapter 6
  142. 142. Class Foundations: Abstract Data Types (ADTs) Picture from: Auto Transport Company ScamsChapter 6
  143. 143. Example of the Need for an ADT Chapter 6 If you need to change to a 12-point font size
  144. 144. If you need to change to a 12-point font size Chapter 6 Benefits of Using ADT
  145. 145. •Avoid creating god classes •Eliminate irrelevant classes •Avoid classes named after verbs Classes to Avoid Chapter 6
  146. 146. Class Interface - Poor Abstraction Chapter 6
  147. 147. Class Interface - Good Abstraction Chapter 6
  148. 148. Class Interface - Better Abstraction Chapter 6
  149. 149. Class Interface - Mixed Levels of Abstraction Chapter 6
  150. 150. Class Interface - Consistent Levels of Abstraction Chapter 6
  151. 151. Exposing Class’s Implementation Details Chapter 6
  152. 152. Hiding Class’s Implementation Details Chapter 6
  153. 153. What is the routines? Chapter 6
  154. 154. What is the routines? Chapter 6 Routines = Functions
  155. 155. Valid Reasons to Create a Routine • Reduce complexity • Intermediate, understandable abstraction • Avoid duplicate code • Support subclassing • Hide sequences • Hide pointer operations • Improve portability • Simplify complicated Boolean tests • Improve performance • To ensure all routines are small? Chapter 6
  156. 156. Operations That Seem Too Simple to Put Into Routines Chapter 7Chapter 7
  157. 157. Operations That Seem Too Simple to Put Into Routines Chapter 7Chapter 7
  158. 158. Operations That Seem Too Simple to Put Into Routines Chapter 7Chapter 7
  159. 159. Operations That Seem Too Simple to Put Into Routines Chapter 7
  160. 160. Good Routine Names • Describe everything the routine does • Bad: ComputeReportTotals() • Silly Names: ComputeReportTotalsAndOpenOutputFile() • Avoid meaningless, vague, or wishy-washy verbs • Bad: HandleCalculation(), PerformServices(),OutputUser(), ProcessInput(), and DealWithOutput()… • HandleOutput() → FormatAndPrintOutput() • Make names of routines as long as necessary Chapter 7
  161. 161. Good Routine Names • Don’t differentiate routine names solely by number • Bad: Part1, Part2,
 OutputUser0, OutputUser1, and OutputUser2 • To name a function, use a description of the return value • e.g. cos(), customerId.Next(), printer.IsReady(), and pen.CurrentColor() • To name a procedure, use a strong verb followed by an object • e.g. PrintDocument(), CalcMonthlyRevenues(), CheckOrderlnfo(), and RepaginateDocument() Chapter 7
  162. 162. Good Routine Names • Establish conventions for common operations • e.g. employee.id.Get(), dependent.GetId(), supervisor(), candidate.id() • Use opposites precisely Chapter 7
  163. 163. How Long Can a Routine Be? 100 200 Less then 200 lines is better. Chapter 7
  164. 164. Don’t use routine parameters as working variables Chapter 7
  165. 165. Don’t use routine parameters as working variables Chapter 7
  166. 166. Limit the number of a routine’s parameters to about 
 Seven
 
 Chapter 7 7
  167. 167. What is Pseudocode? Chapter 5 Pseudocode is an informal high-level description of the operating principle of a computer program or other algorithm.
  168. 168. Pseudocode Principles Chapter 5
  169. 169. Pseudocode Programming Process: Classes Chapter 5
  170. 170. Pseudocode Programming Process: Routines Chapter 5
  171. 171. Constructing Routines by Using the PPP Chapter 5 Design the routine. Code the routine. Check the code. Clean up loose ends. Repeat as needed. 1 2 3 4 5
  172. 172. Code the Routine Chapter 5 1 2 3 4 5
  173. 173. Write the routine declaration Chapter 5 1
  174. 174. Writing the First and Last Statements Around Pseudocode Chapter 5 2 Chapter 5
  175. 175. Turn the Pseudocode into High-level comments Chapter 5Chapter 5 2
  176. 176. Chapter 5 The code for each comment has been filled in from here down. 3
  177. 177. Chapter 15 Example of a Complete Routines Overview Routine Header Routine Interface The code for each comment has been filled in from here down. The last paragraph of Routine
  178. 178. Self-documenting Code Quality Construction
  179. 179. Thank You!
  180. 180. Q & A
  181. 181. 本簡報授權聲明 除另有聲明外,本簡報內容採⽤用 Creative Commons「姓名標⽰示 - ⾮非商業 性」台灣 3.0 版授權條款。 歡迎⾮非商業⺫⽬目的的重製、散布或修改本簡報的內容,但請標明: (1)原作者姓名;(2)本簡報標題;(3)演講⽇日期。 簡報中所取⽤用的圖形創作乃截取⾃自網際網路,僅供演講者於⾃自由軟體推廣演 講時主張合理使⽤用,請讀者不得對其再⾏行取⽤用,除⾮非您本⾝身⾃自忖亦符合主張 合理使⽤用之情狀,且⾃自負相關法律責任。 THANK YOU Website: www.openfoundry.org Phone: 02-2788-3799 ext. 1478

×