Skip to main content

Grading and Submission

Please read this section carefully so that you fully understand the grading scheme and the mode of submission for the problem sets.

In this module, you are being trained to become a good software engineer. At the bare minimum, your code must correctly satisfy the requirements stated in the problem sets. Above and beyond that, you are also required to write well-documented code. In real world software projects, simply ensuring that your code does its job is not sufficient, because the code has to be maintained, be it by you or by other people in the future. The probability that someone else will have to read and understand your code is very high, and chances are that they have to modify it too. What sets a mere programmer apart from a quality software engineer is the ability to minimise the grief of the person going through your code, and even better, to make them love it. In the context of the problem sets, we are specifically talking about the graders who will be grading your work.

Problem Sets Weightage​

Each problem set has varying total scores, not necessarily corresponding to the amount of time and effort required. One point has the same weightage across all the problem sets, which together add up to 440 points.

  • Problem Set 0 (ungraded)
  • Problem Set 1 (50 points)
  • Problem Set 2 (130 points)
  • Problem Set 3 (130 points)
  • Problem Set 4 (130 points)

For the entire CS3217, here is how the scores combine:

  • Problem Sets: 44%
  • Tutorial Participation: 6%
  • Final Project: 50%

Grading Scheme​

For problem sets that involve running of private test cases (Problem Sets 1), the graders will be running them via Xcode using the iOS Simulator. For the Peggle problem sets (Problem Sets 2, 3 & 4), playtesting will be conducted on the iPad.

As a general rule across all the problem sets, the graders will be looking at the following:

  • Your submission should adhere to the submission format.
  • Your project should build without errors or warnings.
  • Your project should run without crashing.
  • You should have implemented required features.
  • Your code should not include third party libraries and code snippets.
  • Your code should be well-documented and understandable.
  • Your code should be written neatly with a consistent coding style (e.g. indentation).
  • Your code should follow good naming conventions, and not use magic numbers or strings.
  • Your tests should be well-designed and should not have failures.
  • You should have answered all the written questions in the problem set in README.md. Markdown allows you to format your answers in a neat and concise manner. Refer to Markdown Cheatsheet if you need a quick refresher.

The Official raywenderlich.com Swift Style Guide is the recommended style guide for this module, with the slight modification being we prefer 4-space indentation to 2-space indentation.

To help you maintain a high coding standard in your problem set, we also provide a SwiftLint configuration file in your assignment repository. You are encouraged to set up SwiftLint in your Xcode project and follow this configuration. Keep in mind that, ultimately, this tool is only a guideline; some exceptions may be made as long as code quality is not compromised.

Plagiarism​

Plagiarism is a serious academic offense and will not be tolerated. You should not recycle any solutions found on the Internet.

Not only it is not fair for your peers, but it is also detrimental to your learning. Many of SoC students become a software engineer, and learning proper software engineering practices is very helpful to that path.

Mode of Submission​

For all problem sets, you will be using GitHub for submitting your code and receiving feedback. We will create repositories with skeleton code for each of the problem sets for you.

Please familiarise yourself with Git as you will be using it as the version control system to track progress on your source code as well as to submit your work. Git will also be used for collaboration with others on the final project. You can try the short crash course by GitHub at https://try.github.io.

As you work, your Xcode project will grow to contain files which are user-specific and should not be committed in a version control system. You can tell Git to ignore files by writing their definitions in a .gitignore file located in the root of the Git repository. This has already been done for you, and the definition we have used is taken from GitHub's Swift gitignore.

Note: Please ensure that all the required files for the Xcode project remain in the repositories. The tutors should be able to clone the entire repository as is, import it into Xcode, and run your solution without making additional changes.

As a nice gesture for the tutors, please also give details in the README about the various files that contain the main bulk of your code, and any special notes for browsing your code directory.

You will be graded on the latest commit pushed to the GitHub repository before the given deadlines, at 11:59pm. You will be deducted 10% of the corresponding Problem Set's total marks for each day the submission is late. For example, if you submit Problem Set 2 at 12:07am the next day, you will be deducted 13 points. Punctual commits but late pushes are also considered late submissions. (We can actually check your last push time!)

Bonus Points​

After you finish a problem set, please spend a few minutes to reflect on a few questions for a few bonus points! The links to the questions can be found at the end of each problem set. These bonus points can only be earned within 24 hours after each problem set deadline, so do remember to submit your reflections on time!

Last updated on by Phillmont Muktar