Grading Guide for CS1112 Project (P6), Study Guides, Projects, Research of Computer Science

A grading guide for a programming project in cs1112, detailing the correctness and style expectations for various tasks. It includes a table mapping scores to the number of correctness and style errors, as well as examples of general and specific grading criteria.

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/31/2009

koofers-user-n1p-1
koofers-user-n1p-1 🇺🇸

4.7

(3)

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Grading Guide (CS1112 – P6)
The coded items below (e.g., c1e, s2a) indicate what a student’s solution should accomplish. Codes that begin with the
letter ‘c’ deals with correctness; codes that begin with ‘s’ deals with style.
Grader: If a student’s solution does not accomplish task c1a, for example, then write the task code ‘c1a’ along with any
diagnostic remarks you can give. Count the number of correctness and style errors separately.
Items marked with ** count as two errors. In the table below, the top row lists the possible scores (1 to 5). The next row
lists the number of correctness errors corresponding to every score category. The style score is determined similarly.
Enter the total score (maximum of 10) in CMS as the project score. If there are bonus questions, enter any bonus points
separately in the “Bonus Bucket,” separate from the project score.
Student: Read the grading guide for every project, even if you get a perfect score! Notice from the table below that we
often give one or two “freebies,” i.e., mistakes that don’t cost you any points. Learn from working on the project, and
learn from any mistakes.
Score 0 1 2 3 4 5
#correctness errors >10 8-10 5-7 3-4 2 0-1
#style errors—general >10 7-10 5-6 3-4 2 0-1
Scores
c and s stand for correctness and style; see table below
parts with ** next to them means that they are double the value, *** for triple, etc.
General
s0a Use meaningful variable names
s0b Appropriate indentation
s0c Appropriate comment header in each script/function file
s0d Use semi-colons as needed; not for use after if condition or else keyword
s0e Appropriate and concise comments throughout
s0f Reasonable line lengths; no horizontal scrolling
s0g [2* max] No superfluous code.
s0h No debugging output.
c0a [2* max] Program successfully executes without crashing. (* for occasional, ** for persistent)
1
pf2

Partial preview of the text

Download Grading Guide for CS1112 Project (P6) and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

Grading Guide (CS1112 – P6)

The coded items below (e.g., c1e, s2a) indicate what a student’s solution should accomplish. Codes that begin with the letter ‘c’ deals with correctness; codes that begin with ‘s’ deals with style. Grader : If a student’s solution does not accomplish task c1a, for example, then write the task code ‘c1a’ along with any diagnostic remarks you can give. Count the number of correctness and style errors separately. Items marked with ** count as two errors. In the table below, the top row lists the possible scores (1 to 5). The next row lists the number of correctness errors corresponding to every score category. The style score is determined similarly. Enter the total score (maximum of 10) in CMS as the project score. If there are bonus questions, enter any bonus points separately in the “Bonus Bucket,” separate from the project score. Student : Read the grading guide for every project, even if you get a perfect score! Notice from the table below that we often give one or two “freebies,” i.e., mistakes that don’t cost you any points. Learn from working on the project, and learn from any mistakes. Score 0 1 2 3 4 5 #correctness errors >10 8-10 5-7 3-4 2 0- #style errors—general >10 7-10 5-6 3-4 2 0-

Scores

 c and s stand for correctness and style; see table below  parts with ** next to them means that they are double the value, *** for triple, etc.

General

s0a Use meaningful variable names s0b Appropriate indentation s0c Appropriate comment header in each script/function file s0d Use semi-colons as needed; not for use after if condition or else keyword s0e Appropriate and concise comments throughout s0f Reasonable line lengths; no horizontal scrolling s0g [2* max] No superfluous code. s0h No debugging output. c0a [2* max] Program successfully executes without crashing. (* for occasional, ** for persistent) 1

showSound

c1a - sound file displays properly on startup c1b - zoom in/out works properly for the general case c1c – zoom in/out works properly for the boundary case c1d - move left/right works properly for the general case c1e - move left/right works properly for the boundary case (the display window doesn't move beyond the data) c1f-when less than 50 data points exist, the points are plotted with some marker (e.g., circles) c1g - play file button plays entire file c1h - play segment button plays current viewed segment c1i - program execution is paused for the appropriate time period when the file/segment plays c1j - [up to **] surprise! button does something sufficiently detailed by manipulating data c1k - surprise! special effect encapsulated in its own subfunction c1m - program terminates when user clicks outside buttons c1n – no error when the program can’t move left or right, or zoom in or out any more – it does nothing or just shows the current display again. c1p - buttons have correct text and are positioned properly; buttons show properly on startup s1a - [up to **] buttons show properly for zoom/shift ops (ok if buttons are slightly shifted when <5 points shown) s1b – [up to **] axes display properly (sample number goes 0-11481 on sp_beam.wav) no numbers are shown on y axis next to buttons s1c - demonstrates at least three font options: alignment, size, weight, color s1d - surprise special effect subfunction has a clear comment header s1e - uses subfunctions (besides the surprise special effect) to modularize solution BONUS. Note to graders: Let TA Zach know if you see a really creative AND well implemented special effect; we will consider it for a bonus point.

drawTree

c2a-end condition checked: tree is empty c2b-if tree has one node, only plots one node – no extra lines c2c [2*]-drawTree function is recursive c2d-splits left and right subtrees off the string correctly; handles empty subtree c2e-lines are drawn between each node and that node's children (if any) c2f-when recursing, position of left subtree is with x-dx, y-dy. The position of the right subtree is x+dx, y-dy. c2g-dx is halved on each call, but dy stays the same c2h-code handles non-full trees (e.g. 'gbrbr' should be a tree with a green root, and the left and right subtrees both have two nodes in them) c2i - nodes are colored appropriately 2