A1 Marking Scheme (preliminary, will be tweaked when we see what the class submits).

/4 Commit schedule
	+1 mark for each commit representing serious progress
	
/3 JUnit Testing
	+1 good code coverage (we won't require complete code coverage)
	+1 all public methods covered with JUnit tests
	+1 makes good use of JUnit as appropriate @BeforeEach, @AfterEach @Test etc.

/3 Java Doc
	+1 All public methods javadoc
	+1 Documentation is simple, clear, concise
	+1 Important/complex private methods javadoc
	
/9 Correctness
	+3 Code passes all of student supplied tests
	+6 Code passes all of our tests as well as 
		additional ones we create after submission

+1 Submits something!

Total out of 20 so far...

Deductions: Simplicity and code quality
	The following are deductions to a max of -4
	-1 overly complex code: 
		- if statements that are unnecessarily deep or hard to understand
			think about defining boolean isDoneWithRow = (..||..)&& ...
		- hard to understand control flows
		- hard to decide when a function will exit
		- no adopted, consistent conventions (like every function exits at the
			end)
	-1 concepts not captured, repeated code, cut and paste when not needed, 
		should think about creating private helper methods for these.

	-1 does not make good use of Java features, like Inheritance, overriding, overloading,
		constructors, and java basics like arrays, primitive types, reference types, ...

	-1 does not make good use of modifiers public, private. 
		In general, some methods public, instance vars private. 
		Don't expose instance vars if it is not necessary

	-1 does not make good use of static vs instance

	-1 does not create reasonable collection of classes

	-1 code is much longer than what it needs to be

	-1 code is not self documenting. Do this by 
		- appropriate variable names (short is ok when it is obvious, more descriptive
		  is better when there is an important concept)
		- brief documentation when doing something interesting
		- not documenting when things are obvious
		- See for example: https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html

	-1 unnecessary use of high powered tools when simple tools suffice.
		That is, a high powered tool should be used when the addition
		of the concept (so added complexity) sufficiently reduces the
		complexity of the code. Keep in mind that some concepts are
		readily available to all Java programmers. But if you force
		someone to read some extra doc to understand your code, make
		sure it is worth the effort. It may very well be, but this
		is the tradeoff you are working with.

	Example:
	The following from OthelloBoard.main is ok
		(see the bit of doc I added)...

		// Fill row 0 and col 0 with P2
		for (int row = 0; row < ob.dim; row++) {
                        for (int col = 0; col < ob.dim; col++) {
                                if (row == 0 || col == 0) {
                                        ob.board[row][col] = P2;
                                }
                        }
                }

		Better would be either of the following:

		// Fill row 0 and col 0 with P2
		for (int i = 0; i < ob.dim; i++){
			ob.board[0][i] = P2; // P2 on row==0
			ob.board[i][0] = P2; // P2 on col==0
		}

		Or even...(I know we have 2 for loops, when we could get away with one!)

		for (int i = 0; i < ob.dim; i++)ob.board[0][i] = P2; // Fill row 0 with P2
		for (int i = 0; i < ob.dim; i++)ob.board[i][0] = P2; // Fill col 0 with P2

	Example: 
		ArrayList<Person> people = new ArrayList<Person>();
		// Some code to extract csc207 students in here into people
		// ...
		// ...
		for(Person p:people){ 

		}

		vs. 

		ArrayList<Person> csc207Students = new ArrayList<Person>();
		// Some code to extract csc207 students in here into csc207Students
		// ...
		// ...
		for(Person s:csc207Students){ // or student (if block is large)

		}

--------------------------------------------------------------------------------
Conceptual Errors: Irrespective of the above marking scheme, if there are major
conceptual errors, the assignment mark will be at most 60%. A major conceptual error is one that requires a significant discussion to correct. 

In general, again, the hope is that the mark derived above reflects the following...

100%: Simple, clear, concise, correct code, well documented, easy to understand, good use of tools
	You wrote the code once and then were not happy with it so you
	simplified it.

80%: Correct code, longer than it needs to be, harder to understand. Simple mistakes,
	which would involve us pointing at a line of code, and we expect that you
	would say 'Oh Yes, I see!!'

60%: Conceptual error. We expect that the conversation about the error would
	be longer, involving a discussion of some concept first. For example, if too many things
	are static, then it becomes clear that the author does not understand static vs instance.
	To fix this we first must clear up that concept.

50%: Multiple conceptual misunderstandings. Many errors in the code.

<=40%: Submission looks like a serious attempt, involving significant effort and learning, 
	to solve the problem in Java.