Skip to content

Introduction

Assignments

Late Submissions

Late submissions will be reduced by one letter grade (1 point off 4-point assignments; 2 points off 8-pouint assignments) for each DAY (or partial day) late (no exceptions without timely prior coordination with the instructors). See the grading policy for assignment grading details.

Note

If you expect any issues with turning in work on time, please contact the instructor as soon as you know. If I know in advance about travel, expected high workloads or other issues, I can work with you. However, letting me know a day or two before an assignment is due is not acceptable (If an emergency occurs, please let me know as soon as possible afterwards.)

Note

If you encounter issues while trying to submit your assignment, please immediately send me an email with your submission zip and a note stating that Canvas is being your best friend. If you submit in this manner, I will not count your submission as late.

Note that the easiest way to get a lower grade is to turn in your assignments late. If you know that something is coming up (business/vacation travel, expected very busy week at work, medical, expected baby) please let me know and I'm happy to work with you.

Commit Often!!!

Note: I highly recommend that you store your code in a version control system such as git. However, if you host your project on a public site like github, gitlab or bitbucket, you must make the repositories private! Any non-private repositories that I find online will automatically set your grade to "F" for sharing code.

Be sure to control your source code! Lost code will not be accepted as an excuse for late or missing assignments.

General guidelines for grade ranges

These are general guidelines, not absolute descriptions of a grading level. Your overall grade on an assignment depends on the overall quality and functionality of your submission. Again, these are general guidelines. You can get lower grades for very significant problems in your submissions and very late submissions.

Letter Grade Common Reasons for the Grade
A On time AND
Working AND
Good design
B Missing required functionality
Not quite working
Bad design/bad style
One day late (but would have otherwise been an "A")
C Many missing functions
Will not compile
Will not execute properly
Very bad design
One day late (but would have been an "B")
Two days late (but would have been an "A")
F Little apparent effort
Plagiarism
Three or more days late
Not turned in

I grade on the following aspects of your submissions. Note that there is no specific percentage allocation for each of these concepts.

Aspect What I Look For
Design Does the design use the patterns discussed in class properly?
Does the design fit the problem?
Is the program designed with a maintenance programmer in mind?
Can I determine why you did things the way you did by reading code and comments?
Function Is all required function present?
Is any non-required function present? (grade deduction)
Does present function work properly?
Style and Coding Conventions Is the code readable?
Can I easily figure out what it's doing just by reading the code?
Does the code follow the required coding conventions?
Note: Not following the required coding conventions, even once in a submission, maximizes your assignment grade at A-
Timeliness Was the assignment submitted on time?
one day late = 1-point grade deduction
two days late = 2-point grade deduction
...

Note

I expect your assignments to follow the approaches I demonstrate in the class examples. When I see other approaches in your submissions, it sends up warning flags for me that you may be plagiarising (I've caught several students this way). I'll spend a good bit of time examining your code and online code that feels similar. Sometimes I'll notice approaches that I used to teach in previous terms, and then find a previous-student submission that matches.

Please make my grading easier and your grades safer - follow the class example approaches and don't copy code from other students in previous or the current class sessions.

Violation of the academic integrity policies will result in a minimum penalty of a 0 for the assignment in question, but there could be higher penalties depending on the circumstances.

Coding Conventions

All assignments must observe the following coding conventions.

Why? I read your code

Sometimes your code doesn't work correctly. Before I decide on the grade to give you, I carefully read the code to try to figure out why it didn't work. If the reason is a small, subtle thing, I'll often give more credit (rather than simply saying "doesn't work; you get a C") I often have to do this for multiple assignments. If the code is readable, using meaningful variable, method and class names, I can often find the problems more quickly.

  • Indentation must be consistent. Use either leading spaces or tabs, but not both!

  • All type names must follow Upper-Camel Case:

    • ShoppingCart
    • ObjectDrawingApplet

  • All variable and method names must follow Lower-Camel Case:

    • drawObject()
    • numberOfObjectsOnScreen

  • Type, variable and method names shall be a series of full words, not abbreviations or single letters.

    • Standard acronyms are acceptable (such as url or http), but names like c are generally not acceptable. If you aren't sure whether a name is acceptable, feel free to ask me, but remember the rule of thumb: it should sound exactly like what it's being used for.
    • Some Exceptions (based on common, understood usage)
      • integer counters in loops can be named i, j, k
      • the "current number" for walking through an array or counting items can be n
      • e for an exception in a catch block

  • All classes and interfaces must be contained in a Kotlin package

  • All Kotlin package names must be completely lower-case and start with lastname.firstname.hw# where the # is the homework number. For example, I might have a project named stanchfield.scott.hw4 (with the same Android package name) that contains Kotlin packages:

    stanchfield.scott.hw4
stanchfield.scott.hw4.model
stanchfield.scott.hw4.database

  • All projects must be named HW1, HW2, HW3 and so forth

  • All submission zip files must be named lastname.firstname.HW1.zip, lastname.firstname.HW2.zip, etc

  • All string literals that would appear for the user (typically text in TextViews, dialogs, toasts, etc) must be externalized into the strings.xml file. This is a really good habit to get into upfront, and you should always do this in any application you create to make localization simpler.

Note

This means all user-facing text. Any string constants that the user could see, whether used in your XML files or Kotlin code, must be externalized.