This week you will be primarily writing reports about code,
rather than writing new code itself.
All files (java, test data, documentation, etc.)
PART I:
Since the beginning of this course we've mentioned the importance of programming "practice" as well as program correctness (later in the course we'll take up efficiency in a systematic way, too). Exactly what defines "good" programming practice? Sometimes there will be informal understandings, and other times there will be written expectations. An example of the latter are the Sun Microsystem's Code Conventions for Java Programmers.
First, browse that document to get familiar with it. As you do, see if you can spot differences between your own style and what that standard recommends.
Then take a look at a sample solution to Project 2 that we have posted (in the directory above). Go through the solution files (the ones that you had to turn in for the project). Write a critique of the programming practice of those files. That is, point out areas where there are discrepancies, and/or areas where the code of the solution adheres to the standard. Your critique should be between one paragraph and one page in length.
Part II:
We have talked about several ways to document expected program behavior, and to detect and report errors. Look at the code for the package textfile (which among other classes contains the DelimitedTextFile you have used in the projects). In particular, look at where, how, and why those classes use 1) exceptions and 2) asserts. See if you can patterns in where each is used. Write a report (a paragraph to a page in length) describing and critiquing the use of these constructs in the textfile package.
Part III:
Take a look at your own solution to Project 3. Critique it from a coding style point of view (as in Part I). In addition, consider when and how you might have used exceptions and/or asserts in the solution (as in Part II). Write a paragraph or two on each.
Part IV:
Testing is another tool to help achieve good software. Write code to test the Filler class you saw last week in quiz section (code for Filler.java is in the directory). A good test would find any errors that existed in any implementation of the method -- not just the one given! "Finding an error" means the test should stop and announce the problem (with assert usually, although other techniques might be valid). Write your test as a JUnit test case, with all your testing in a static (public) method called testMethod(). (You are free to write other (helper) methods if you wish.) We will evaluate your test by running testMethod against a faulty version of Filler.java. You can find examples of JUnit tests in the directories above (in both the baseball and the textfile packages), as well the the lecture slides.
Write a very short report (1 paragraph suffices) to describe how well you think your test works.
A good test would find any errors that existed in any implementation of the class -- not just the one given! It's not required, but some of you might wish to create faulty Filler.java methods and post them on the Message Board -- good ones. posted early enough, might deserve a sP point!
Hand in the files electronically by the due date at the top of this page.
Note: there are are already four reports in this project -- you don't need to write an additional separate one for the project as a whole! The four reports do not need to be on separate pages, either. Finally, please hand in just ONE report per team. There is no individual report this time.
Get started early and have fun!