L2: Program Development Flashcards
(CRE)2 Criteria
(Program Fitness Checklist)
A Good Program should be:
- Correct
- Does what specification said
- What client wants
- What user needs
- Clear
- Understandable Implementation
- Robust
- Resilient wrt the real world, human abilities, future requirements
- Ready
- Delivered within schedule, budget constraints
- Efficient
- Within limits of time, space, cost
- Ethical
- Meets standards set by law, professional ethics, and safety needs
Convergent Programming Steps
- Understand the Problem
- State the Problem
- Specify the Interface
- List representative and stressful cases
- Code into C
- Diagram your approach
- Decide on variables and invariants
- Outline overall logic
- Convert logic into code
- Verify the Solution
- “Desk Check” -mental test cases
- Perform test cases on computer
- Use Fitness Test (CRE)2
- Peer Review
- Return to earlier steps as needed
Convergent Programming:
Basic Idea
- Clearly define the logic:
- in english,
- mathematical notation
- diagrams
- THEN, express that logic in C
Code INTO C, not IN C
Convergent Programming Steps:
Step 1) Understand the Problem
-Substeps
- State the problem
- Specify the Interface
- List Representative Cases
- List Stressful Cases
Convergent Programming Steps:
Step 2) Code Into C:
-Substeps
Code into C
- Diagram your approach
- Decide on variables and invariants
- Outline overall logic
- Convert logic into code
Convergent Programming Steps:
Step 3) Verify the Solution
-Substeps
Verify the Solution
- “Desk Check” -mental test cases
- Computer Test: Perform test cases on computer
- Use Fitness Test (CRE)2
- Peer Review
2 “Families” of Common Errors
- Exogenous (Outward error)
- Hardware Issues
- Computer Crash/error
- Software Issues
- Data Issues:
- incorrect data
- too much data
- too fast/slow
- Hardware Issues
- Endogenous (Problems with development process/team)
- Analysis
- Wrong Problem
- Wrong Goals
- Wrong User
- Specification
- incorrect
- incomplete
- inconsistent
- Logic
- forgetfulness
- stupidity
- laziness
- Analysis
make:
-n switch
%make -n
Do not actually perform the commands in the recipes,
just echo them
Programming as a Craft:
Maintain Respect for ________
- The User
- Will they feel good about using your product?
- The Tools
- Recognize their limits, and your own
- Yourself
- Use best known practices
- Take pride in your work
Make Files:
- file name
- format
- Always have the name “makefile”
- Format:
target: prerequisites
recipe
dependencies
Example:
foobar: main.o util.o
cc -c main.c
Key Files
during
Compiling and Linking
- Source Files
- c language
- text format
- end in .c and .h
- Object Files
- machine instructions, binary format
- external names
- data initialization
- end in .o
- Libraries
- Collections of object files
- binary format
- end in .a
- Executable Files
- instructions
- data
- entry point (“main”)
- other details
Steps of Creating an Executable Program
- Edit
- Create source files(.h, .c) with editor
- Compile
- Translate each source into an object file
- Link
- Combine the object files into an executable file
- Execute
- Use the new program
Compiler:
Useful switches for the
cc program
* -c
* compile into an object(.o) file * -D * Define a variable, equivalent to #define * example: cc -DFOO=this * -E * Send preprocessor output to stdout and stop * -S * Save .s files instead of deleting them
More advanced switches:
- -g
- create expanded symbol table for debugging
- -p
- link with the profiling facility “prof”
- -O
- optimize the code
Compiler Steps
- Preprocessing
- Replace #define, #include, etc
- Compilation
- Produce assembly language from c text
- generates .s files
- Assembly
- Produce object files from assembly text
- generates .o files
Using External Variables
- Use the “extern” keyword to declare an external variable
- Allows use of a variable from another object that is linked
- Example:
- extern int flag
- Ensure exactly one definition for each external name
- Always initialize external variables
- Ensure definition & import agree on type(the linker doesn’t check this)