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. 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. 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. Have you ever thought…?
• 看不懂別⼈人的 Code 在做什麼?
• 為什麼別⼈人寫的 Code 很凌亂?
• 如何寫出 “品質好”, “可讀性⾼高” 的 Code?
• Or more…?
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. 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
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?
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. 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. 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. 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
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?
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?
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. How to create High Quality
Code?
Code Complete 2nd Part II – Creating High-Quality Code
102. Specific Tasks in Construction
• Verifying that the groundwork has been laid so
that construction can proceed successfully
102
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. 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. 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. 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. 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. Specific Tasks in Construction
• Reviewing other team members’ low-level
designs and code and having them review
yours
108
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. 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. 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
114. Here’s Why
• Construction is a large part of software
development
• Construction is the central activity in software
development
114
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. 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. 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. OK! I got it…
Should I need to care about
before the construction?
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
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. 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
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.
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. Top-Down and Bottom-Up Design Approaches
Argument for Bottom Up
Argument for Top Down
Chapter 5
137. Top-Down and Bottom-Up Design Approaches
Argument for Bottom UpArgument for Top Down
No Argument, Really
Chapter 5
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
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. 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. Good Routine Names
• Establish conventions for common operations
• e.g. employee.id.Get(), dependent.GetId(), supervisor(), candidate.id()
• Use opposites precisely
Chapter 7
163. How Long Can a Routine Be?
100
200
Less then 200 lines is better.
Chapter 7
166. Limit the number of a routine’s
parameters to about
Seven
Chapter 7
7
167. What is Pseudocode?
Chapter 5
Pseudocode is an informal high-level
description of the operating principle of a
computer program or other algorithm.
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
176. Chapter 5
The code for each comment has been filled in from here down.
3
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
