Assignments Procedure for Karl Grabe.

updated 04Oct 2012

Marking Scheme

• Marks are shown on the assigment

General Tips

• When starting out is is better not to write lots of code, compile it to discover lots of compile errors and then when it eventually does compile - it won't run.
• Better to start with something simple that works and compile and run after every small change. "Code a little, test a little".
• Make regular backups of your work to your own media! Don't trust the our servers!
• Keep older versions of your code so you have something to fall back on if something breaks after you make a change (usually the day before handup!).
• Email copies of your assignment to yourself every so often to archive them.
• Use Blackboard to sumbit assigments - NO printouts are required.

Coding Standard

Use a coding standard, here's a basic one:

1. At the top of your program state your name, email address, revision, revision history with dates, and what the program is about.
2. Be well commented including what each method/class you write does. For methods note what inputs and outputs it uses, error codes returned (where applicable).
3. Use conventions such as block capitals for names of  constants or 'k' in front of constant names (e.g. RADIUS or kRadius). Use capitalization to break up words e.g. 'FirstName'. Class names should start with a capital letter, variables and methods with a lower case letter.
4. Use meaningful names for variables/classes/methods. You should use long names but limit to <15. Avoid names that are similar or differ only in case. eg. firstName and FirstName. For classes  start with a capital letter and break works with capitals e.g.  SerialPort, WeightCalculator.  For method and variables start with a lower case letter e.g. customerAddress, calculateAge ( ). For GUI components e.g. Swing put the class name at the end e.g. inputjLabel, ageJTextField.
5. Try to make variables (& possible some methods) 'private' where possible.
6. For later assignments write your own methods and classes. They should be generic where possible so that they can be re-used in other programs in the future.
7. Be maintainable – easy to add new features
8. Avoid using 'hard wired' numbers in for loops, drawings etc. Use constants declared at the top of the program or pass the values into methods
9. If/else, while, for loops - try to limit nesting to max 3 levels (so it's easy to follow)
10. For later assignments consider using customised components and or generic components.

A more comprehensive coding standard is here but is probably OTT for an assignment.

Development Tools

• You can use any development tool you like (Eclipse , BlueJ, NetBeans, JDK etc). Consider using Eclipse as many companies to use it .
• Do NOT use the visual design capabilities for assignments (except Android). All GUI components must be hand-coded and placed on the screen manually or using a layout manager(s).

Documentation

List each item on the assignment e.g. 1 (a), 1 (b) etc on a NEW page and include screen shot of the code and running application.

.

Assignment Demo - On the due date or 1st lab thereafter if you have no lab on the due date

You are required to demonstrate your assignment to the lecturer. If you do not demonstrate it then it may not pass.

For applets: you need to demonstrate the applet running from your CIT web page or your own web page. Test that your applet works in a browser regularly during development. Be able to show the features you’ve implemented and be able to answer questions on how you implemented the features in code. Clearly identify the link to your assignment on your web home page. You may want to add some information about the applet and some instructions for the user.

For Applications/Server side/MIDlet: you need to demonstrate the program running. Be able to show the features you’ve implemented and be able to answer questions on how you implemented the features in code. 

Format of the Demo:

Show your program running and briefly show the important parts working. If you have spent time on an unfinished feature you should mention this at the demo and in the documentaion as you may get marks for it.

You many be asked to make a small change to your program during the demo to demonstrate your understanging on what you have done.

Handup Date

The handup date will be advised by the lecturer and also on the module link on cit.karlgrabe.com. If the submission deadline is missed then the following rules apply - these are from CIT's Marks and Standards document dated May 2010:

"Coursework which is submitted after the submission date will attract a penalty as follows:
-Up to 1 calendar week delay 10% of the marks available for the assessment
-Up to 2 calendar weeks delay 20% of the marks available for the assessment
-Over 2 calendar weeks delay 100% of the marks available for the assessment"

‘Small’ Print:

The assignment must be handed in by the deadline outlined above. The only exceptions will be for documented personal difficulties e.g. you are ill and can produce a medical cert. Give the medical cert to your year coordinator & follow up with an email to me & cc the year coordinator. .

The external examiner may, during the exam board reviews, ask to see what you handed in and may recommend a different mark be given.

The demonstration of your assignment is mandatory - it may fail if there's no demo.

Keep backups of your project as you develop it. System failure cannot be used as a reason for not handing in the assignment on time.

Check the module descriptor. This will give the mark breakdown for the module so make sure you understand the implications of not handing up an assignment or not doing well in an assignent.