Purpose

Code submission guidelines are structured to conform to professional guidelines as much as possible to help train the student in professional coding practices. 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. The following guidelines, and classes in general, are designed to simulate real-world software engineering practice as much as possible.

Files Submitted Through GitHub

Most of your work will be submitted this way.

• Your repository on GitHub must be generated by a GitHub Education invite (this will be explained in class). All repos will be private.
• Commit only source code, a .gitignore, and an optional README file unless instructed to do otherwise. The presence of other files will result in a zero.
• Commit everything your project needs to be built. If you use a source code library, include it. In that case commit the library as-is, you do not need to check the library files for conformity to these guidelines. This usually only applies to Web programming.
• Use a proper .gitignore and ensure that no extra files are present in the repo. Do not commit any of the following:
  • IDE Project files
  • Executables
  • Data files (unless directed to do so)
  • Stray files such as MacOS files.
  None of those belong in a repo. If your repo contains any stray files/directories your assignment will not be accepted.
• When you submit, you will submit your GitHub repo url according to the following:
  • Do not use the comment feature to submit. 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 braches, or files, or anything else.
    

Files Submitted Through Blackboard

This will be rare. Most assignments will use GitHub.

• Source code will almost never be submitted through Blackboard, it will be submitted through GitHub. However, if there is a special case to submit through Blackboard, submit only source code files. Do not submit any other files except source code. Do not submit shell or other output. Do not submit data files.
• One File Submissions If your submission is one-and-only-one file, for example a pdf or image file, just upload that file directly.
• Multiple File Submissions If your submission is more than one file, put your code files in a zip file and submit the zip file through Blackboard.
  • 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. 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, 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 (if you choose to resubmit). 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. Do not submit the day an assignment is due and expect it to be graded in time to resubmit the same day. That might happen by luck, but don't count on it.
• 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 may work in any project environment, a command prompt environment, or any custom environment and operating system of your choosing.
• You may use any developer tools you wish to complete assignments. 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.
• You may use any research or "answer" sites such as Stack Overflow (highly encouraged). Sites like W3Schools are not forbidden, but are highly discouraged as they are not a reliable resource and are not suitable for professionals (if in doubt, ask). You may collaborate with fellow students and/or tutors with the following caveats:
  • Most of the code must be original and yours.
  • You may not simply cut-and-paste, but you are free to share and borrow techniques from each other with mutual explicit agreement.
  • If portions of your code resembles another student's, or any other source, you will be asked about it. So long as 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.
• You may use generative AI such as ChatGPT, but you are responsible for what you submit, if it's wrong, it's wrong, and it's your responsibility.

Minimum Compilation and Runtime Standards

These requirements seem very strict, however these standards are very easy to achieve and are part of learning proper professional developer testing.

• All programs must compile (C/C++) or interpret (Web and Python) without error or warning. If there is an error or warning in compiling or interpreting, your assignment will incur substantial penalties, up to and including a 0. This includes any errors or warnings in the console in a Web browser for Web applications.
• 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 this will likely result in a substantially reduced grade up to and including a 0. This requirement is somewhat relaxed in the first 1/3 of Programming I and Beginning Web Programming but is held strictly in subsequent classes/assignments.
• All programs must run without fatal runtime errors. Runtime errors will likely result in a substantially reduced grade up to and including a 0.

Web Programming Additional Requirements

• If your assignment has warnings or errors in the console on any page for any reason, it will incur a substantial grade penalty up to and including a 0.
• Your "main" file (aka the home page or the "driver" must be named index.html or index.php and be in the root of project.
• Your primary CSS file must be named main.css. Name any additional CSS files whatever is appropriate for your application.
• If you have more than one CSS file, all CSS files must me in a 'css' directory. If you only have one CSS file, it can be in the root of your project with your index file.
• Your primary JavaScript file must be named main.js. Name any additional JS files whatever is appropriate for your application.
• If you have more than one .js file, all .js files must me in a 'js' directory. If you only have one js file, it can be in the root of your project with your index file.
• Include all assets needed to make your site run (e.g. images, JavaScript files, css files, etc.). Do not in include any files not needed.
• All images must be in an images directory, even if you only have one image.
• Do not include any files larger than 512 KB (.5 MB). All images must be less than 512 KB (.5 MB) in size. Do not use or include any videos.
• Do not hot link to any images, you must use local images.

C/C++ Additional Requirements

• Your program should compile at the command line, under Linux, with the following command: g++ -I ./ *.cpp. If you prefer an alternate g++ command because of unique directory structures or other considerations, that is up to you, but in that case you must supply that command with your submission in your comment headers or supply a makefile. If you do not supply the compile command or a makefile, your submission will receive a zero.
• 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 dependant. "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. For example, when you run an app on your phone or an application on your computer, do you start an IDE first, load the application in the IDE, and then press "Run?" Of course not. The only true test of an application is to run it like it will be run when it's deployed - on it's 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 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.