Hand marking scheme for Assignment 3 ------------------------------------- There are 7 sections, each out of 2 marks (except the last which is out of 4). Generally, 2 indicates that the section is fine, 1 indicates a few problems but overall pretty good, and 0 indicates it's terrible and/or worthless. Note that hand marking doesn't assess whether the code works or not, rather, how "good" the code is. "Good" here means clarity, readability, extensibility, maintainability, etc. The machine marking assesses how correct the code is. READABILITY (out of 2 marks) This is things such as indenting, whitespace, bracketing, identifiers, comments, etc. 2/2: Code is all easily readable at a glance. 1/2: ... 0/2: Code is hard to read at a glance. DESIGN (out of 2 marks) 2/2: Code easily extensible to other paging algorithms. Different paging algorithms are well separated from one another (excepting the CacheFactory of course). Features common to all algorithms (eg. the hit/miss counters, etc) are centralised somehow. This probably requires inheritance, but not necessarily. Getting 2/2 without inheritance is possible, if very unlikely. 1/2: ... 0/2: Code not well designed with respect to paging algorithms. CODE REPETITION BETWEEN read() AND write() METHODS (out of 2 marks) 2/2: Large sections of code are not repeated in the read() and write() methods. eg. use another method with or without a boolean passed in to indicate read/write. 1/2: Some code shared, some code repeated. 0/2: read() and write() are basically the same except for a few lines of code. CODE REPETITION BETWEEN ALGORITHMS (out of 2 marks) 2/2: Code from other algorithms is reused where possible. ie. no repeated code between the three algorithms. For inheritance, this probably means have LRU inherit from FIFO, and PLRU inherit from LRU. 1/2: Some code shared, some code repeated. For inheritance, this probably means something like having helper functions inside the Cache class which don't belong there (since Cache should be general, but it instead has code to support specific algorithms which belongs in the actual specific algorithm classes). 0/2: The algorithms contain large sections of identical or nearly identical code. FILE LAYOUT (out of 2 marks) 2/2: Use of .h and .cc files to store class definitions and code is correct. Include guards used correctly. 1/2: ... 0/2: Lots of code inside .h files (excepting templated classes). Or include guards not used. Or code all in one .cc file. Or #including .cc file. And so on. CORRECT USE OF TYPEDEFS (out of 2 marks) 2/2: Typedefs are used where they should be, and the right typedef is always used. 1/2: Typedefs not always used where they should be, or are occasionally used incorrectly, but the majority are okay. 0/2: Typedefs rarely used if ever, often used incorrectly. The correct use is: * addr_t is used whenever you need to store an address or a count of bytes. * page_t is used whenever you need to store a page number or a count of pages. * counter_t is used whenever you need to store a count of the hits/misses. CHOICE OF DATA STRUCTURES (out of 4 marks) 4/4: All data structures are good, efficient, appropriate (eg. dual lists/maps, using the appropriate one at all times). 3/4: Some data structures efficient, some not. 2/4: Data structures are good in general, but not efficient (eg. linear searching through lists). 1/4: Data structures are barely appropriate. 0/4: Data structures completely inappropriate.