CPS120 Introduction to Computer Science

1
CPS120 Introduction to Computer Science

• Programming Debugging
• Lecture 6

2
Introduction to Programming
3
The Program Development Cycle
4
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

5
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

6
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)

7
Program Design

• Input Data Format
• Output Data Format
• Procedural Logic
• Control Structure

8
Introduction to C
9
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

10
Characteristics of a C Program

• Comments
• Compiler Directives
• Functions
• Braces
• Statements

11
A Simple C Program

• Comments //Simple C Program
• //
• // Purpose To demonstrate the
• // parts of a simple C program
• Compiler Directive include ltiostream.hgt
• Main Function main ( )
• Braces
• Statements cout ltlt "This is a simple program
  "
• return 0

12
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 /

13
Compiler Directives

• Instructions to the compiler rather than part of
  the C language
• Most common directive is include
• For Example include ltiostream.hgt
• A .h file is a header file. It serves as a link
  between program code and standard C code needed
  to make programs run

14
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

15
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

16
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

17
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

18
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

19
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

20
Literals

• Literals are system commands and other pieces of
  information that the compiler doesnt understand,
  and therefore, takes your word for them
• In C, literals are enclosed in straight double
  quotes " " which is the shift of the apostrophe

21
C Control Structures

• "Sequence statements" are imperatives
• "Selection" is the "if then else" statement
• AND, OR, NOT and parentheses ( ) can be used for
  compound conditions
• "Iteration" is satisfied by a number of
  statements
• "while"
• " do "
• "for"
• The case-type statement is satisfied by the
  "switch" statement.
• CASE statements are used for most non-trivial
  selection decisions

22
Program Design
23
Program Design

• Input Data Format
• Output Data Format
• Procedural Logic
• Control Structure

Algorithms
O U T P U T
I N P U T
Process
Flowcharts Pseudocode
24
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
String
BirthDate
46-53
8
25
Program Design- Output

• Report Sample

Employee Name
ID
Birth Day
Robert Williams
A4687
04/08/1976
J3567
02/01/1983
Ronald Wilson
K2467
07/04/1978
Larry Jackson
L8909
03/06/1966
Mary Roosevelt
26
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

27
Pseudocode Flowcharts are Important

• Pseudocode
• Make a detailed description of your algorithms
  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!

28
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

29
Common Flowchart Symbols
30
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

31
Flowcharting Example
Start
A
Sum 0
Count 0
Avg Sum/Count
Input data
Output Avg
Sum Sumdata
Count Count1
End
Count 3?
A
NO
YES
32
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).
33
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

34
Pseudocode

• This device is not visual but is considered a
  first draft of the actual program.
• Pseudocode is written in the programmers native
  language and concentrates on the logic in a
  programnot the syntax of a programming language.

35
General Rules for Pseudocode

• There is no standard pseudocode
• The rules of Pseudocode are generally
  straightforward
• Should be easily read and understood by
  non-programmers
• All statements showing "dependency" are to be
  indented.
• These include while, do, for, if, switch

36
Using Pseudocode
37
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

38
Rules for Pseudocode

1. Make the pseudocode language-independent
2. Indent lines for readability
3. Make key words stick out by showing them
   capitalized, in a different color or a different
   font
4. Punctuation is optional
5. End every IF with ENDIF
6. Begin loop with LOOP and end with ENDLOOP
7. Show MAINLINE first all others follow
8. TERMINAE all routines with an END instruction

39
Compiling and Debugging

40
Compilation Process

1. Get the set of instructions from you
2. Review the instructions to see if they violate
   the rules (syntax) of the language
3. If all the rules are obeyed, create a working
   file in the language of the computer (machine
   language)
4. Attach to the working file full instructions for
   any shortcuts you may have used (linkage)
5. Assemble a final file in machine language

41
Compiling
Source Code
Compiler
Object Code
Executable Code
Additional Code
Linker
42
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

43
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 compilers
  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

44
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

45
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

46
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.

47
Debugging Steps

• Proofread before compiling
• Compile
• Correct all the obvious errors
• 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
• Dont worry if more errors appear. Some errors
  mask other errors
• Recompile when you have fixed what you recognize

48
Debugging Steps

1. Repeat 3 4 until no further errors are obvious
2. Attempt to solve the remaining errors in a
   top-down fashion
3. Solve whatever errors you can without spending
   long periods of time on any given error
4. Recompile whenever you feel you dont see any
   further solutions

49
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 cant explain

50
Debugging Checklist

• 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
• Verify syntax with a reference book, not just
  visually
• -- Dont trust your eyes you see what is
  supposed to be there
• 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

51
Debugging Checklist

• Without looking at your source code or notes,
  rewrite the instruction on a piece of paper and
  then compare it to your actual code dont cheat
• Verify that the line is really the source of the
  error by commenting the line using //
• Dont 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

52
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

53
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

54
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

55
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

56
Approaches to Correction

• Desk-checking
• Inserting Tracing Statements
• Used when program "crashes"
• Runs to completion with incorrect output
• Using an interactive debugger

57
Common Semantic Errors

• Infinite Loop
• Created when a loop in which the expression
  tested never becomes false
• Misunderstanding operator precedence
• Dangling else
• Off-By-One Error
• Loop that iterates one fewer or one more than is
  correct
• Code inside a loop that doesnt belong there
• Not using a compound statement when one is
  required
• Array index bounds error

58
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

59
C2065 Undeclared Identifier

• 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