User Tools

Site Tools


haas:fall2015:common:submitblurb

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
haas:fall2015:common:submitblurb [2015/09/19 17:37] wedgehaas:fall2015:common:submitblurb [2016/09/06 10:52] (current) wedge
Line 13: Line 13:
  
   * Project must be submit on time, by the posted deadline.   * Project must be submit on time, by the posted deadline.
 +    * Early submissions will earn 1 bonus point per full day in advance of the deadline.
 +      * Bonus eligibility requires an honest attempt at performing the project (no blank efforts accepted)
     * Late submissions will lose 25% credit per day, with the submission window closing on the 4th day following the deadline.     * Late submissions will lose 25% credit per day, with the submission window closing on the 4th day following the deadline.
       * To clarify: if a project is due on Wednesday (before its end), it would then be 25% off on Thursday, 50% off on Friday, 75% off on Saturday, and worth 0% once it becomes Sunday.       * To clarify: if a project is due on Wednesday (before its end), it would then be 25% off on Thursday, 50% off on Friday, 75% off on Saturday, and worth 0% once it becomes Sunday.
 +      * Certain projects may not have a late grace period, and the due date is the absolute end of things.
   * All code must compile cleanly (no warnings or errors)   * All code must compile cleanly (no warnings or errors)
     * all requested functions must be implemented in the related library     * all requested functions must be implemented in the related library
     * all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves).     * all requested functionality must conform to stated requirements (either on this project page or in comment banner in source code files themselves).
-  * Executed programs must display in a manner similar to provided output +  * Output generated must conform to any provided requirements and specifications (be it in writing or sample output) 
-    * output formatted, where applicable, must match that of project requirements+    * output obviously must also be correct based on input.
   * Processing must be correct based on input given and output requested   * Processing must be correct based on input given and output requested
-  * Output, if applicable, must be correct based on values input 
   * Code must be nicely and consistently indented (you may use the **indent** tool)   * Code must be nicely and consistently indented (you may use the **indent** tool)
 +    * You are free to use your own coding style, but you must be **consistent**
 +    * Avoid unnecessary blank lines (some are good for readability, but do not go overboard- double-spacing your code will get points deducted).
 +    * Indentation will be rated on the following scale (worth 3 total points):
 +      * 3/3: Aesthetically pleasing, pristine indentation, easy to read, organized
 +      * 2/3: Mostly consistent indentation, but some distractions (superfluous or lacking blank lines, or some sort of "busy" ness to the code)
 +      * 1/3: Some indentation issues, difficult to read
 +      * 0/3: Lack of consistent indentation (didn't appear to try)
 +  * Unless fundamentally required, none of your code should perform any inventory or manual counting. Basing your algorithms off such fixed numbers complicates things, and is demonstrative of a more controlling nature. 
   * Code must be commented   * Code must be commented
     * Any "to be implemented" comments **MUST** be removed     * Any "to be implemented" comments **MUST** be removed
       * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted.       * these "to be implemented" comments, if still present at evaluation time, will result in points being deducted.
 +    * Commenting will be rated on the following scale (worth 3 total points):
 +      * 3/3: Aesthetically pleasing (comments aligned or generally not distracting), easy to read, organized
 +      * 2/3: Mostly consistent, some distractions or gaps in comments (not explaining important things)
 +      * 1/3: Light commenting effort, not much time or energy appears to have been put in.
 +      * 0/3: No original comments
     * Sufficient comments explaining the point of provided logic **MUST** be present     * Sufficient comments explaining the point of provided logic **MUST** be present
 +  * Code must be appropriately modified
 +    * Appropriate modifications will be rated on the following scale (worth 3 total points):
 +      * 3/3: Complete attention to detail, original-looking implementation
 +      * 2/3: Lacking some details (like variable initializations), but otherwise complete (still conforms, or conforms mostly to specifications)
 +      * 1/3: Incomplete implementation (typically lacking some obvious details/does not conform to specifications)
 +      * 0/3: Incomplete implementation to the point of non-functionality (or was not started at all)
 +    * Error checking must be adequately and appropriately performed, according to the following scale (worth 3 total points):
 +      * 3/3: Full and proper error checking performed for all reasonable cases, including queries for external resources and data.
 +      * 2/3: Enough error checking performed to pass basic project requirements and work for most operational cases.
 +      * 1/3: Minimal error checking, code is fragile (code may not work in full accordance with project requirements)
 +      * 0/3: No error checking (code likely does not work in accordance with project requirements)
   * Any and all non-void functions written must have, **at most**, 1 **return** statement   * Any and all non-void functions written must have, **at most**, 1 **return** statement
     * points will be lost for solutions containing multiple return statements in a function.     * points will be lost for solutions containing multiple return statements in a function.
 +  * Absolutely, positively **NO** (as in **ZERO**) use of **goto** statements.
 +    * points will most definitely be lest for solutions employing such things.
   * Track/version the source code in a repository   * Track/version the source code in a repository
   * Filling out any submit-time questionnaires   * Filling out any submit-time questionnaires
   * Submit a copy of your source code to me using the **submit** tool (**make submit** will do this) by the deadline.   * Submit a copy of your source code to me using the **submit** tool (**make submit** will do this) by the deadline.
haas/fall2015/common/submitblurb.1442684229.txt.gz · Last modified: 2015/09/19 17:37 by wedge