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

lab46:~/src/data/PROJECT$ make submit
...

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.