David Newton wrote:I'm not sure I would have made separate arrays for the priorities--most likely I would have simply made the priority a part of the object. It also seems to be recursive, which I'm pretty sure isn't your intent (for example, selectionScreen() calls prompt() which calls selectionScreen() etc. It'll take awhile, but eventually you'll run out of memory and crash.
The checkActivityArray() method seems to basically repeat large chunks of code. Any time you find yourself using "paste" as a programming paradigm it's time to re-think and re-factor.
seetharaman venkatasamy wrote:1.Use LogWriter instead of System.out.println()
Check method parameter before using them
Harshit Rastogi wrote:
Change this to
you should always use the interface class . Thats a good practice. Because if in case you want to change it to Vector simply change the implementation
Rob Prime wrote:Suppose you find that Priority4 gives you problems. You debug a bit, and find it is a threading issue - two threads are adding elements at the same time, and the ArrayList breaks. You think: I should synchronize the ArrayList! Big problem: now you have to change all points of access to the ArrayList. Auch!
Now, let's say you declared the field as List. Now all you need to do is change just one line of code:
Or, a method I prefer:
And voila! All access to Priority4 is now synchronized*.
* When using an Iterator you should still synchronize manually:
Still, much less code needs to be changed.
Fred Hamilton wrote:I'm gonna nitpick on something that doesn't really affect functionality, but may affect readability.
Give some thoughts to the names you give your Boolean variables and methods. IMO they should be more suggestive of yes or no answers or true/false answers
So instead of things like Boolean importance and Boolean urgency, you would have things like Boolean isImportant and Boolean isUrgent.
if( activity1.isImportant ) sounds better to me than if( activity1.importance ) , see what I mean?
Campbell Ritchie wrote:I would only suggest using html tags in the documentation comments, which are supposed to be translated to html anyway. There are some Swing components which support html too.
The \n character is not an html tag, and since Java5 it has been far better to use the %n tag which obtains the platform-specific line separator than \n.
Campbell Ritchie wrote:The only bit of Java which usually uses HTML is the documentation comments. You don't need HTML to write Java. You can write documentation comments without knowing any HTML. You can create 99.99% of any GUIs without knowing HTML.
If you wish to execute an applet you will need a 3-line HTML document, which you can more or less copy out of the books.
There are a few GUI components where you get a better-looking text display with HTML. Your documentation comments are converted into HTML, which looks better if you put a few tags in. It will take ages to learn the amount of HTML you would actually use for Java programming, at a rough estimate maybe half an hour .