Please hand this project in as a folder named "final". Your final folder should include all your .java files plus a file named "readme.txt". The readme.txt file should include your name(s), an explanation of how to run the program (which class has "main", what the command-line parameters are, etc.), a discussion of the current status of the program (what works, what doesn't), and anything else you would like me to know.
You may work alone or with one other person from the class.
The takehome exam will include a question asking you to provide a description of your final project and an incremental development plan (like the list of project phases I suggested for the word-counting program). Take that question seriously, because it will help you get off on the right foot with your project.
At its simplest level, a spell checker is a program that takes input from two files (a dictionary of correctly spelled words and a file whose spelling is to be checked), and produces a list of words from the second file that do not appear in the first file. If you choose this final project, your job will be to write a spell checker.
Your program should ask the person using it to specify a dictionary file and a file whose spelling you want checked. You may assume that the dictionary file consists of an alphabetized list of lowercase words, one word per line. (See /Accounts/courses/cs117/ondich/words.txt for a large example of such a file, but you might want to create your own small dictionary file for early testing of your code.) After the person has specified the files, your program should print out (to System.out) a list of incorrectly spelled words, along with their line numbers. For our purposes, "incorrectly spelled" is synonymous with "doesn't appear in our dictionary file."
That's the minimum spell checker, and if you choose this project, you must write a program that does the job described in the previous paragraph. However, there are many ways to enhance your program (see the Ambition item in the Grading Criteria section below). For example,
Try to think in object-oriented terms. For example, you should have a class that represents the dictionary, with suitable methods for loading the dictionary into memory and searching for words in it. By giving the dictionary class responsibility for the detailed manipulations of the dictionary, you will make the rest of your code easier to read, write, and debug.
Here's a file of about 80,000 words for you to use as a dictionary file, if you wish.
As you know if you have ever used Adobe PhotoShop or viewed a photographic hoax, there are many interesting ways to manipulate photographs. Last week's EzImage lab gave you a very small introduction to pixel-by-pixel photographic manipulation. For this project, you will use EzImage to do more.
Your job will be to create a menu-driven program that offers people several choices. At minimum, you should offer a person using your program the following options:
Your program's menu of options should appear in the Terminal window, and after each operation, a new image window should appear on screen showing the current working image. A good organization for your main program would be something like this:
Initialize while( the user hasn't selected Quit ) { print the menu get the selection from the user perform the operation display a new image window } Clean up (maybe ask whether the person wants to save the modified image?)
The list of options above is what I would like to see from anybody doing this project. Note that several of the options are things did for the EzImage lab, but in a slightly new context. If you would like to make your program more sophisticated, there are many more operations you can offer people. For example:
If you have a project you are eager to work on, prepare a short description of your idea (no more than one page), and deliver it to me in person or via e-mail by noon Friday, November 11. I will let you know quickly whether I consider your project appropriate as a final project for this course.
Does it compile? If not, I can't test it, and thus I can't grade it.
Does it work? Correctness is the most important thing, though by no means the only thing. Your program should work. If it doesn't do exactly what it was intended to do, you should provide a discussion of that fact in your documentation.
Is it well organized? We will talk in class about principles to use when designing a class. Think about those ideas as you develop your code.
Is it well documented? Your code is a piece of writing directed to two audiences--human readers and compilers. You need to make the code readable to both of them, and clear commenting is an essential part of what you do for your human readers.
Is it written with good style? Descriptive variable/function/parameter names, consistent indentation and placement of braces, and appropriate comments are the fundamentals of good coding style.
Ambition. If two projects are well documented, functional, and exhibit good style, the one that does a more interesting or ambitious thing is likely to get the better grade. That said, a really outstanding basic spell-checker with no extra frills still has a shot at an A.
Start early, have fun, and keep in touch.