AP Computer Science A common mistakes
AP Computer Science A · Understand the traps and how to avoid them.
Calling a mutator such as list.add(x) or builder.append(x) and then ignoring the returned value, or conversely assigning the result of a mutator (String result = s.toUpperCase() is fine, but treating list.add as if it returns a new list is not).
Students memorize 'methods return things' and blur the distinction between immutable objects (String, Integer) where methods return a new object, and mutable collections where mutators change the receiver and return void or boolean.
What to do instead
Before writing a call, classify the receiver: if it is String or a wrapper class, the method returns a new value you must capture; if it is ArrayList or StringBuilder, add/remove/append mutate in place. Practice by writing one line that reverses a String with StringBuilder and one that does it with String concatenation, noting which needs reassignment.
Using == to compare two String objects for equal text, or two Integer objects, and expecting true when the contents match.
== is taught early for ints and works there, so students transfer it to objects without internalizing that == compares references for object types. Autoboxing of small Integers (cached -128 to 127) sometimes makes == appear to work, reinforcing the error.
What to do instead
Adopt the rule: primitives use ==, objects use .equals(). When comparing an Integer to an int, unboxing makes == legal but write .equals or compare via intValue() deliberately. Drill with String a = new String("hi"); String b = "hi"; and predict a == b versus a.equals(b).
Writing a while loop whose condition can never become false because the variable updated inside the body is not the one tested in the condition, or the update is inside an if branch that may not execute.
Students translate 'loop until done' directly into code and update a counter or index in a branch rather than unconditionally at the end of the body, so some paths skip the update.
What to do instead
For every loop, identify the loop-control variable and verify it is modified on every path through the body. Place the update as the last statement of the body unless the algorithm requires early exit. Trace the loop by hand for the smallest input and the boundary input before running it.
Off-by-one errors in for loops over arrays or strings: using i <= arr.length, or starting at 1, or stopping at length - 1 when the last element should be included.
Mixing the count of elements (length) with the largest valid index (length - 1), and mixing inclusive/exclusive bounds when translating a problem statement.
What to do instead
Memorize the canonical form for (int i = 0; i < arr.length; i++) and derive others from it. When a problem says 'the last n elements', compute the start index as arr.length - n and check it with a concrete small array such as length 3, n 2.
Assuming && and || short-circuit in the wrong direction, or relying on side effects inside a boolean expression (e.g., count++ > 0 && other()) without knowing which operand runs.
Students evaluate boolean expressions as if both sides always execute, and they forget that && skips the right side when the left is false while || skips when the left is true.
What to do instead
Remember: && stops at the first false, || stops at the first true. Avoid putting side effects in conditions; if you must, trace both branches. Practice predicting output for expressions like (i++ > 0) || (j++ > 0) and verify the post-increment values.
Declaring instance variables and then shadowing them with local variables or parameters of the same name without using this, so assignments in a constructor or setter silently update the local copy.
Parameter names that match field names are natural to write, and the compiler does not warn because the code is legal; the field keeps its default value.
What to do instead
In constructors and setters, always write this.field = parameter when names collide, or rename parameters (newName). After writing a constructor, check every field is assigned exactly once and that no assignment target is a bare parameter name matching a field.
Writing a subclass constructor that does not call super(...) with the required arguments, or calling super() after other statements, causing a compile error or unexpected default initialization.
Students learn that 'super() is called automatically' and assume it works even when the superclass has no no-argument constructor, or they place field assignments before the super call.
What to do instead
Rule: if the superclass lacks a no-arg constructor, the first statement of the subclass constructor must be super(args). Put all super calls first, then initialize subclass fields. When given a superclass with only a parameterized constructor, write the subclass constructor and confirm the argument types match.
Confusing static and instance members: calling an instance method from a static context, or accessing an instance variable from main without an object.
main is static and students write helper logic directly in it, then try to reference fields or call non-static methods that require an object.
What to do instead
Ask of every member: does it depend on a particular object's state? If yes it is instance; if it is shared or a utility, it is static. From main, create an object first, then call instance methods on it. Mark helper methods static only if they use no instance fields.
Removing elements from an ArrayList with a for loop that increments the index, skipping the element that shifts into the removed position, or calling remove(int) when remove(Object) was intended.
The loop was written for arrays where removal does not shift elements, and the overloaded remove is ambiguous when the element type is Integer.
What to do instead
When removing while traversing, iterate backward from size()-1 to 0, or decrement the index after a removal. To remove a value from an ArrayList, use remove(Integer.valueOf(x)) or remove(index) deliberately. Verify with a list of three equal elements.
Assuming a 2D array is jagged or rectangular without checking, or transposing row and column indices in arr[row][col] access, producing out-of-bounds or wrong values.
Students visualize a grid as x,y coordinates and map x to the first index, but Java uses row first. Ragged arrays from initialization lists break loops that assume a constant column count.
What to do instead
Always write arr[row][col] and name loop variables r and c to reinforce order. For traversal, use arr.length for rows and arr[r].length for the current row's columns, never a fixed constant. Trace a 2x3 and a ragged {{1},{2,3}} example to confirm bounds.