Purpose

Code submission guidelines are structured to conform to professional software engineering practices as much as is reasonable for an academic setting. The purpose of these guidelines is to train the student in professional coding practices to better prepare them for a career in software development. All code submitted must conform to the following guidelines. Failure to do so will result in your submission being penalized, up to and including being rejected and an assigned grade of zero.

See grading guidelines for details regarding grading.

Use the code submission checklist along with these guidelines to ensure your code meets best practices and requirements for submission.

Files Submitted Through GitHub

Most of your coding work will be submitted this way.

• Your repository on GitHub must be generated by a GitHub Education invite. No other repos are accepted.
• Commit only source code, a .gitignore, and a README file unless instructed to do otherwise.
• Commit everything your project needs to be built. Do not commit any files that are not needed to build your project except a README and .gitignore.
• Use a proper .gitignore and ensure that no extra files are present in the repo. Never commit any of the following:
  • IDE Project files
  • Executables
  • Data files (unless directed to do so)
  • Stray files such as MacOS files.
• Submit a proper README file with your project. The README file should contain the following:
  • A brief description of the project.
  • Instructions on how to build and run the project.
  • Any special instructions for the project.
  • Any special requirements for the project.
  • Any special dependencies for the project.
  • Any special notes for the project.
• When you submit, you will submit your GitHub repo url according to the following:
  • Use the write submission feature.
  • Do not submit SSH links or .git links or links to branches. Submit the URL from your browser window which points to your repository as a whole, not branches, or files, or anything else.
    

Files Submitted Through Blackboard

• If your submission is one-and-only-one file, for example a pdf or image file, just upload that file directly.
• If your submission is more than one file, put your files in a zip file and submit the zip file through Blackboard.
  • If your submission is code, then the same rules apply to the zip file as applies to repos. Code only, no stray files, no executables, etc.
  • Do not include top level directories. See Images Below
  • Mac users, if your zip files contain MacOS files, your assignment will not be accepted. You cannot see these directories and files normally on a Mac. You have to use a 3rd party zipping tool, or you have to zip at the command line (preferred). To use the command line: zip -r dir.zip . -x ".*" -x "__MACOSX"
    
    
  • Examples (click to enlarge)
      

File Names

• Use only lowercase filenames without spaces or "strange" characters (this applies to zip files as well). The only allowed characters are a-z, 0-1, dash, underscore, and one period for the extension.
• All files will be run, viewed, compiled/interpreted on Linux. Linux (and Mac) is case-sensitive. If you mix cases between resource names and calls to that resource, it will not work on Linux and you will receive a zero for that assignment. Examples:
  • Web Programming: If you use an image tag like this:
    <img src="image.jpg">
    but your actual file is named Image.jpg, your image link will break on Linux (note the lower and uppercase "i" in the file name).
  • C/C++: If you use an include like this:
    #include "functions.h"
    but your actual file is named Functions.h, your include will break on Linux (note the lower and uppercase "f" in the file name).
  • Python: If you use an import like this:
    import MyLibrary
    but your actual file is named mylibrary.py, your import will break on Linux (note the lower and uppercase "m" and "l" in the file name).

Due Dates and Re-submissions

• All assignments are expected to be submitted on time by 11:59 pm of the due date (usually a Sunday night).
• You may submit any assignment a TOTAL of TWO times total BEFORE the due date. Assignments are generally graded daily (but not always). If there are errors you will be given feedback to improve for a second attempt. To be able to resubmit you must submit the first time several days early so there is time to get a grade and feedback, fix your work, and resubmit before the due date. If you do this properly, you are likely to get 90%+ on all assignments.
• Late penalties are as follows:
  • Up to 24 hours: 20% off the top.
  • 24 to 48 hours: 30% off the top.
  • Over 48 hours: Assignment will not be accepted.
  
  

Developer Environment and Tools

• You will be given requirement for parts of your environment, for example which compiler/interpreter to use, virtual environments, version control.
• Anything not specified is up to you.
• You may use any developer tools you wish to complete assignments, unless otherwise specified. This includes but is not limited to:
  • Text Editors such as Notepad, Notepad++, Emacs, VIM, etc.
  • IDEs such as PyCharm, WebStorm, CLion, Visual Studio, Netbeans, etc. You are highly encouraged to get a Jetbrains academic account and use any IDE appropriate for your class.
  • Code checkers, memory checkers, debuggers, etc.
  • AI tools such as Copilot, ChatGPT, or Gemini. See the generative AI statement for more guidance.
• You may use any research or "answer" sites such as Stack Overflow. You may also collaborate with fellow students and/or tutors with the following caveats:
  • Most of the code must be original and yours.
  • You may not simply copy-paste, you must understand the code and make it conform to class guidelines.
  • If portions of your code resembles another student's, or any other source, you will be asked about it. If you can demonstrate an understanding of it, and you can intelligently explain why you used the code, you're okay. If you cannot do this, you will be required to redo the assignment on your own or risk a grade of zero.
  • Be prepared to discuss any of your submissions in class.

Minimum Compilation and Runtime Standards

• All programs must compile (e.g., C/C++) or interpret (e.g., Python) without error or warning. If there is any error or warning for any reason, your assignment will be rejected (i.e., you receive a 0).
• All programs must perform proper and comprehensive input checking unless otherwise noted. This means programs must account for all possible user or file input errors and gracefully handle such occurrences. If your program crashes or unexpectedly exits from incorrect input your assignment will be rejected (i.e., you receive a 0).
• All programs must run without fatal runtime errors. Runtime errors will result in a grade of 0.

C/C++ Additional Requirements

• Your program must compile at the command line, under Linux, with the following command: g++ -I ./ *.cpp. Do not structure your code in directories unless specifically instructed to do so.
• In Windows DOS, the command would have the .cpp files expanded like so: g++ -I ./ main.cpp functions.cpp myclass.cpp
• Programs run in the school labs may require C++ version 11 in which case the following command applies. g++ -std=c++11 -I ./ main.cpp functions.cpp myclass.cpp
• If your program does not compile and run at the command line under Linux with g++ (without errors or warnings), it will incur a substantial grade penalty up to and including a grade of 0.
  
  This does not mean you must run Linux. This does mean code must conform to standard C/C++ GNU guidelines and not be OS dependent. "It compiles on my machine" or "it works on my machine," are not an acceptable answers to programs that do not compile and run under Linux. Errors when compiling or running at the command line versus compiling and running in an IDE will most commonly manifest when you only use the "run" command in a project IDE environment. Real world programs don't run in an IDE! Ensure your program compiles and runs outside the IDE as would any professional code (see below). Before submission, you should always compile and run multiple times from the command line. This will be explained further in class.

General statement on IDEs

Do not only press "Run" in the IDE to test your code. Real world programs do not run in an IDE. When you run an app on your phone or an application on your computer, you do not start an IDE first, load the code in the IDE, and then press "Run." You just use the stand-alone application. The only true test of an application is to run it like it will be run when it's deployed—on its own.

An IDE creates an artificial environment by putting a layer between your application and the operating system (i.e. your application is a child process or a fork of the IDE). This can mask errors, especially memory access and file structure errors. Only running stand-alone at the command prompt can tell you if your program really works. For convenience, you can press "Run" to test your code as you're coding, but as a final check, you should always run your application stand-alone several times before submitting.

Your code will be graded by running at the command prompt, and it will be run no less than 10 times. If you don't do the same to test your program, do not be surprised when you get a grade of 0.