It's UWAweek 17 (1st semester, week 8)

help2005

This forum is provided to promote discussion amongst students enrolled in CITS2005 Object Oriented Programming.

Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.

How do I ask a good question?
Displaying selected article
Showing 1 of 93 articles.
Currently no other people reading this forum.


 UWA week 17 (1st semester, week 8) ↓
SVG not supported

Login to reply

👍x1
helpful
6:29pm Wed 24th Apr, Abdul M.

ANONYMOUS wrote:

I have used comments to describe which method in the superclass I am overriding and the purpose of using the @Override annotation, but I'm not sure if it is necessary to keep repeating this in every file for each subclass. Would this be considered excessive and does it lose me marks in terms of how succinct the overall code is? (clarification: repetition in different files)

Is commenting on something only the first time it's used in the class sufficient, even if it occurs multiple times? For example, explaining the usage of @Override and how dynamic dispatch works. (clarification: repetition within one file)

A previous post advised for comments to 'describe your intent and reasoning on how you implement the requirements', is it beneficial to establish the requirements through the comments then? Such as shown in the below comment. /* Follows class requirements: describe() should represent it as a pair of braces containing no elements: "{}"*/

Also, should field/parameter names be commented on, or are they considered trivial?

Hi. If you think that the comment is repetitive, you can omit it on the other classes.

However, I suggest you commented some of the algorithms that you implement by your own. For example how to check whether an Union or Intersection contains certain element. I found that some students are unable to grasp the idea how to check it.

The field/parameters should be trivial if you follow the requirements. For example, in the Range class there are upper bound and lower bound property. If you named your variable as upperBound and lowerBound respectively, then it is trivial.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  5:07AM Sep 06 2023
Privacy policy