CPS120 Introduction to Computer Science

Download Report

Transcript CPS120 Introduction to Computer Science

CPS120 Introduction to
Computer Science
Programming & Debugging
Lecture 6
Introduction to Programming
The Program Development Cycle
Understand the problem
Plan the program's logic
Code the program
Get the program into machine-readable form
Translate the program
Test and debug the program
Document the program
What Can a Program Do?

A program can only instruct a computer to:
–
–
–
–
–
–
–
Read Input
Sequence
Calculate
Store data
Compare and branch
Iterate or Loop
Write Output
Fundamental Programming Concepts
Assignment of values to a variable
 Iteration (Looping)

– Over a set of set of statements
– With respect to a logical expressions
(conditions)

Delegation of sub-tasks to functions /
procedures
The Structure Theorem


The Structure Theorem states that any algorithm
can be built from three basic control structures.
One-after-another (Sequence)
Decision-making (Selection)
–

Making choices between 2 or more alternatives
Repetition (Iteration)
–
Concerned with repetitive tasks (and the termination
conditions of loops)
Program Design
Input Data Format
 Output Data Format
 Procedural Logic
 Control Structure

Introduction to C++
C++ Usages & Conventions
 C++
is absolutely case sensitive
–For Instance: A is 97 in ASCII and a is 65
–Remember: in ASCII {, [, and ( are not equivalent
 No
keywords in ANSI standard are even partially
uppercase
–‘While’ is not a keyword, ‘while’ is
–Be careful if you define new keywords
 The
most common practice in C+++ is to use small
letters of the first part of a variable name and
capitals for the rest of it
Characteristics of a C++
Program
Comments
 Compiler Directives
 Functions
 Braces
 Statements

A Simple C++ Program
Comments
program
Compiler Directive
Main Function
Braces
Statements
program ";
//Simple C++ Program
//
// Purpose: To demonstrate the
// parts of a simple C++
#include <iostream.h>
main ( )
{
cout << "This is a simple
return 0;
}
Comments
 Document
what is happening, why it is happening
and other issues
 Commentary is ignored by the compiler
 C++ has inline, block and documentary comments
–Inline comments are within line of code
• Use the // symbols
–Block comments are long comments delimited with /*
and */
Compiler Directives

Instructions to the compiler rather than part
of the C++ language
– Most common directive is #include
• For Example: #include <iostream.h>
– A .h file is a header file. It serves as a link between
program code and standard C++ code needed to make
programs run
Functions
A function is a block of code that carries out
a specific task
 Every C++ program has a main function
that executes when a program initiates

– Includes open parenthesis to designate a
function
– Ends with a return 0; statement
Scope Delimiters
A symbol or pair of symbols used to define
a region or area which is considered a locale
 In programming, many structures need to
have their scope defined because they
should not affect the entire program

– In C++, the symbols ‘{‘ and ‘}’ are used
Semicolons

There must be a semicolon after every
statement
– To tell the compiler that the statement is
complete
– Function definitions and compiler directives are
exempt
Columns and White Space
 Modern
programming languages are free form with
delimiters instead of columns to determine the end
of instructions
–The ; (semi-colon) is the delimiter used in C++
 Use
tabs, indents, and blank lines in any manner
that makes code easier to understand
 Many
programming instructions become
subordinate to other instructions due to scope and
other restrictions. Formatting code to reflect this
makes it easier to read
Uppercase or Lowercase
Be careful to use the same combination of
uppercase or lowercase lettering when you
enter source code
 Commands and other reserved words are all
lower case

Variables

Variables or identifiers are used to hold
information
– Usually mixed case with the first letters small
and the rest starting with a capital
– e.g. theWeight
Literals
Literals are system commands and other
pieces of information that the compiler
doesn’t understand, and therefore, takes
your word for them
 In C++, literals are enclosed in straight
double quotes " " which is the shift of the
apostrophe

C++ Control Structures
"Sequence statements" are imperatives
"Selection" is the "if then else" statement
1.
2.
–
3.
AND, OR, NOT and parentheses ( ) can be used for compound
conditions
"Iteration" is satisfied by a number of statements
–
–
–
4.
"while"
" do "
"for"
The case-type statement is satisfied by the
"switch" statement.
–
CASE statements are used for most non-trivial
selection decisions
Program Design
Program Design
•
•
•
•
I
N
P
U
T
Input Data Format
Output Data Format
Procedural Logic
Control Structure
Algorithms
Flowcharts
Pseudocode
O
U
T
P
U
T
Program Design - Input

Record Layout Table
Field Name
Position
Length
Data Type
EmpName
1-20
20
String
EmpID
21-25
5
String
EmpAddr
26-45
20
String
BirthDate
46-53
8
String
Program Design- Output

Report Sample
Employee Name
ID
Birth Day
Robert Williams
A4687
04/08/1976
Ronald Wilson
J3567
02/01/1983
Larry Jackson
K2467
07/04/1978
Mary Roosevelt
L8909
03/06/1966
What is an Algorithm?

An algorithm is merely the sequence of steps
taken to solve a problem
– Two parts
• Actions to be executed
• Order in which those actions are to be done
– Computational steps that transform the input data into
useful output data.

Algorithms are not programs
– They need to be coded in a programming language like
C++
Pseudocode & Flowcharts are Important

Pseudocode –
– Make a detailed description of your algorithm’s logic
before worrying about C++ syntax and data layout.
– An algorithm you develop using pseudocode should be
capable of implementation in any procedural
programming language
• Pseudocode is generally independent of the implementation
language

Flowcharts –
– A graphical layout of the algorithm is often very useful
in spotting “illogical” logic!
Reasons Programmers Draw Flowcharts




Drawing a flowchart gives the programmer a good
visual reference of what the program will do
Flowcharts serve as program documentation
Flowcharts allow a programmer to test alternative
solution to a problem before coding
Flowcharts provide a method for easy desk
checking
Common Flowchart Symbols
Common Flowchart Symbols
Terminator. Shows the starting and ending points of the program. A terminator has
flow lines in only one direction, either in (a stop node) or out (a start node).
Data Input or Output. Allows the user to input data and results to be displayed.
Processing. Indicates an operation performed by the computer, such as a variable
assignment or mathematical operation. With a heading – an internal subroutine
Decision. The diamond indicates a decision structure. A diamond always has two
flow lines out. One flow lineout is labeled the “yes” branch and the other is labeled the
“no” branch.
Predefined Process. One statement denotes a group of previously defined statements.
Such as a function or a subroutine created externally
Connector. Connectors avoid crossing flow lines, making the flowchart easier to read.
Connectors indicate where flow lines are connected. Connectors come in pairs, one with
a flow line in and the other with a flow line out.
Off-page connector. Even fairly small programs can have flowcharts that extend several
pages. The off-page connector indicates the continuation of the flowchart on another
page. Just like connectors, off-page connectors come in pairs.
Flow line. Flow lines connect the flowchart symbols and show the sequence of operations
during the program execution.
Rules for Drawing Flowcharts

Top to bottom and left to right
– Draw the flowchart the way you like to read
– Use arrowheads on flow lines whenever the
flow is not top to bottom, left to right
Be neat ! Use graphics software
 Avoid intersecting lines

Flowcharting Example
Start
A
Sum =0
Count =0
Avg = Sum/Count
Input data
Output Avg
Sum = Sum+data
Count = Count+1
A
YES
Count
=3?
NO
End
Program Design: Flowcharts
Problem:
Compute a Centigrade temperature from a Fahrenheit
temperature, which has been entered through the keyboard.
The Centigrade value is then output. A centigrade
temperature is computed as
5/9 * (Fahrenheit temp -32).
Start
Get f
C=5/9*(f-32)
Output c
End
Disadvantages to Flowcharts
Time consuming
 A program flowchart shows how the input
becomes output, but it does not show why a
particular step is done
 Flowcharts are subjective

Pseudocode
This device is not visual but is considered a
“first draft” of the actual program.
 Pseudocode is written in the programmer’s
native language and concentrates on the logic
in a program—not the syntax of a
programming language.

General Rules for Pseudocode
There is no standard pseudocode
 The rules of Pseudocode are generally
straightforward

– Should be easily read and understood by nonprogrammers
– All statements showing "dependency" are to be
indented.
• These include while, do, for, if, switch
Using Pseudocode
Problem Solving Example:
Write a program that allows the user to calculate the area of a rectangle as many times as they want.
A) Input: length, width, continue/quit
B) Restrictions: inputs must be positive
C) Output: area
D) Formula: area = length * width
Pseudocode for algorithm (there are many different ways to write pseudocode, two are
shown):
Pseudocode Example 1
Pseudocode Example 2
1. Ask user to input length
1. Repeat until the user wants to stop
2. Read in length
2. Repeat until the length is positive
3. If length is not positive, return to step 1
3. Ask user to input length
4. Ask user to input width
4. Read in length
5. Read in width
5. Repeat until the width is positive
6. If width is not positive, return to step 4
6. Ask user to input width
7. Calculate area
7. Read in width
8. Output area
8. Calculate area
9. Ask user if they want to do it again
9. Output area
10. Read in answer
10. Ask user it they want to do it again
11. If the answer is to continue, return to step 1
11. Read in user's response
Pseudocode Statement Rules
– Statements are written in a simple English-like
language
– Each instruction is started on a separate line
– Logic-showing keywords are written in UPPER CASE
or typed in BOLD UPPERCASE
• (e.g. IF, THEN, FOR, DO etc.)
• These are the only uppercase words in this form of
pseudocode.
– Indentation is used to show structure
– Instructions are written from top to bottom, with only
one entry point and one exit point
– Logically related groups of instructions can be formed
into modules and given a name
Rules for Pseudocode
1.
2.
3.
4.
5.
6.
7.
8.
Make the pseudocode language-independent
Indent lines for readability
Make key words stick out by showing them
capitalized, in a different color or a different font
Punctuation is optional
End every IF with ENDIF
Begin loop with LOOP and end with ENDLOOP
Show MAINLINE first; all others follow
TERMINAE all routines with an END
instruction
Compiling and Debugging
Compilation Process
1.
2.
3.
4.
5.
Get the set of instructions from you
Review the instructions to see if they violate the
rules (syntax) of the language
If all the rules are obeyed, create a working file
in the language of the computer (machine
language)
Attach to the working file full instructions for
any shortcuts you may have used (linkage)
Assemble a final file in machine language
Compiling
Source Code
Compiler
Object Code
Additional
Code
Linker
Executable
Code
Compiling and Debugging
Executable code will not be created until
you correct all of the syntax errors in your
source code
 Then the fun (with logic errors) begins

Syntax & Logic Errors

A syntax error is simply the violation of the rules
of a language; misuse of structure and form in
programming or a violation of the compiler’s
rules. These errors are detected by the compiler
– Also know as 'fatal compilation errors'

A logic error is a mistake that complies with the
rules of the compiler that causes the program to
generate incorrect output
Error Prevention & Testing

Use good design and programming style
– Don't use global variables

Study your code before typing and running it
– Have someone else look at it






Make your program self-documented
Program defensively – put in assertions and self-checking
code and comment them out
Test your code at boundary values for variables
Log your bugs
Test code in pieces using "stubs"
Consider – correctness, reliability, utility and performance
Semantic Error Detection






Use the tracing method to display the value of
critical variables
Make the error reproducible
Get a stack trace of function calls to verify
sequencing
Correct the error immediately when you find it
and check if you made it somewhere else
Examine your last code changes for errors
Ensure that you have saved and run the corrected
programs
Debugging
Debugging is the process of locating and
fixing or bypassing bugs (errors) in computer
program code or the engineering of a hardware
device.
 To debug a program is to start with a problem,
isolate the source of the problem, and then fix
it.

Debugging Steps
1.
2.
3.
Proofread before compiling
Compile
Correct all the obvious errors
•
•
•
•
4.
Start at the beginning of the list of errors and warnings
A single syntax error may cause the compiler to believe numerous
other syntax errors are occurring
Look at the error lines and if you see the error, fix it. Otherwise,
leave it for later. It may vanish when you fix something else
Don’t worry if more errors appear. Some errors mask other errors
Recompile when you have fixed what you recognize
Debugging Steps
5.
6.
7.
8.
Repeat 3 & 4 until no further errors are
obvious
Attempt to solve the remaining errors in a
top-down fashion
Solve whatever errors you can without
spending long periods of time on any given
error
Recompile whenever you feel you don’t see
any further solutions
A Debugging Mindset

Assume your syntax is wrong. Look it up!
• Add working comments as you change things

If you are 100% sure a line is correct, then
search for a syntax error in the lines
ABOVE that line
– Start with the immediately previous line and
work backward

Never make a change you can’t explain
Debugging Checklist
1.
Visually verify the spelling and case of keywords and
identifiers
-- Remember, in the editor, keywords are blue, literals are black
and comments are green
-- Look for problems with l and 1 and o and 0
2.
Verify syntax with a reference book, not just visually
-- Don’t trust your eyes; you see what is supposed to be there
3.
4.
Try to find an example in the reference book that does
something similar and compare the code
Verify that the necessary delimiters used for that line are
there
-- Check the lines above and below as well
Debugging Checklist
5.
6.
Without looking at your source code or notes, rewrite the
instruction on a piece of paper and then compare it to
your actual code; don’t cheat
Verify that the line is really the source of the error by
commenting the line using //
a)
b)
c)
d)
Don’t worry about other errors that result from this
If the error disappears, it probably results from the line you are
working on
If it moves to the next line it is probably caused earlier in the
code
Remember that the compiler cannot be trusted to pinpoint lines
Warnings
Even though an executable has been
generated, you may not be done with syntax
errors
 Compilers generate syntax warning
messages which are not fatal errors but
represent special error checking functions
for certain common programming errors

Linker Errors

Not all syntax errors are detectable by the
compiler
– These errors do not become apparent until files
are put together to create an executable
– These errors are not linked to a specific line of
code
• Look for the name of the variable and see what lines
of code it occurs on using EDIT and FIND
– LNIK2001: unresolved external
– LNK1120: unresolved externals
Logic/Semantic Errors

If the data is good and a program does not
do what it is supposed to do, there must be
at least one logic error present
– The syntax rules of C++ have been correctly
followed, but the meaning of the code is
incorrect
Semantic Errors

A semantic error is a violation of the rules of
meaning of a programming language
– E.g. My refrigerator just drove a car to Chicago
– Overt logic errors
• Something is obviously wrong even though the program is
running
– Covert logic errors
• Not so obvious something is wrong
Run things various ways to highlight these errors
Approaches to Correction
Desk-checking
 Inserting Tracing Statements

– Used when program "crashes"
– Runs to completion with incorrect output

Using an interactive debugger
Common Semantic Errors
1.
Infinite Loop
–
2.
3.
4.
Misunderstanding operator precedence
Dangling else
Off-By-One Error
–
5.
6.
7.
Created when a loop in which the expression tested never
becomes false
Loop that iterates one fewer or one more than is correct
Code inside a loop that doesn’t belong there
Not using a compound statement when one is required
Array index bounds error
Color Coding in Visual C++ Editor
Comments are green and are ignored by the
compiler
 All ANSI keywords are coded in blue
 Other code is in plain black

– Compiler keywords like cin and cout are also
shown in black
C2065: Undeclared Identifier
1. Several things may produce this error
•
•
•
•
Misspelling a keyword
Misspelling a programmer defined name (identifier)
Misuse of case in a keyword or identifier
Failure to declare an identifier