Source code
package org.junit.internal;
import java.util.ArrayList;
import java.util.List;
import org.junit.Assert;
/**
* Thrown when two array elements differ
*
* @see Assert#assertArrayEquals(String, Object[], Object[])
*/
public class ArrayComparisonFailure extends AssertionError {
private static final long serialVersionUID = 1L;
private List<Integer> fIndices = new ArrayList<Integer>();
private final String fMessage;
/**
* Construct a new <code>ArrayComparisonFailure</code> with an error text and the array's
* dimension that was not equal
*
* @param cause the exception that caused the array's content to fail the assertion test
* @param index the array position of the objects that are not equal.
* @see Assert#assertArrayEquals(String, Object[], Object[])
*/
public ArrayComparisonFailure(String message, AssertionError cause, int index) {
fMessage = message;
initCause(cause);
addDimension(index);
}
public void addDimension(int index) {
fIndices.add(0, index);
}
@Override
public String getMessage() {
StringBuilder sb = new StringBuilder();
if (fMessage != null) {
sb.append(fMessage);
}
sb.append("arrays first differed at element ");
for (int each : fIndices) {
sb.append("[");
sb.append(each);
sb.append("]");
}
sb.append("; ");
sb.append(getCause().getMessage());
return sb.toString();
}
/**
* {@inheritDoc}
*/
@Override
public String toString() {
return getMessage();
}
}
Run 1
The code is well-structured and follows clear object-oriented principles. The class has a single responsibility, with methods that are short and focused. Nesting is minimal, limited to a single loop and conditional check. Intent is clearly communicated through meaningful names, Javadoc comments, and overridden methods. Code length is appropriate, with no repetitive logic or unnecessary abstractions. Action granularity is good: each statement performs one logical action, especially in `getMessage()`. Reading flow is natural, moving from fields to constructor to methods, with override methods placed last. Minor deductions: the loop in `getMessage()` could theoretically use `String.join` or a helper, and the use of Hungarian-style 'f' prefix fields is outdated, but these do not significantly impair readability.
Run 2
The code is highly readable. It has a clear, logical structure with a single class and well-separated methods. Nesting is minimal; only one loop exists with no conditional depth. Intent is explicit through descriptive names like `addDimension`, `fIndices`, and thorough Javadoc. The code is concise — no dead code or unnecessary abstraction. Each line performs a distinct action, especially in `getMessage()` where appending operations are separated clearly. Reading flow is natural: fields, constructor, mutator, then overridden methods follow a logical order. Minor deductions: the use of the legacy prefix `f` for fields and direct `getCause().getMessage()` without a null-check could slightly reduce clarity, but overall it is very maintainable.
Run 3
The code is well-structured and readable. It follows a logical organization with clear field declarations, a well-documented constructor, and focused helper methods. Nesting is minimal; the only loop in getMessage() is flat and easy to follow. The intent is clearly stated through the class name, Javadoc, and method names like addDimension and getMessage. Code length is appropriate and avoids unnecessary verbosity. Each line performs a single clear action, especially in the message-building loop. Reading flow is natural — the constructor initializes state, addDimension mutates it cleanly, and getMessage composes the output step by step. Minor drawbacks are a slightly outdated naming convention (fIndices, fMessage) and possible confusion around the list insertion order, but overall the code is easy to understand and maintain.
Run 1
Code Structure: The class is logically organized into fields, construction, index tracking, and message formatting. Nesting: A single conditional and a simple loop keep nesting shallow. Clarity of intent: Descriptive method names and documentation explain the purpose, though legacy f-prefixed fields, sb, and each are less expressive, and prepending indices could use clarification. Code length: The implementation is concise, with only minor verbosity in documentation and separate append calls. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Methods progress naturally from initialization to message construction and string representation; the missing constructor documentation for message is a small inconsistency.
Run 2
Code Structure: The class is logically organized into fields, construction, index tracking, and message formatting. Nesting: A single conditional and a simple loop keep nesting shallow. Clarity of intent: The class name, documentation, and method names clearly communicate its purpose; however, f-prefixed fields and names like sb and each are less descriptive, and prepending indices could benefit from explanation. Code length: The implementation is compact with little unnecessary code, although some documentation is boilerplate. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Message construction follows a natural sequence from the optional prefix through array indices to the underlying cause, with consistent formatting throughout.
Run 3
Code Structure: The class is logically organized into fields, a constructor, and focused methods. Nesting: A single conditional and loop keep nesting shallow. Clarity of intent: The class documentation and method names clearly explain its purpose, though names such as fIndices, sb, and each are less descriptive, and prepending indices could benefit from a brief explanation. Code length: The implementation is concise, with little unnecessary code. Action granularity: Each statement performs one clear action; message construction is easy to inspect line by line. Reading flow: Initialization, dimension tracking, and message formatting follow a natural sequence. Minor documentation gaps, including the missing message parameter description, slightly reduce readability.