CSE 321: How to get full credit for your labs

Your labs will, of course, be graded for correctness. The grader will run your executable on a test file designed to see if your program is working correctly. But even if your program produces correct output, you may not get full credit. The grader will also look at your source code and consider other factors such as

execution and space efficiency
readability and good programming style
adherence to Resolve conventions

To maximize your chance of getting all the points you think you deserve, keep in mind the following guidelines.

Parameter Responsibilities

A preserves parameter's original value is used by the procedure. The procedure may change it, but the original value must be restored before the procedure returns.
A consumes parameter's original value is used by the procedure, but it must be changed to an initial value for its type before the procedure returns. Note that this is not always an "empty" value.
A produces parameter's original value must not affect the procedure's behavior, and no assumption can be made about the incoming value. It is the responsibility of the procedure implementer to make sure that the procedure does the right thing (as specified by the ensures clause) regardless of the initial value of any of its produces mode parameters.
An alters parameter's original value can be used and may be changed by the procedure as specified by the ensures clause.

Requires/Ensures

Every implementer defined private operation should have a requires and ensures clause. It may be written in English, but should be as precise as possible.
The body of any operation (public or private) is always written assuming that the requires clause is true. It never checks the requires clause.
The client of an operation (public or private) has the responsibility to call the operation only when the program is in a state where the requires clause is true.

Repeated Argument Rule

An object may not be used more than once as a parameter in a procedure call. For example, t.Compose(root,t,t2) violates the repeated argument rule.
Use of the accessor on the same object more than once as a parameter in a procedure call also violates this rule, unless the object is a Record. For example, if a is an Array_Of_Item, a[i] &= a[j] and Item_Are_In_Order::Are_In_Order(a[i],a[j]) are violations of the repeated argument rule.

Concrete Templates

When a concrete template has a parameter such as Item, your kernel implementation must work for an Item of any possible type.

Remember that the assignment operator makes a copy of the object. If you want to put the value of an object in another object use the swap operator instead. (Use i1 &= i2, not i1 = i2). If you truly need to make a copy of the Item, a Copy_To extension should be provided by the client.
If you need to compare two objects of type Item, then an Are_In_Order predicate should be provided by the client. Use it instead of the <= operator. (Use Item_Are_In_Order::Are_In_Order(x,y) not x <= y)

Implementing a Kernel procedure body

A kernel operation (i.e., an operation exported by a kernel component) should operate on the fields of self.
A kernel operation should not call another kernel operation.
A corollary to the above is that a kernel operation should not call itself. If you want to use recursion to implement a kernel operation, create a private operation that can be called recursively.

Private operations within a Kernel

Initialize and Finalize

The standard private operations Initialize and Finalize operate on the fields of self.
The behavior of Initialize is to create a new instance of Rep. Since Rep is a Record, the record Initialize will be invoked, initializing every field of Rep. A component implementer does not need to add anything to Initialize unless a field of Rep should be different from its initial value.
For example, assume Rep has the following field names:
```
     rep_field_name (Rep, 0, Queue_Of_Item, queue_rep);
     rep_field_name (Rep, 1, Boolean, flag_rep);
```
If the initial Rep should be an empty queue and a flag set to true, then self[flag_rep] = true must be added to Initialize. Do not add a statement to clear self[queue_rep] since an empty queue is the initial value of Queue_Of_Item.
The Finalize operation will call Finalize on self. Since self is a Record, the Finalize operation for each field in the record is called. In general, there is no need to add anything to the Finalize operation. The exception is if a field in self is a C++ pointer. Since pointers do not have a Finalize (destructor) operation nothing happens to that field. This means that the object the pointer refers to still exists, causing a memory leak. To avoid this, you must add code that deletes the object the pointer refers to.
For example, assume Rep has the following field names:
```
     rep_field_name (Rep, 0, Queue_Of_Item, queue_rep);
     rep_field_name (Rep, 1, Queue_Of_Item*, queue_ptr);
```
If the body of Finalize is left empty, then queue_rep would be destroyed, but any queue pointed to by queue_ptr would still exist, and be inaccessible. To avoid this, you must add delete queue_ptr to the body of Finalize.

User Defined Private Operations

A component implementer may add additional private operations. But the body of any such private operation should not use self. Any fields of self that are needed by the private operation are passed as parameters. It is legal to pass more than one field of the representation as parameters to a private operation (since Representation is just a fancy kind of Record).

Kernel Extensions

The implementation of an extension acts as a client, using only kernel operations. It should not refer to the representation.
This restriction should be observed even if the compiler allows you to refer to the fields of self.