CS : Programming for Non-majors, Fall 2018 Programming Project #2: Census Due by 10:20am Wednesday September

Transcription

1 CS : Programming for Non-majors, Fall 2018 Programming Project #2: Census Due by 10:20am Wednesday September This second assignment will introduce you to designing, developing, testing and debugging your own C program, as well as to declaring variables, inputting and outputting. You will also learn to add new projects to your makefile. I. PROBLEM DESCRIPTION You are a software developer for the United States Census Bureau, working on software for the 2020 Census. The particular program that you re developing will ask three questions about a census subject: 1. the average number of meals that the subject eats in restaurants per month; 2. the average number of help sessions that the subject attends per semester; 3. the subject s cell phone number. Notice that the average number of meals eaten in restaurants per month MIGHT NOT BE AN INTEGER; for example, a person might average 8.5 meals eaten in restaurants per month. Likewise, the person might average help sessions attended per semester. Note that a number that doesn t have to be an integer is known in mathematics as a real number, and is also known in computing as a floating point number. On the other hand, notice that a person s cell phone number can be expressed as three integers (the area code, the prefix and the line number), 1 separated by hyphens; for example: So, this program will have a user input two real numbers (average number of meals eaten in restaurants per month, average number of help sessions attended per semester). and three integers (the parts of the cell phone number). Write a program to perform the above task. Note that your program MUST begin with a declaration section in which you declare all necessary variables. This will be followed by the execution section (body), which will: 1. greet the user and explain what the program does, and then 2. prompt the user and input the five numbers, and then 3. output the five numbers. Details follow. Please read all of this specification CAREFULLY. Remember, every word Dr. Neeman writes down is PURE GOLD. This programming project specification contains many small code examples. In most cases, these code examples will be extremely useful in your actual PP#2. We urge you to use them

2 II. WHAT TO DO FIRST: Insert an Entry for the New Project into Your Makefile AS THE VERY FIRST STEP, in your makefile, insert a makefile entry for the new program, so that, when you re ready to compile your new program, you can use make instead of having to use the gcc command directly (which would risk disaster). Your C source file MUST be named census.c and your executable MUST be named census Using your preferred text editor (for example, nano), edit your makefile (which is named makefile) to include the following lines at the TOP of the makefile, ABOVE the make entry for Programming Project #1 (PP#1), with a blank line between the entries for PP#2 and PP#1: census: census.c gcc -o census census.c In the gcc command, the filename after -o should be the executable (NO.c extension), and the filename at the end should be the C source file (WITH the.c extension). DON T DELETE THE MAKE ENTRY FOR PROGRAMMING PROJECT #1, nor any other make entry, EVER. On the first line, above, between the colon and the name of the C source file, there are one or more tabs (on most keyboards, it s in the upper left, to the left of the Q key). There are NO SPACES between the colon and the filename. On the second line, immediately before the gcc, there are one or more tabs. There are NO SPACES immediately before the gcc. Also in the makefile, alter the clean entry (the bottommost entry in the makefile) by putting in another rm command, like so: clean: rm -f my_number rm -f census NOTES: DON T DELETE THE rm COMMAND FOR PROGRAMMING PROJECT #1, nor any other rm command, EVER. In the new rm command, above, immediately before the rm, there are one or more tabs. There are NO SPACES immediately before the rm. NEVER put ANYTHING on the same line as clean: regardless of what it may be that you want to put there. LEAVE THAT LINE COMPLETELY ALONE! In the clean entry, the file to be removed with the rm should ALWAYS ALWAYS ALWAYS be the EXECUTABLE (for PP#2, census) and NEVER NEVER NEVER a source file. NOTE: You MUST use the lecture slide packets titled C Introduction, Variables and Standard I/O to complete this project. You should study every single slide CAREFULLY. You can also look at the Software and Constants packets, but the bulk of the crucial information will be in the C Introduction, Variables and Standard I/O packets. 2

3 III. DETAILED DESCRIPTION OF THE PROGRAM HOW TO EDIT A FILE THAT DOESN T EXIST YET As noted in section II, above, your C source file for PP#2 MUST be named census.c and your executable MUST be named census But when you start working on PP#2, the C source file named census.c doesn t exist yet. Question: If a file doesn t exist yet, how can you edit it? Answer: Pretend that the file already exists, and edit it just as if that were true. The first time you save what you re editing, the file will come to exist. When you re editing a file, remember to save your work OFTEN, preferably every few minutes. A. BASIC STRUCTURE OF THE PROGRAM OTHER THAN COMMENTS (see Grading Criteria, below), the program MUST begin with the following preprocessor directive: #include <stdio.h> OTHER THAN COMMENTS (see Grading Criteria, below), the program MUST then have the main function header, followed on the next line by the main function block open, and, AT THE END OF THE PROGRAM, the main function block close on a line by itself. The main function block open and the main function block close will each have, following it on its same line, a blank space, followed by the comment open delimiter, followed by a blank space, followed by the word main in all lower case, followed by a blank space, followed by the comment close delimiter. So the basic structure of the program, OTHER THAN COMMENTS (see Grading Criteria, below), will look like this: #include <stdio.h> int main () { /* main */ } /* main */ INSIDE the main function that is, between the block open and the block close of the main function FIRST should be the declaration section, FOLLOWED BY the execution section (body) of the program, IN THAT ORDER. B. STRUCTURE OF THE DECLARATION SECTION In the declaration section, OTHER THAN COMMENTS (see Grading Criteria, below), FIRST should be ALL float variable declarations, FOLLOWED BY ALL int variable declarations. If you wish, you may put multiple variables of the SAME DATA TYPE in the same declaration statement, or you may use an individual declaration statement for each variable, or you may do some of each. 3

4 C. STRUCTURE OF THE EXECUTION SECTION (BODY) The EXECUTION SECTION (BODY) of the program MUST have the following structure and MUST be in the following order interleaving these pieces is ABSOLUTELY FORBIDDEN: 1. Greeting Subsection: Your program MUST begin by outputting a helpful message telling the user what the program does. This message may be a single line of output text, or multiple lines of output text. ALL OUTPUTS, THROUGHOUT THE ENTIRE PROGRAM, MUST BE MEANINGFUL, COMPLETE ENGLISH SENTENCES. 2. Input Subsection (a) Input the first real (floating point) quantity: i. Prompt the user to input the subject s average number of meals eaten in restaurants per month. ii. Input the subject s average number of meals eaten in restaurants per month. (b) Input the second real (floating point) quantity: i. Prompt the user to input the subject s average number of help sessions attended per semester. ii. Input the subject s average number of help sessions attended per semester. (c) Input the subject s cell phone number: i. Prompt the user to input the subject s cell phone number as three integers, separated by blank spaces (see section V); for example, printf("what is the subject s cell phone number\n"); printf(" (area code, prefix, line number, "); printf(" separated by blank spaces)?\n"); ii. Input the three integers in the above order, using a single scanf statement to read all three int variables from a single line of input text. 3. Output Subsection: (a) Output the subject s average number of meals eaten in restaurants per month, including helpful explanatory text; for example, the output text might look like: The subject eats an average of meals in restaurants per month. (b) Output the subject s average number of help sessions attended per semester, including helpful explanatory text. (c) Output the subject s cell phone number, including helpful explanatory text. This output MUST use the 3-part hyphenated notation shown on page 1. (The output may contain extra spaces between the numbers and the hyphens.) For example, the output text might look like: The subject s cell phone number is We encourage you to make your comments and outputs entertaining, but not profane or offensive. The real (floating point) numbers that you output may come out with a weird format, like this: The subject eats an average of meals in restaurants per month. For runs #2 and #3, which will use values that you ve chosen, you may see something like this: The subject attends an average of help sessions per semester. If either of these happens, DON T PANIC! THESE ARE NORMAL, so don t worry about them. 4

5 IV. ADVICE ON HOW TO WRITE A PROGRAM When you re writing a program: 1. write a little bit of the source code; 2. make; 3. if the make fails, then debug the source code; 4. when the make succeeds, then run; 5. if the run fails, then debug the source code; 6. when the run succeeds, then go on and write a little more, and so on. For example, in the case of this program: 1. Start by writing the skeleton of the source code: the #include directive, the main function header, the main function block open and block close. and appropriate comments for these items. Then make, then run. (This run won t be very interesting, unless the program crashes, in which case debug it.) 2. Then, write the variable declarations, with appropriate comments. Then make, then run. (This run won t be very interesting, unless the program crashes, in which case debug it.) 3. Then, write the greeting subsection, with appropriate comments. Then make, then run. 4. Then, write the input subsection, with appropriate comments. Then make, then run. 5. Then, write the output subsection, with appropriate comments. Then make, then run. Also, in your preferred text editor (for example, nano), FREQUENTLY SAVE YOUR WORK. Specifically, we recommend that, in your preferred text editor, you SAVE YOUR WORK EVERY FEW MINUTES. (For example, in nano, press Ctrl-O to save your work, and do this every few minutes.) NOTE: When you write a comment open delimiter (slash asterisk), you should IMMEDIATELY write the comment close delimiter (asterisk slash) so that you don t end up forgetting it later and then you can put the actual comment text in between. Likewise, when you write a block open delimiter (open curly brace), you should IMMEDIATELY write the block close delimiter (close curly brace) so that you don t end up forgetting it later and then you can put the actual source code text of the main function in between. When you re editing a file, remember to save your work OFTEN, preferably every few minutes. 5

6 V. RUNS In the script session that produces your script file (described below), you MUST run your program three times. For the first run, use the following inputs: average number of meals eaten in restaurants per month: 8.5; average number of help sessions attended per semester: 11.25; cell phone number: Note that this should be input as but it should be output as (along with helpful explanatory text). When you input the subject s cell phone number at runtime, DON T INPUT ANY HYPHENS. Instead, separate the pieces of the cell phone number with spaces (preferred) or carriage returns. For the second and third runs, choose any VALID answers to these questions that you want, but all three runs MUST have different inputs for all questions; that is, every question MUST have different answers for each of the three runs, and all inputs within a run must differ from each other. NOTE: You are ABSOLUTELY FORBIDDEN to use any cell phone number that starts with a zero in the leftmost digit of any of the three pieces. DON T USE YOUR OWN CELL PHONE NUMBER AS INPUT, nor that of anyone else that you know. VI. WHAT TO SUBMIT Before creating your script file, THOROUGHLY TEST AND DEBUG YOUR PROGRAM. Once you are satisfied with your program, create your script file, which MUST be named: pp2.txt Use the procedure described in the Programming Project #1 specification to create your script file, except replacing census for my number and census.c for my number.c, doing three runs using the input values that you ve tested (section V, above). CAREFULLY PROOFREAD THE PRINTOUT OF YOUR SCRIPT FILE. Frequently, students lose SIGNIFICANT CREDIT because of failure to proofread. Especially, CHECK YOUR MAKE COMMANDS to be sure (a) that you did them and (b) that they worked properly. Cover and Summary: You MUST create a cover page and a summary essay following the same rules as in Programming Project #1. PRINT your cover, summary and script file, using the method described in the PP#1 specification. For full credit on PP#2 (and ALL future programming projects), you MUST submit a paper submission AND upload to Canvas (see below). Binding Order: You MUST bind, IN THIS ORDER, the cover page, then the summary, then the script, then the bottom half of the extra credit form (at the very end), if applicable (see below). Thus, for binding PP#2, follow the same rules as in PP#1. Upload to Canvas: You also MUST upload your source file and script file to Canvas, as you did for PP#1, but into the place for this project. 6

7 VII. GRADING CRITERIA The following grading criteria will apply to ALL CS1313 programming projects, unless explicitly stated otherwise. Grading Criteria for Cover Page, Summary Essay, Script File and Upload to Canvas: The rules and grading criteria for the cover page, summary essay, script file and upload to Canvas, as described in the Programming Project #1 specification, also apply to the cover page, summary essay, script file and upload for Programming Project #2, and will also apply to all future Programming Projects unless explicitly stated otherwise. Failure to upload the correct files to the correct place in Canvas by the PP#2 deadline may cost you up to 5% of the total value of PP#2, right off the top before any other deductions are applied. You MUST properly do the make clean and make census steps in your script. FAILING TO PROPERLY DO THE make clean AND/OR make census STEPS, OR HAVING A COMPILE FAIL DUE TO ERRORS, WILL COST YOU AT LEAST 50% OF THE POINTS FOR THIS PROGRAMMING PROJECT, right off the top before any other deductions are applied. COMPILER WARNINGS in response to the make census step other than the clock skew warning WILL COST YOU AT LEAST 25% OF THE POINTS FOR THIS PROGRAMMING PROJECT, right off the top before any other deductions are applied. Grading Criteria for C Source Code 1. Documentation MUST be similar to that in my number.c, and will count for at least 10% of the total value of this project. (a) The program MUST be preceded by a comment block, as shown in my number.c. (b) The declaration section and the execution section (body) MUST be clearly labeled, as shown in my number.c. (c) Variable declarations MUST be preceded by comments explaining the nature and purpose of each declared name, as shown in my number.c. (d) Each subsection of the execution section (body) of the program greeting, input, output MUST be clearly labeled, as shown in my number.c. (e) EVERY executable statement MUST be preceded by a comment that clearly explains what the statement does, well enough so that even a non-programmer could understand. Exception: Multiple printf statements in a row that together output a single message need a comment only before the first of them. (f) ALL comments MUST use the format shown below. Specifically, the first line of the comment MUST simply be the comment open delimiter (slash asterisk), and the last line MUST simply be the comment close delimiter (asterisk slash). All other lines MUST have, as their first non-blank character, an asterisk, followed by a blank space, followed by the text of the comment. ALL of the asterisks MUST line up with the text of the program statement that the comment describes. For example: /* * Output to the terminal screen the subject s * average number of meals eaten in restaurants per month. */ printf("the subject averages %f meals eaten in restaurants per month.\n", average_monthly_restaurant_meals_eaten); 7

8 2. Block open/block close comments: The block open and block close for the main function MUST each be followed, on the same line, by a comment indicating that the block that they begin and end is the main function. Specifically, the line with the block open or the block close MUST have the following structure: the block open or block close, followed by a single blank space, followed by the comment open delimiter, followed by a single blank space, followed by the keyword main, followed by a single blank space, followed by the comment close delimiter. For example: { /* main */ } /* main */ 3. Section order: The section order MUST be as follows: the declaration section, followed by the executable section (body), as shown in my number.c. Therefore, ALL declarations MUST appear BEFORE ANY executable statements. 4. Identifier structure: Identifiers such as variable names MUST be in ALL LOWER CASE, except where upper case is appropriate as part of a proper name (for example, population of Oklahoma). Adjacent words in an identifier MUST be separated by an underscore. 5. Favorite professor rule for identifiers: Identifiers such as variable names MUST strictly observe the favorite professor rule, as described in the lecture slides. Meaningless, obscure or cryptic names will be penalized, as will abbreviations that aren t in common use in nonprogramming contexts. 6. Data types: EVERY variable MUST have an appropriate data type. Inappropriate data types will be penalized. 7. Variable declaration grouping: Variable declarations MUST be grouped by data type; that is, you MUST first declare ALL float variables, followed by ALL int variables. 8. Variable declaration statement structure MUST be as follows: the indentation, followed by the data type, followed by one or more blank spaces, followed by the name of the variable, followed by the statement terminator (or you may declare multiple variables in the same declaration statement, separated by commas and with a statement terminator at the end, as shown in the lecture slides). 9. Variable declaration spacing MUST have the following property: The first character of the first variable name of ALL declaration statements, regardless of data type, should be in the same column of source code text. In the case of PP#2, this means that, in a float variable declaration, there should be EXACTLY ONE blank space after the keyword float, and in an int variable declaration, there should be EXACTLY THREE blank spaces after the keyword int. (In other Programming Projects, the blank space counts may differ, but the principle will be the same.) For example: int main () { /* main */ float average_monthly_restaurant_meals_eaten; float average_semesterly_help_sessions_attended; int area_code, prefix, line_number; } /* main */ 8

9 10. Multiple variables in the same declaration statement: An individual declaration statement may declare multiple variables, but it is STRONGLY RECOMMENDED that this be done only when the variables are very closely related to one another. If an individual declaration statement declares multiple variables, then in its comma-separated list of variable names, each comma MUST be followed by a single blank space, as shown in the example just above. If the multiple variables would exceed the proper length of a line of source code text, then the declaration statement may continue on to the next line, in which case, in the subsequent line(s) of the declaration statement, the first variable name of each line should line up with the first variable name of the first line of the declaration statement. 11. Indentation MUST be used properly and consistently. The #include directive and the main function header MUST NOT BE INDENTED AT ALL (that is, they MUST begin in the leftmost column). Likewise, the main function s block open (open curly brace {) and the block close (close curly brace }) MUST NOT BE INDENTED AT ALL. ALL OTHER STATEMENTS, both declarations and executable statements, MUST be indented an additional FOUR SPACES beyond the function header. For example: #include <stdio.h> int main () { /* main */ float average_monthly_restaurant_meals_eaten; printf("the subject averages %f meals eaten in restaurants per month.\n", average_monthly_restaurant_meals_eaten); } /* main */ NOTE: If a statement uses more than one line of source code text, then the second line (and beyond) of source code text of that statement MUST be indented farther, preferably 4 spaces farther than the first line of the statement, as shown in the example just above. IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT!!! Indenting is SO INCREDIBLY IMPORTANT that it s worth at least 10% of your overall score on PP#2 (A FULL LETTER GRADE)! 12. Subsection order in the execution section: In the execution section, the subsection order MUST be as follows: the greeting subsection, followed by the input subsection, followed by the output subsection. 13. Execution subsection contents: In the execution section: the greeting subsection is ABSOLUTELY FORBIDDEN to contain any inputs; the only outputs that may be in the input subsection are prompts for inputs; the output subsection is ABSOLUTELY FORBIDDEN to contain any inputs. 14. The length of each line of C source code text MUST be less than 80 characters (the width of a typical PuTTY window); 72 characters or less is preferred. 15. The length of each line of output text MUST be less than 80 characters; 72 characters or less is preferred. 9

10 16. printf WITHOUT placeholders: EVERY printf statement that DOESN T contain any placeholders MUST have the following structure: indentation, followed by the word printf, followed by an open parenthesis, followed by a double quote, followed by the text of the string literal (probably but not necessarily ending with a newline), followed by a double quote, followed by a close parenthesis, followed by the statement terminator. For example: printf("what is the subject s cell phone number\n"); printf(" (area code, prefix, line number, "); printf("separated by spaces)?\n"); 17. printf WITH placeholders: EVERY printf statement that DOES contains one or more placeholder(s) MUST have the following structure: indentation, followed by the word printf, followed by an open parenthesis, followed by a double quote, followed by the text of the string literal including placeholder(s) (probably but not necessarily ending with a newline), followed by a double quote, followed by a comma, followed by a blank space, followed by the comma-separated list of variables whose values are replacing the placeholder(s), with a blank space after each comma, followed by a close parenthesis, followed by the statement terminator. For example: printf("the subject averages %f meals eaten in restaurants per month.\n", average_monthly_restaurant_meals_eaten); 18. Newlines in printf statements. Every line of output text MUST end with a newline. The last (or only) printf statement for a particular line of output text MUST have a newline \n as the LAST characters in its string literal, immediately before the double quote that ends that string literal. See above for examples. 19. scanf: EVERY scanf statement MUST have the following structure: indentation, followed by the word scanf, followed by an open parenthesis, followed by a double quote, followed by the text of the string literal including placeholder(s), followed by a double quote, followed by a comma, followed by a blank space, followed by the comma-separated list of variables whose values are being input each preceded by an ampersand & with no blank space after the ampersand with a blank space after each comma, followed by a close parenthesis, followed by the statement terminator. For example: scanf("%f", &average_monthly_restaurant_meals_eaten); 20. Newlines in scanf statements are FORBIDDEN. A scanf statement CANNOT have a newline \n anywhere in its string literal. See above for an example. 21. String literals MUST NOT have carriage returns embedded inside them. So, the following statement is BAD BAD BAD: printf("this is a very long sentence so it needs to be broken into pieces.\n"); The output text above MUST be broken into multiple printf statements, so the following statements are GOOD: printf("this is a very long sentence so it needs"); printf(" to be broken into pieces.\n"); Note that the resulting line of output text MUST be less than 80 characters long, preferably no more than Once you ve created your script file, you are ABSOLUTELY FORBIDDEN to alter your script file IN ANY WAY, EVER. (But, you may replace it with a completely new script file.) 10

11 EXTRA CREDIT You can receive an extra credit bonus of as much as 5% of the total value of PP#2 by doing the following: 1. Attend at least one regularly scheduled CS1313 help session for at least 30 minutes, through Wed Sep During the regularly scheduled help session that you attend, work on CS1313 assignments (ideally PP#2, but any CS1313 assignment is acceptable). YOU CANNOT GET EXTRA CREDIT IF YOU DON T WORK ON CS1313 ASSIGNMENTS DURING THE HELP SESSION. 3. Before you leave the regularly scheduled help session, fill out BOTH halves of the form on the last page of this project specification and have the help session leader (instructor or TA) sign BOTH halves. THE FORM CANNOT BE SIGNED UNTIL IT IS COMPLETELY FILLED OUT IN INK. Use of pencil on these forms is ABSOLUTELY FORBIDDEN. 4. If you leave the help session without getting the form signed, you CANNOT get extra credit for attending that help session; your form CANNOT be signed later. 5. Attach the bottom half of the form to your PP#2 script printout, AFTER the script itself, and keep the top half for your own records. VALUE OF THE EXTRA CREDIT BONUS: for attending a regularly scheduled help session Mon Sep 10 - Wed Sep 12: 5% of the total value of PP#2; for attending a regularly scheduled help session Mon Sep 17 - Wed Sep 19: 2.5% of the total value of PP#2. NOTES: You can only get the extra credit bonus ONCE per programming project that offers it. This extra credit bonus WON T be available on any other programming project unless explicitly stated so in that project s specification. 11

12 THIS PAGE INTENTIONALLY LEFT BLANK. 12

13 CS1313 PROGRAMMING PROJECT #2 BONUS REQUEST FORM Name Help Session Date Help Session Time (Arrive) Lab Help Session Time (Depart) Instructor Signature Keep this copy for your records. CS1313 PROGRAMMING PROJECT #2 BONUS REQUEST FORM Name Help Session Date Help Session Time (Arrive) Lab Help Session Time (Depart) Instructor Signature Submit this copy. In your submission, attach this copy AFTER your script file printout. If you put this in the wrong place in your submission, then you WON T get the extra credit. 13