Testing, Debugging and Documentation

Running a program once with the numbers you had in mind while writing it proves almost nothing — of course it works on those. Testing is the deliberate search for inputs that break the program, and it is a planned stage with written cases and expected results decided in advance. Almost every logic bug lives at a boundary, because a boundary is exactly where < and <= disagree, and they disagree on precisely one value. Test with 73 and both versions pass; test with 100 and only the correct one does.

Treat the three types as a diagnostic routine rather than a list to memorize. Did it refuse to compile? Syntax — read the first error message only, because later ones are often knock-on effects of the first. Did it start and then stop? Runtime — read the stack trace, which names the fault and the exact line. Did it run cleanly and produce the wrong answer? Logic, and now you need a trace table: one column per variable, one row per pass, filled in by hand, executing the code exactly as written rather than as intended. The moment a row disagrees with the value you expected, the bug is in the statement you just executed.

int[] data = {3, 7, 2};
int total = 0;
for (int i = 0; i < data.length; i++) {
    total += data[i];
}
System.out.println(total);

When a Java program throws, it prints a stack trace. It looks intimidating and it is actually a gift: it tells you the exception type, a message, and the exact line of the exact file where the program stopped. Read it top down — the first line is what went wrong, the second is where, and each line after that is the call that led there, so the last line is usually main. The message itself carries both numbers you need: "Index 5 out of bounds for length 5" says what you asked for and what was actually there, and when those two numbers are equal the cause is nearly always a loop condition using less-than-or-equal instead of less-than.

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 5 out of bounds for length 5
    at MarkReport.average(MarkReport.java:18)
    at MarkReport.main(MarkReport.java:7)

Maintenance is the longest stage of the life cycle, and the person doing it is usually reading the code cold. Four conventions do most of the work. Name variables for what they hold — passCount, not x or temp2. Indent four spaces per level every time, because inconsistent indentation hides the structure the logic depends on. Use comments to explain why a decision was made, never to restate what the code obviously does. And put a short description above every method saying what it takes, what it returns, and what happens when it fails. Keeping methods short enough to fit on one screen makes all four easier.

// Hard to maintain: nothing here says what any of it is for
int x=0;
for(int i=0;i<a.length;i++){if(a[i]>=50){x++;}}

// Maintainable: the names carry the meaning and the comment explains WHY
int passCount = 0;
for (int mark : marks) {
    // 50 is the reporting cut-off set by the specification, not an arbitrary number
    if (mark >= 50) {
        passCount++;
    }
}

/**
 * Returns the index of the first occurrence of target in arr,
 * or -1 if target does not appear in the array.
 */
public static int indexOf(int[] arr, int target) {
    for (int i = 0; i < arr.length; i++) {
        if (arr[i] == target) {
            return i;
        }
    }
    return -1;
}