| Assignment • FAQ • Development Guide • Code • Checklist • |
Question:
Does returning null somehow stop the program, or does it just make the function call invalid?
Answer:
Returning null will not stop the program. null is often an indicator that the function that you called did not complete successfully. This return value allows the caller of the function to check the return value and make a decision as to what to do next. Most methods don't cause your program to exit if a methods call fails.
All the programs in the class will return through the main program.
Question:
When writing the code for "pop", what does the space in the array that previously held the value of the number being popped get assigned?
Answer:
Since your stackpointer holds the index of the next available space in the stack, it doesn't matter what are the values within the stack for spaces that are unused (or previously used).
Question:
I was running your program, when I hit Control D, ^D appears and then you break out. But when I was running my program, and I hit Control D, it says "Stack Deleted" and then breaks out. Is that wrong? Thanks.
Answer:
Yes, that is wrong. Your program has extra output. Are you displaying "Stack deleted" at the end of your delete_Stack methods? If you were trying to insert that message for display by your driver program, then that output should come from your Driver.java code. The stack code should not display any non-error output to the user.
Question:
Before executing any method from LongStack.java, we have to do our validity checks, such as seeing if the stack exists or if the stack is full, etc. Do we embed these validity checks inside of the method definition, or inside of the case statement before the method call?? I've included the validity checks inside of the method definition and if the stack doesn't exist, I print a statement saying that tha stack doesn't exist and return a 0.
How would I properly format this if I can't add code to Driver.java?
Answer:
In general, you should think of the driver code as disposable. We only have it there to test our object/data structure. As such, all the validity checks need to be inside of the data structure code, itself.
Although the driver does check the return values of the method it calls and displays error messages accordingly, you'll notice that you'll also get an error message that is generated directly from the object/data structure code, itself.
Once your stack is working, when you try to use it in your calculator in hw4, these messages are much more helpful than just a core dump in trying to resolve your problem.
As the course progresses, you'll find that although these data structures are very powerful, they are also sometimes fragile. Debugging them will be difficult. Often times, the core dump will come many lines after your initial error of popping from an empty stack or pushing to a non-existent stack. Sometimes, no core dump will occur; instead you just don't get the expected results.
Producing error messages when your validity checks detect problems goes a long way to save you time in diagnosing your problem to guide you towards resolution.
Question:
Can you tell us how much in line commenting you expect?
Answer:
The simplest guideline I've ever been able to come up with for my own commenting is: "A reader must be able to know generally what my program does without reading a single line of code *or* the assignment handout." That doesn't mean you have to write a novel, but it does mean there should be some good information packed in there.
Realistically, you should be commenting as you write your code. This is in much the same vein as the debugger statements we require -- commenting forces you to translate your code into plain english. If you take the time to do it right, the translation process will help cement in your mind the logical flow that your program is supposed to take. Furthermore, if you're writing comments based on the code you actually wrote (rather than what you think it's supposed to do), you'll often manage to catch little mistakes that would have caused you grief while debugging (like off-by-one errors, useless code, places where code could be made more efficient, etc.). The point is, the level of detail should be a natural extension of how closely you check your own code. No matter how you look at it, you're going to have to comment sooner or later, because we require it. In that situation, you might as well get into the practice of automatically commenting as you code -- it's just as quick to comment while coding as it is after the code is written, and doing so may well save you time debugging.
| Assignment • FAQ • Development Guide • Code • Checklist • Star Point |