ITEC 325 2011spring ibarland

home—lects—exams—hws
breeze (snow day)

hw01-grade-guide
hw01 grading guide

Here are some grading guidelines for hw01; on individual papers I might take off slightly more or less than the indicated amounts depending on what else was handled in context.

Γρεεκ letters are used to label common mistakes.

1. (15%) Part I: checkpoint: rough html and php that receives/prints the form's values.
2. (20%) Part II html forms' look (using css, aligning checkboxes, list concentrations):
   • β′ (beta′) - checkboxes looking sloppy (2%)
   • κ (kappa) - good commas/separators in php list of concentrations (3%) (or not print all concs: 7% total)
3. (30%) Part III: correct validation, client side (js)
   • α (alpha) - some/all error checking missing, or commented out, or only checking for empty.
   • ε (epsilon) - one error message at a time (alert) (2%)
   • ε′ - one single error message just saying “there is a bad character in firstname, last name, or course description” but not saying which. (3%)
   • β - no checkbox sync (10%)
   • ν (nu) - element# numbers hardcoded (6% in future,
     but waived for the first turn-in: if you did this to avoid the maintenance liability of mentioning each concentration-checkbox by name, then that's understandable, but for hw02 use javascript's getElementsByName instead.)
   • μ (mu) - a minor requirement mis-reading. (2% each) One particular too-common oversight: the courseNum 600 is specifically not allowed.

     A common industry practice is to closely re-read the client's spec (the homework) just before releasing the product to testing.

   • ι (iota) - indentation that is confusing or downright misleading. The main idea is very simple, and the same for all languages: if something statement is contained inside another, then indent it to reflect this.
     Poor indentation makes it not only difficult for others to read/debug your program, it makes it easier for you to have introduced bugs to start with.
4. (35%) Part IV: correct validation, server side (php)
   • σ (sigma) - course description allows¹ the user to inject code/tags? (4%)
   • δ (delta) - not verifying the course-prefix is valid, in php. -2. [My own solution missed this one, originally.]
   • Overall guideline/goal: are the parallels between the javascript and php code clear? (similar function names/variables?)
   • ι (iota) - indentation that is confusing or downright misleading. The main idea is very simple, and the same for all languages: if something statement is contained inside another, then indent it to reflect this.
     Poor indentation makes it not only difficult for others to read/debug your program, it makes it easier for you to have introduced bugs to start with.

Other issues:

• Miscellaneous strange behaviour or code constructs: -2
• Misleading or innacurate error messages: -2 to -5 ea.

Possible self-exercise, to help you understand the code in the provided solution: Scale it back so that: take the hw01-soln, and scale it back as follows:

• instead of statusAppend, call alert
• remove all optional-args to functions
• remove the pos/neg regexp option, for validatePat (choose one)
• change validateInt to not take optional args

Remember, javascript debuggers are your friends (e.g. Chrome's [Wrench] > Tools > Developer Tools > Javascript Console or the “firebug” add-on for FireFox and others).

home—lects—exams—hws
breeze (snow day)

©2011, Ian Barland, Radford University Last modified 2011.Mar.04 (Fri)

Please mail any suggestions (incl. typos, broken links) to iba�rlandrad�ford.edu