Programming Projects

Quick Reference

Grading

The grading system of complex projects differs greatly from that used in entry-level courses and in coding questions in exams:

  • Your code must compile and run!

  • The grader grades your code by running rather than by reading them!

  • A program compiles and runs through GNU make using commands like make, ./main, make test-all, make test-run, etc.

  • You should not expect any partial credits for code that cannot be tested by running your program. The grader do not have the responsibility to read, debug and understand your unfinished source code.

Prerequisites

Project Workflow

Local workflow

  • Open the assignment link supplied by your instructor, accept the assignment, and open the GitHub repository. Classroom 50 is mainly a brief entry point; your normal workflow is in the repository.

  • Create or verify your GitHub account, and add your UWF email under GitHub Settings > Emails.

  • Accept the GitHub organization invitation, then select your exact roster name when accepting the assignment. Never select another student’s name.

  • Clone the repository to your local machine:

    git clone <repository-url>
cd <repository-directory>

  • Iterative Development

    • Write code

    • Run tests or your main to verify the progress

    • Add and commit the changes

    • Push commits when:

      • You have passed some tests

      • You need to put your work on hold

  • Push your work to submit it, then inspect the repository’s Actions tab and latest GitHub Release. Detailed results may appear as result.json.

  • If git push is rejected because your instructor has pushed new commits to the remote repository, first make sure your local changes are committed, then follow the Git rejected-push procedure.

CodeSpaces

Everything is the same as the local workflow except that you are working in the browser. No need to clone the repository or configure GitHub user information. Open the repository on GitHub, choose Code -> Codespaces -> Create codespace on main, and use the browser terminal. Codespaces is especially important for macOS users because valgrind is not supported natively there:

make test-mem

Build, run and debug

Due to the complexity of compiling and running your modular project manually, building tools such as GNU make, Autotools, Cmake, Ninja, Meson are employed to automate the process. We employ GNU make in our course.

Make commands

Make commands are employed to build, run and test your project. Please read the instruction carefully to learn how to use them to run tests or build your project.

Typical targets include:

make clean
make build
make test
make test-1
make test-2
make test-mem

Provided Tests

  • Tests and autograding configuration may be supplied through the starter repository and Classroom 50 assignment configuration.

  • Do not modify or remove provided tests, ``.github`` files, or autograding configuration.

  • Use the correct file names. No Capital letters in file names!

  • Tests are often triggered by make commands like make test-xxx.

  • Run tests locally to test your code.

  • A major portion of grading will be based on the tests runs.

Test Runs

For project that requires an executable as the final product. Make sure to run your main executable to reproduce the sample runs. It can usually be done by make commands like make test-run or make run.

Get Help

  • Post sharable problems on the Discord server

  • Email the instructor or TA about the question. Must include push your code before hand!

Warning

Never ask me question with only limited information like screenshots or error messages.

Avoid Common Mistakes

  1. Avoid over-engineering

    • Understand the problem and requirements very well

    • Work toward a just-enough solution (follow the instruction) rather than a perfect solution

    • Choose the simplest (simple to use) data structures, not the fastest or coolest ones (e.g. choose vector over C array, string over C string)

  2. Avoid bad submission

    • Run make clean before add and commit

    • Remove any added files and directories not needed in the submission. They are usually from your editor or IDE and can be huge in size.

  3. Avoid wasting time on anything not required in the instruction

    • Read instruction carefully

    • Ask questions if you are not sure

  4. Avoid last minute rush

    • Projects are usually more challenging than you think

    • You will not learn much in the rush

  5. Avoid writing code without testing

    • Any project beyond a certain size should be finished in an incremental manner and tested in every step

    • A testing framework (e.g. Catch2) will greatly improve this process but need learning

  6. Avoid working without backing up your code

    • It is common to lose important code snippet by mistake

    • You will hesitate to try new idea

    • Do backup your changes frequently using git add and commit