Programming with C++
Dry Run (dry) CISP360 Structured Programming in C++ Dry Run (dry) Professor Caleb Fowler June 5, 2022 The parentheses contains the short file name for this homework assignment. Problem. This assignment is designed to test out your coding process and provide an opportunity to practice creating your source file. Your task is to display "Hello World - my name is " whatever your name is. Your program should compile cleanly and execute without any errors. Requirements. These are general requirements for the assignment and apply to the entire homework, rather than one specific part. These always apply to all your assignments. • Correctly compile your program. • Successfully execute your program and generate correct results. • Check the plagiarism score to make sure it’s low enough (Close to green). If your score is not green, you need to examine to plagia- rism report and find out why. Discuss your findings and conclu- sions in a comment in the Canvas assignment. • Use white-space and comments to make your code more readable. • Program activities are split into logical ’chunks’ or paragraphs. I’m expecting paragraphs for input, processing (if any), and output operations. • Show me your latest program output by coping your program output onto the bottom of your source file and commenting it out so your program will still run. I will still compile and execute your program, but I have seen way to many students submit non- compiling code. I’m hoping this will force students to spot that problem before they turn it in. Specification Overview. These are the features your client (me) is asking for in your code. You need to do 2 things to complete each specification: 1) actually code the task, 2) document what you did with the appropriate specifica- tion comment. If you do not do either of these things, you will not get any credit for that task. Note: sometimes you will get comments stacking on top of each other - that’s OK .You will notice the first line of the specifications looks like a C++ comment. That’s so you can copy and paste these into your code. Don’t worry about plagiarism for these comments. You will also notice the comments have letters associated with them. That’s to give you a rough indicator of how difficult that feature is to implement. You want to comment when these specifications begin because I will be looking for them. You want me to find them. To confirm I can find them, use the grep trick discussed below. Folsom Lake College dry run (dry) 2 Specifications. � // Specification C1 – Program Greeting Create your own program greeting and display it to the console. This should always be the first thing your program displays. You can put anything you want here, but it’s common to list the pro- gram name, your name and the current date. Use a comment with the words Program Greeting the line above this code to make it easy to find. � // Specification C2 – Source File Header Put a header on the top of your source file. Start your program with comments like this: // dryRun.cpp // Pat Jones, CISP 413 // 12/34/56 � // Specification B1 – Variables Declare and initialize 1 of each of the following types of variables: int, float, double, boolean, char, and string. Make these constants because you aren’t going to change them. � // Specification A1 – Output Variables Display on the console all the variables you created in B1 - their names and their values. Rubric. Element Points Code Compiles 5 Code Runs 5 Each of the 4 specifications 5 each, 20 total Total Points 30 Due Date. This assignment is due by 11:59 PM on Sunday on the date on the calendar in Canvas. Example, if this assignment appears on the Can- vas calendar during week 2, the assignment will be due that Sunday at 11:59 PM. All the assignments are open the first day of class and you can begin working on them immediately. I encourage you to start sooner rather than later with your homework, these always seem to take longer than you think. Late Work. If you miss the due date and time specified above, your work is late. Canvas records the date and time your homework upload COM- PLETES. Late work is still acceptable, but it suffers a -10% penalty. You may turn late work in up until Canvas closes for the semester. dry run (dry) 3 This can be dangerous - do not get behind! It is also unlikely I will get a chance to grade your assignment before the semester ends. Once Canvas closes I will not accept an assignment. Do not email your homework files to me; I will not accept them. Keep in mind the time Canvas uses to record your submission - build 5 - 10 minutes into your estimates to upload the file! Pro-Tip: Get a bare bones copy of your code running and turn it in 1 . Then go ahead and modify it, fix it and whatnot. Upload it with 1 If you really want to go pro, get some sort of version control system running (like Git). the same name when you finish. That way, if something unexpected happens, you have some working code turned in. Risk management, class, risk management. Turn homework in by uploading to the appropriate Canvas Drop- box folder. I ONLY accept homework through the Canvas Dropbox. Do not add it to the comments or email me. If you are having trouble submitting the assignment, email me immediately. Save your homework as a .txt file. Just save it as a .cpp file and when you are ready to turn it in, change the .cpp extension to .txt manually. Don’t zip or otherwise compress your files. I will be able to read them once you get them on Canvas. I have a script which converts the files to any other file format I need and automatically executes them. This script also runs other tests with them as well. Multiple files compiled together are very common in the work world, but they cause all sorts of havoc in the classroom. You can upload multiple versions of a file, just make sure they are stand alone and will compile and run individually. Style Guide. All programs you write MUST have the following code and/or comments. Again, I look for these elements with my scripts, you want me to find them. Comments. Use white space and comments to make your code more readable. I run a program called cloc (count lines of code) which actually looks for this stuff. End of line comments are only permitted with variable declara- tions. Full line comments are used everywhere else. dry run (dry) 4 Comment Rate. I use a program called cloc to calculate the total number of blank lines, total number of comments and the total number of lines in your program. When you divide the number of comments by the number of lines you get the comment rate. This number gives me a rough approximation of how well commented your code is. When I see a rate of 10% (for example) I have a good idea of what I will find when I look at the program - pretty much no comments at all. Ditto, when I see a rate of 45% (for example). This code will have comments for many tricky or complex sections as well as functions. Specification Comments. Specifications are bundled into groups: "A", "B", "C", "D". You must meet the specifications of the lowest group before I will count the specifications for the highest group. For example, you must meet the "D" specifications before I will count the "C" specifications. If you miss one element of a specification bundle, that is the grade you will get for the assignment - regardless of how much extra work you do. Use whole line comments for Specifications. Put the comment on the line above the start of the code implementing the Specification. If the same Specification code appears in more than 1 place, only com- ment the first place that Specification code appears. Number your Specifications according to the specification bundle and the specific specification you are using, also provide a very short description. DO NOT BUNCH ALL YOUR SPECIFICATIONS AT THE TOP OF THE SOURCE FILE. Example specification comment: // Specification A2 - Display variables Your code to do this starts here; It’s very important to get the specifications down correctly. If your specification code isn’t commented, it doesn’t count. I use the grep trick to find your specification code. Proper documentation is part of the solution, just like actually coding the solution is. Compiler Warnings. Compiler warnings are a potential problem. They are not tolerated in the production environment. In CISP 360 you can have them. I will deduct a small number of points. CISP 400 - I will deduct lots of points if compiler warnings appear. Make sure you compile with -Wall option. This is how you spot them. C++ Libraries. We are coding in C++, not C. Therefore, you must use the C++ libraries. The only time you can use the C libraries is if they haven’t been ported to C++ (very, very rare). dry run (dry) 5 Non-Standard Language Extensions. Some compilers support unapproved extensions to the C++ syn- tax. These extensions are unacceptable. Unsupported extensions are compiler specific and non-portable. Do not use them in your pro- grams. Program Greeting. Display a program greeting as soon as the program runs. This is a simple description of what the program does. Example: // Program Greeting cout « "Simple program description text here." « endl; Source File Header. Start your source file with a program header. This includes the program name, your name, date and this class. I use the grep trick for .cpp (see below) to look for this. I focus on that homework name and display the next 3 lines. Example: // drake.cpp // Pat Jones, CISP 413 // 12/34/56 Space Rate. I use a program called cloc to calculate the total number of blank lines, total number of comments and the total number of lines in your program. When you divide the number of blank lines by the total number of lines you get the space rate. This number gives me a rough approximation of how well laid out your code is. When I see a rate of 10% (for example) I have a good idea of what I will find when I look at the program - wall of words. Ditto, when I see a rate of 45% (for example). This code will have good spacing between major blocks of code and functions. Note: when this number get’s too high (like 70% of so) the blank