Grading Policy

Correct Submission of Program - 10 points

If you turn in your program on time, with the correct pieces, with your name and assignment number on everything, you get 10 free points. Here's what's required:

printed source code, stapled or paper-clipped together
design document (if required - see the next paragraph)
printed output
printed data files, if used in the assignment
executables - you may turn these in on disk; however, I prefer them to be turned in directly onto my computer. In Network Neighborhood, type in \\LORELEI\ENGR131 . The password is "mischief" - if you're prompted for a username, leave it blank. Make a new folder with your name and CWRUnet ID (example: "Amanda Rohn, aer8"), and put the file(s) in it. I will check them for viruses; if your file is infected I will ask you to clean it. If it comes back still infected, or if it infects my computer, Bad Things will happen.

Design Document and/or In-Class Work - 15 points

Usually I will assign something for you to code during recitation. Depending on its difficulty, it will be worth some amount of points between 5 and 15.

A design document will be required for most assignments, and will count for the remaining points in this category. This doesn't need to be nicely typed up; in fact, it probably shouldn't be. What I'm looking for is a piece of paper that shows me you sat down and thought about your program before you started typing in code. Yes, I realize you may not want to design it first; that's the point. The design document can be anything that shows me the design process: pictures, algorithms/psuedocode, bits of C++ code, flow charts, whatever. It doesn't need to include everything; obviously you shouldn't need to design the code that gets a valid integer from the user every time you write a program. This will basically just be graded on whether it's there and it's reasonably convincing.

Logic and Design - 50 points

Your program has to work. It has to work correctly. And it has to work in an efficient way (this is an advanced class remember). You will lose a lot of these points if you turn in a program that won't compile. If your program does run, but works incorrectly, the amount of points you get depends on why it doesn't work right. If it's because you put a parenthesis in the wrong place or forgot a semicolon, that's a pretty minor mistake, and you'll still get most of the points. If it's due to a major logic error, you'll lose more. Also, you will lose points if you do things sloppily and inefficiently, even if it still works.

Clarity - 25 points

You want me to be able to read your code. Readability of code is determined by several things such as

Coding style: white space and indentation.
- Leave spaces between lines of code. Paper isn't that expensive.
- You can follow a famous indent style or make up your own. Be consistent within a program, though. (The book tends to use K&R style, which is slightly harder for me to read than Allman style, which Joel uses.)
Output style.
- Meaningful output lets the user know what s/he is supposed to be entering.
Variables.
- Names of variables should be meaningful, but not ridiculously long.
- There are a few different conventions in style of names. (I usually use variable_names, FunctionNames, and CONSTANT_NAMES. I find that it's somewhat helpful, but it's not something I'm going to grade on.)
Commenting.
- You need to comment your code. It helps me out a lot, and is good programming practice for when you (or others) will need to come back to your code and change it later. Try to comment anything that isn't blindingly obvious.

Josh Ghiloni, the Friday 3:30 recitation leader, has a grading policy with nice examples of good and bad things to do. You may wish to look at it.

Other Important Things

Cheating: don't do it. I may not catch it, but if I do (and it's not too hard to catch), you will not be happy. There are only three ways I know of to get less than a B in ENGR 131: don't go to class, don't turn in your work, or cheat.

If you do something in your program differently from the way that's suggested or implied in the assignment, that's fine (well, depending what it is - ask first if you aren't sure). But you should *clearly* explain it in comments; if it's major, you should probably write me a note about it. For example, sometimes I'll give you an algorithm, but allow you to write your own if you want to. If you do make up your own algorithm, you need to explain it. If I'm grading your programs and I see something that is obviously what I gave you and is not explained, I'm not necessarily going to feel like spending the time to figure out what your algorithm was, where you got it from, and whether it works. (The statement "this worked for all the numbers I tried, so I guess it works" is not a valid argument for the efficacy of your algorithm.)

You are NOT allowed to work ahead and use things we haven't learned yet in your assignments. Stick to what's been covered in class or recitation.

Back to the Main Page