As a general rule I do not give exams. You will be graded entirely on assignments and projects. Usually the assignments and projects will consist of programming problems. However, in appropriate courses, and as part of programming courses, the assignments may be design documents or the like.

Each assignment will be graded on the basis of 1.0 points and then weighted for inclusion in the term grade. The term grade will then be scaled to the 4.0 point scale that the university uses.

I then look at the grades for the class as a whole and may add in another linear scaling factor to adjust the grades upward. (I will never adjust them downward.) To do this, I select a student who I think deserves a "C" (in the letter grading scale), one who deserves a B and one who deserves an "A" and adjust as needed to try to get them to those grades.

Finally, once scaled to the 4.0 scale, I may add up to 0.3 points to your grade for general goodness and niceness. I will not subtract points. This is a subjective measure and is given to students who have participated in class well, who have worked exceptionally hard, who have worked hard in helping others, or for similar displays of intelligence, helpfulness, diligence or humour( list not exhaustive).

This is done on a spreadsheet and the raw calculations are available on request.

As a concrete example of the computational part of the process, consider a class in which there are three programming assignments, weighted at 1.0, 2.0 and 3.0 and with each programming assignment weighted for function and style as below.

	code	style	total	scaled to 1.0	Weight	Weighted
Ass. 1	0.7	0.6	3.3	0.66	1	0.66
Ass. 2	0.8	0.5	3.4	0.68	2	1.36
Ass. 3	0.7	0.6	3.3	0.66	3	1.98
sums					6	4.00
result						0.67
scaled to range 0-4						2.7

Programming assignments will be graded on two parts : function and style. Unless otherwise stated, function will be weighted by a factor of 3.0 and style by a factor of 2.0. (So function is more important than style, but not overly so.)

It is difficult to assign specific point levels to specific levels of functioning, but you should assume that things work out about as follows :

0.0		Program not submitted, empty or does not compile
0.2		Program submitted. Looks (at least) like it is an attempt to solve the problem and compiles, but does not run or does not handle any test cases correctly.
0.4		Program compiles. Handles the simplest test cases.
0.6		Program handles a reasonable set of simple test cases.
0.8		Program handles a large set of test cases.
1.0		I can't find a test case the program does not handle and it fails softly when it fails on completely improper input.

Style is very difficult to judge objectively. A set of general rules for style follows - but the first thing to remember is that for a program to get perfect style points it must be clear, readable, appropriately commented and easy to change.

Your program should be laid out consistently.
In particular, braces (where used) should be laid out consistently.
Lines in blocks should be indented to the same level.
Long lines should be broken and indented appropriately.
Blank lines should be used to separate logical sections of code.
Use good identifier names. Identifier names should be the longer and more descriptive as they have greater scope and visibility.
Comment appropriately. Don't undercomment. Don't overcomment.
Don't mix side effecting constructs with value producing constructs.
Use a full block for the then and else parts of if statements.
Similarly use a full block for the body of a loop.
It is often better to use break statements than to indent another level with an if.
Subroutines should do one thing and only one thing.
Use standard idioms for the language where such exist.
It is better to use a subset of the language well than the whole language sloppily.
Do not code to obfuscate.
Remember the 4-rule. You can remember at most 4 (± 3)things at a time - trying to do more is a good way to mess up.
Therefore : don't nest more than 4 levels.
And: don't use more than 7 parameters to a function.

0.0	I can't even begin to read your code.
0.2	Code poorly laid out, not consistent.
0.4	Code laid out ok, but otherwise unreadable
0.6	Code is laid out ok, and readable with difficulty.
0.8	Readable code. Appropriate level of comments.
1.0	I would like to write code this good.