A version control system will be used to turn in assignments (programs and any other required files).
All assignments must be put in the version control system's repository.
Students are responsible for making sure that their work is in the repository.
Work not in the repository will not be accepted.
Code that is not committed cannot be counted. There is no way for the instructor(s) to see code that is not committed.
Project Milestones are due by the time specified on the main CSII page.
Lab assignments are due before the next lab meeting. For example, Lab 2's assignment is due when Lab 3 starts.
Grading for the lab will come in two components:
Weekly Lab Assignments:
A score of 0 - 10 will be given for each lab assignment.
Lab assignment scores are based on lab attendance and the assignment itself.
Before you leave the lab you must show the lab instructor you have completed the assignment.
Lab Quizzes
Occasionally, a quiz will be assigned during the lab alongside the lab assignment.
These quizzes MUST be completed during the lab, and cannot be completed before or after.
The lab quizzes are graded separately from your lab assignment, and are worth ~20% of the overall lab grade.
Projects are broken into 3-4 Milestones.
Each Milestone is worth a specific number of points, as specified in the project assignment document.
Each Milestone will be seperately graded and scored.
Regrades must be requested via a Discord post ONLY in the #regrade-requests channel.
To be eligible for a regrade, a reasonable attempt on the milestone must have been made and committed to subversion by the due date.
There is only one regrade request per milestone.
After you recieve your initial milestone grade, there is a one week period to request a regrade.
Regrades incur a flat 10% off. This means the highest possible score from a regrade is 90%. (10% off of 100%)
If a request was made and the code is not noticeably better, you will lose 5% off your current grade.
Regrades MUST follow the format specified in the Discord server. Any deviation will result in the regrade not being processed.
Lab assignments are not eligible for regrades.
For more information on regrades, check the #regrade-requests channel in the class Discord server.
Grades for your projects and assignments will be submitted to the EVAL folder in your version control.
Check your EVAL folder regularly.
We will leave comments after we've graded your assignments, giving you an idea of why you recieved the score we gave you.
Programs must run and compile with clang++ on the department's computers (e.g., WASP). You must use the clang++ option -Wall when compiling.
Do NOT commit any object or executable files. These can be generated by the instructors. You WILL lose points for committing these files.
Output must be readable and easy to understand
Folder/file names must be EXACTLY as specified. Any deviation could result in your work not being graded.
All programs must compile on the CS Department's machines WASP or HORNET.
When a lab instructor is grading the labs, the instructor will not spend time fixing programs that do not compile.
There will be a large point deduction for programs that do not compile, and they will not otherwise be graded. Depending on deadlines you may get some points back if you fix your program (see regrade section).
It is your responsibility to make sure your code in the repository compiles. When in doubt - recompile.
It is easy to make a mistake in a small change and cause your program to not compile.
Don't hesitate to contact your lab instructor if you have any problems or questions.
A comment must be at the very top of each file with the following format. Substitute your name, the correct due date, and the correct program name as specified in the assignment.
/*** Firstname Lastname* program_name* CS course_number*/There must be a comment at the top of each program, after the initial comment, describing what the program does.
The program body must include comments, see below.
The program must have the functionality described in the programming assignment.
There is no debugging output from your programs.
Your program does not have an infinite loop for any valid input.
The program must produce correct results with any valid input.
Just because a program compiles does not mean it is correct
Just because a program produces a correct result with 1 or 2 different inputs does not mean it is correct
Test your program thoroughly to insure that it performs correctly
Even thorough testing does not guarantee a correct program
All programs must compile and run on the CS Department's Computers.
Additional requirements will be given with a programming assignment.
All programs should follow good programming practices (see below).
Points may be deducted for requirements not fulfilled and for failure to follow good programming practices.
The follow are fundamental good programming practices. All program you write should be written using the following guidelines.
Use good indentation.
Indentation is used so that blocks may be easily recognized. Two or four spaces per level is widely regarded as good.
Be consistent with indentation and indentation style.
Separate subtasks by empty lines.
To accomplish its task, a program or function often must perform a number of subtasks. Each subtask will require one or more C++ statements. This is analagous to sentences and paragraphs, a sentence is a C++ statement and a paragraph a subtask. Separate subtasks with empty lines so they stand out as units.
Include helpful comments.
Precede each subtask with a comment that describes what the subtask (code) does. Comments are included to describe the purpose of a statement or group of statements. it is not necessary to comment each line. Comment things that are unusual, non-standard, or complicated.
Define a variable right before its first use.
Initialize a variable when it is defined.
Initializations in C++ can be expressions that use previously defined variables, and can include function calls. An exception; don't initialize a variable if it will immediately receive input - any value you would use for initialization would not be meaningful.
Use good variable names.
This is very important.
A variable should have a name that is descriptive of the purpose of the value/object it stores.
Use constants.
If a variable's value will not change, make it const.
If a method will not change anything within the class, make it const.
Do not use line wrapping.
Ultimately, programs may be printed. If lines are too long, many printers simply put the end of the long line on the next line. This ruins the benefit indentation gives us. Avoid line wrap by keeping all lines less than 80 characters or so. Accomplish this by keeping editing windows 80 characters wide. Do not maximize editing windows.
You will learn more good programming practices as you progress.
It is a good habit to not change the value of input variables. They might be needed later on in the program with their original value. Use another variable instead.
It is a good habit to separate the input of values, calculations, and the output of values. This allows you to change the way that you prompt for input, or the way you perform the calculation, or the way that you output results without changing the other subtasks.
Pretend you are a user of your program and observe its output. Make it say what needs to be said neatly, clearly, and without and excess.
One of the best software development skills that you can learn is to start with a minimal program, get it to compile and run, and add to it in small, incremental steps with a new compile and run between each addition.
Plagiarism of any type will not be tolerated and will be dealt with in accordance to Kent State University's policy on cheating and plagiarism described in the student handbook.
See your lecture instructor's syllabus for plagiarism details.
Students may discuss programming assignments with each other - however, each student must write their own program.
It is not permitted to copy, in any manner, assignment related material (except material provided by the instructor).
You should understand and be able to explain any and every part of any assignment you turn in.
This policy applies to code created or modified by an LLM, such as ChatGPT, Gemini, or Copilot.