======DATA======

=====Project Submission=====
When you are done with the project and are ready to submit it, you simply run **make submit**:

<cli>
lab46:~/src/data/PROJECT$ make submit
...
</cli>

=====Submission Criteria=====
To be successful in this project, the following criteria must be met:

  * 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.
      * 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 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).
  * Output generated must conform to any provided requirements and specifications (be it in writing or sample output)
    * output obviously must also be correct based on input.
  * Processing must be correct based on input given and output requested
  * 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
    * 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.
    * 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
  * 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
    * 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
  * 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.