haas:fall2015:common:submitblurb
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| haas:fall2015:common:submitblurb [2015/10/10 14:45] – [Submission Criteria] wedge | haas:fall2015:common:submitblurb [2016/09/06 10:52] (current) – wedge | ||
|---|---|---|---|
| Line 17: | Line 17: | ||
| * 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 | + | * Output generated |
| - | * output | + | * output |
| * 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** | * You are free to use your own coding style, but you must be **consistent** | ||
| Line 32: | Line 32: | ||
| * 1/3: Some indentation issues, difficult to read | * 1/3: Some indentation issues, difficult to read | ||
| * 0/3: Lack of consistent indentation (didn' | * 0/3: Lack of consistent indentation (didn' | ||
| + | * 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" | * Any "to be implemented" | ||
| Line 41: | Line 42: | ||
| * 0/3: No original comments | * 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), | ||
| + | * 1/3: Incomplete implementation (typically lacking some obvious details/ | ||
| + | * 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/ | * Track/ | ||
| * 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.1444488322.txt.gz · Last modified: 2015/10/10 14:45 by wedge
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
