Computer Science 365

Spring 2005

Initial feedback

This page is intended to give some tips and overall guidelines when doing your 365 labs.  Much of this can (and should) be extended to your everyday programming practices.  While not everyone has violated these principles, it is still a good idea to peruse the points made.  A lot of this is based upon trends that have been seen in the first three programming assignments.


CODING

Adhere to the principle of simplicity when coding, as the simplest answer is your best.  While some of you may have extensive previous experience with Java, some of the early labs do not require reinvention of the wheel.  They are simply small assignments designed to verify you grasp the concepts presented in lecture and can apply them.  While it is wonderful that you may be versed in some of the more advanced classes Java provides, at this point you should focus on what is needed to get the job done.  Einstein was once quoted as saying "make things as simple as possible, but no simpler."  He had more than a few valid thoughts in his lifetime.

Exception Handling

Exception handling is a key aspect to mastering Java programming.  So far, you have been given exceptions to look for when completing the assignments.  This may or may not continue as the semester progresses, but you definitely will not receive this type of information in "real world" applications.  Make a habit of organizing your code into logical try{...} catch{...} blocks.  Some of you already have comparable habits as far as exception handling, try/catch blocks, etc.  Others have barely gotten by with minimal use of pertinent exception handling.  This is probably the biggest difference noticed yet in the lab submissions.  By the time you submit your completed project at the end of the semester, all of you should have a firm grasp on exception handling.

There are certain exceptions that you should mentally link together with aspects to a program.  For instance, you should always error check command line arguments from all angles (number of arguments, type of particular argument, etc.), regardless if the lab write up requests that you do so.  This extends beyond Java in the sense that by now you should be doing this for any programs you write that involves passing input, regardless of language/architecture.  Another good example is any exceptions that can be caught when processing files (such as FileNotFoundException).  These should be checked without doubt.

As you have been told numerous times before, the online Java API specification should be your right hand in coding in Java, at least until you have become completely comfortable with the language.  Its layout provides a wonderful advantage in the way that each class definition gives related exceptions to look for.  Java is different from C (or even C++) in the sense that for the most part everything is already built for you -- you just have to properly assemble the pieces.  The API specification is your blueprint.


COMMENTING

Good commenting is like a fine art form.  Lack of commenting makes it difficult to impossible for others to maintain, supplement, or even interpret your code.  On the other hand, too much commenting can make it cluttered and hard to discern as well.  A good rule of thumb is each relevant method or class should have a “header” type block comment preceding it, and inline commenting should be done when the purpose of some procedure is not obvious.

Further, some of you have not been including your name on some or any of your source code.  A minimal header should go at the beginning of each file you submit, preferably similar to the form

/* Name: John Doe

Computer Science 365

Lab #: x

Due: February 31, 2005

Description: (brief summary of program involving any input(s), output(s), etc.)

*/

Again, this is to minimize the effort someone has when trying to decipher your product.  With object oriented programming it is often useful to break source files apart into classes.  With larger projects this can result in a plethora of files.  If there is no concise commenting at the beginning, it can get very confusing very quickly.  

The Javadoc approach to commenting Java source files was recently presented to you in class.  While this may seem tedious initially, it is excellent when you come across larger projects (such as the one due at the end of the semester) because of its HTML output.  Play around with some smaller files and formats and make sure you can execute Javadoc properly before you attempt to comment your final project.


TESTING 

The ultimate test of your code is the lab machines.  While one of the perks of Java is its emphasis on platform-independence, you need to be sure that your programs compile as well as run properly on the lab machines.  This is due to several reasons.  First, there has to be a universal rubric for the performance of the class’s work.  For reasons of fairness as well as ease, this is the lab.  Second, working with the lab machines gives you a taste of real world development.  Odds are if you are a software engineer for a relatively large corporation, you will not necessarily serve as system administrator.  Thus, you have to learn to cope with the provided tools (or submit requests to get the desired ones installed).  Feel free to create and test your code in whatever development you desire.  Just be certain it runs flawlessly (or as well as you deem fit) on the Cetus or Hydra machines.  The bottom line is that if we cannot compile or run your code, we cannot give you credit for execution-related aspects to grading, regardless of how simple the mistake is.  After all, you would not expect to purchase a meal from a restaurant uncooked and pay for it.  Think of your points as pay for your work.


SUBMISSION

Only submit exactly what is needed to compile and run your program.  There have been countless times that people have submitted with either Java .class files of extraneous files with their submissions.  Although these files may or may not affect testing and execution, they sometimes added an unneeded layer of complexity when trying to evaluate what does what.  A good practice is to have a subdirectory of that particular lab's directory specifically for submission.  That way you can keep all of your test files, potential .class files, etc. separate from what you submit.