| CMSC 106 | Project #2 | Spring 2001 |
In this project you will write a program using various conditional statements.
For this project you will be writing a tool that will help the person who deternmines if a mortgage application should be approved and what mortgage rate the customers will receive for that loan. These decision are based on the person's credit rating, the amount of the loan and the length of time they elect to have that loan.
As you read this section, you may also want to refer to the ``Sample output'' section below.
The input read and output which should be produced is discussed below.
cc -std1 -trapuv
on the OIT
UNIX Class Cluster. Even if you already know what they are, you may not use
any C language features other than those introduced in Chapters 1 through
5 of your textbook. Note that as a result loops, arrays, and user-defined
functions may not be used. In addition, your program must contain only one
single return statement at its end. Using C features not in these
chapters will result in losing credit.
Your program must have a comment near the top which contains your name, login ID, student ID, your section number, your TA's name, and an original description of the action and operation of the program. Do not put your alias in this comment! Your program should be written using good programming style and formatting, as discussed in class and throughout your textbook. For this project, style is considered to consist of:
You may want to skip this section at first, read the rest of the project, and come back to study it carefully when you are about to begin writing your program.
It is very important to continue to type in only a part of your program at a time and verify that it's correct, before going on. Any mistake is much easier to locate this way. The idea is that at all times you have a correct program, which may be incomplete and solve only part of the problem but at least the part you've written so far works.
In other words, do not attempt to write your program to perform all the necessary tests or produce completely correct output at first. Add code to perform only one processing step at a time and produce its output, and then add another until your program is complete.
For example, here is one way to begin developing the program one part at a time. Write the code for each of the following steps, and compile and test at each stage to make sure the correct results are printed for different inputs before going on to the next step listed.
else, the else is not placed so it's inside an
if statement. Only one statement can appear as the
subsidiary statement after an if, and only one statement
can appear after an else. If you want more than one
statement to appear in a place where one statement belongs, you
can use braces to group them into a compound statement. You may
have forgotten braces around the statements which were supposed to
be executed if the condition in the if/else was true
(the first group of subsidiary statements). Alternatively, it's
possible you made a mistake and have more elses than
ifs. You are much less likely to make this mistake when
your code is properly formatted and indented, with each
else lined up to clearly indicate which if statement
it belongs to.
If your program doesn't produce the results you think it should, the debug
printf statement is the best tool you can use. If, for instance,
you're not sure why one branch of an if/else statement is
being executed when you think the other should be, put a debug printf
statement right before the whole if statement which prints the values
of all the variables used in the condition. Maybe one of them doesn't have
the value which you think it should have at that point. On the other hand,
if you run your program and see that the variables all have correct values,
then the condition itself is probably not expressed correctly. Or perhaps
nothing prints in some case where you think something should. Try adding an
else to every if statement which doesn't already have one,
which prints a message indicating what must be true for that statement to be
printed. Also in other cases, add as many printfs as you need to
determine what is true about the data currently stored.
Make sure the debug printfs you add are descriptive in nature to
tell you any information you may need to determine what your program is
doing, such as what line in in the program is producing this output or what
the values of all relevant variables are at that point. This is much more
useful than printing something like ``I am here'' in your debug
printfs. Also, make sure the debug printfs do not
change what statements are controled by the if or the else.
Also for technical reasons not worth explaining, it is very important that
every debug printf ends with the newline character '\n'.
Although these debug printfs will make your output look incorrect,
they will help you develop your program correctly.
Make sure that all debug printfs are removed before you submit your
source code file for grading. After removing them, before submitting your
source file, make sure that you have compiled, run and tested your project
again to be sure you did not accidentally change it when you were removing
those lines.
If you can't find the problem after trying to debug your program using these techniques, bring printouts of your program and any compiler errors or execution results to office hours. To help us find the mistake as quickly as possible, be prepared to demonstrate and explain how you have tested your program, and what results you got.
It is very important to test your program against all different possibilities of input data, not just the values shown in the sample output section below. Doing this correctly involves thinking of what other input values are possible based on the project description, and what results the program should produce in those cases.
As an example, say you had to write a program which reads three integers
into variables a, b, and c, and prints the name of the
variable which had the largest value. Imagine that you wrote the following
program:
#include <stdio.h>
main() {
int a, b, c;
scanf("%d%d%d", &a, &b, &c);
if (a <= b) {
printf("b");
if (b <= c)
printf("c");
} else printf("a");
printf("\n");
return 0;
}
Try typing, compiling, and executing this program.
If you run the program and enter 2 6 4 it prints ``b'', which is correct.
If you run it and enter 6 4 2 it prints ``a'', which is correct.
You might assume the program works since you ran it twice with different input values, but it is not correct.
Try entering 4 2 6 and it prints ``a'', which is wrong.
Try entering 2 4 6 and it prints ``bc'', which is also wrong.
There are other possibilities of input values which cause incorrect results as well.
The conclusion is that it is always necessary to think of all the different possible combinations and possibilities of input values which might appear in a program's input, and test it so you are certain it works correctly in all cases, not just for one or two different inputs.
If you are curious, one correct program to perform this task is as follows. The program could also be written using the logical operators.
#include <stdio.h>
main() {
int a, b, c;
scanf("%d%d%d", &a, &b, &c);
if (a <= b)
if (b <= c)
printf("c");
else printf("b");
else
if (a <= c)
printf("c");
else printf("a");
printf("\n");
return 0;
}
One development policy which is extremely important is to use proper
indentation from the beginning. Many students type in their programs any
way at all, with poor or no indentation, figuring once their project works
correctly they will clean it up before submitting it. This is a very bad
idea, because it is much harder to find certain errors in a program with
poor indentation, and it's much easier to make these types of mistakes. You
are much more likely to have problems such as mismatched braces, or
misplacing an else, or misunderstanding which statements are
subsidiary to which if statements if your code is improperly
formatted or indented, or the braces are incorrectly placed. In the Q+A
sections your textbook shows several popular styles of indentation. It
doesn't matter which you use, as long as your code is clear and your
indentation is consistent, subsidiary statements are all indented, and
statements at the same level are all indented the same way. If you come to
office hours for help with a program which has missing or very poor
indentation, you will be asked to correct and reformat your program before
we are able to help you further with it.
Any evidence of unauthorized use of computer accounts or cooperation on projects will be submitted to the Student Honor Council, which could result in an XF for the course, suspension, or expulsion from the University. Projects are to be written INDIVIDUALLY. For academic honesty purposes, projects are to be considered comparable to a take-home exam. Any cooperation or exchange of ideas which would be prohibited on an exam is also prohibited on a project assignment, and WILL BE REPORTED to the Honor Council.
VIOLATIONS OF ACADEMIC HONESTY INCLUDE:
|
IT IS THE RESPONSIBILITY, UNDER THE UNIVERSITY HONOR POLICY, OF ANY STUDENT WHO LEARNS OF AN INCIDENT OF ACADEMIC DISHONESTY TO REPORT IT TO THEIR INSTRUCTOR.
Your project must be electronically submitted by the date above, before 11:00pm, to avoid losing credit as indicated on the syllabus. No projects more than two days late will be accepted for credit without prior permission or a valid medical excuse, as described on your syllabus. Only the project which you electronically submit, according to the procedures provided, can be graded; it is your responsibility to test your program and verify that it works properly before submitting. Lost passwords or other system problems do not constitute valid justifications for late projects, so do not put off working on your program or wait to submit it at the last minute!
Turn in your assignment using the ``submit'' program as before, except using ``2'' for the project number. You are to submit only the .c file containing your source code, not the executable version of your program! If your program is in a file named ``loan.c'', submit would be run as shown.
% submit 2 loan.c
Before you submit your project, you must exactly follow the specific submission checklist in the ``Testing projects before submitting'' handout separately posted by your instructor!
Assuming the name of the executable version of the program is ``loan.x'', here are three executions for three different sets of input values. Note that the input file is shown separately before each output set, and nothing is typed by the user as the program is run.
Be sure to test your program against a variety of inputs, so you are sure it works in all circumstances!
% cat input1
964
10000
0 100000.00 30
1.5
% loan.x < input1
Mortgage Application for 964 submitted
Rating: 3, Amount: $10000.00, Time: 1 years and 6 months
Your loan application is accepted.
Your loan will be granted at the 10% rate.
You will owe $1000.00 in interest.
We look forward to serving you with this matter.
% cat input2
007
500000
20 1234.56 0
1.1
% loan.x < input2
Mortgage Application for 007 submitted
Rating: 5, Amount: $500000.00, Time: 1 years and 2 months
Your loan application is rejected.
We are sorry we could not help you at this time.
% cat input3
14
1000000
0 1000000.00 20
3.0
% loan.x < input3
Mortgage Application for 014 submitted
Rating: 1, Amount: $1000000.00, Time: 3 years and 0 months
Your loan application is accepted.
Your loan will be granted at the 5% rate.
You will owe $50000.00 in interest.
We look forward to serving you with this matter.