Source code
package org.junit.internal;
import java.lang.reflect.Method;
import java.util.Arrays;
import java.util.Comparator;
import org.junit.FixMethodOrder;
public class MethodSorter {
/**
* DEFAULT sort order
*/
public static final Comparator<Method> DEFAULT = new Comparator<Method>() {
public int compare(Method m1, Method m2) {
int i1 = m1.getName().hashCode();
int i2 = m2.getName().hashCode();
if (i1 != i2) {
return i1 < i2 ? -1 : 1;
}
return NAME_ASCENDING.compare(m1, m2);
}
};
/**
* Method name ascending lexicographic sort order, with {@link Method#toString()} as a tiebreaker
*/
public static final Comparator<Method> NAME_ASCENDING = new Comparator<Method>() {
public int compare(Method m1, Method m2) {
final int comparison = m1.getName().compareTo(m2.getName());
if (comparison != 0) {
return comparison;
}
return m1.toString().compareTo(m2.toString());
}
};
/**
* Gets declared methods of a class in a predictable order, unless @FixMethodOrder(MethodSorters.JVM) is specified.
*
* Using the JVM order is unwise since the Java platform does not
* specify any particular order, and in fact JDK 7 returns a more or less
* random order; well-written test code would not assume any order, but some
* does, and a predictable failure is better than a random failure on
* certain platforms. By default, uses an unspecified but deterministic order.
*
* @param clazz a class
* @return same as {@link Class#getDeclaredMethods} but sorted
* @see <a href="http://bugs.sun.com/view_bug.do?bug_id=7023180">JDK
* (non-)bug #7023180</a>
*/
public static Method[] getDeclaredMethods(Class<?> clazz) {
Comparator<Method> comparator = getSorter(clazz.getAnnotation(FixMethodOrder.class));
Method[] methods = clazz.getDeclaredMethods();
if (comparator != null) {
Arrays.sort(methods, comparator);
}
return methods;
}
private MethodSorter() {
}
private static Comparator<Method> getSorter(FixMethodOrder fixMethodOrder) {
if (fixMethodOrder == null) {
return DEFAULT;
}
return fixMethodOrder.value().getComparator();
}
}
Run 1
The code is well-structured with clear separation of concerns: comparators are defined as constants, the sorting logic is centralized in getDeclaredMethods, and helper methods have single responsibilities. Nesting is minimal with only one level of conditionals. Intent is clearly documented through Javadoc comments and descriptive method/field names. Code length is appropriate for the functionality. Action granularity is generally one action per line, though the ternary-like return in getSorter could be slightly more explicit. Reading flow is natural, progressing from public API to private helpers. Minor deductions: the DEFAULT comparator's hash-based comparison could use Integer.compare for clarity, and getSorter's null check adds slight cognitive overhead.
Run 2
The code is well-structured with clear separation of concerns: constants for comparators, a public API method, and a private helper. Nesting is minimal and flat. Intent is explicit through comments and method names like getSorter and getDeclaredMethods. The comparators are concise but slightly verbose due to anonymous class syntax; alternative approaches like lambda or Comparator.comparing could reduce length. Action granularity is appropriate, with one logical action per line in most cases. Reading flow is natural, though the Javadoc for getDeclaredMethods is somewhat lengthy and interrupts the code. Overall, readability is high with minor opportunities for modernization and brevity.
Run 3
The code is well-structured with clear separation of concerns: comparators are defined as constants, and helper methods are focused and single-purpose. Nesting is minimal, with only one level of anonymous inner classes and straightforward conditional logic. Intent is clearly communicated through descriptive names and Javadoc. Code length is concise and avoids unnecessary verbosity. Each line typically performs one logical action, promoting readability. The reading flow is natural: constants are introduced first, followed by the public API and private helpers. Minor deductions: anonymous inner classes could be replaced with lambdas for brevity, and the null-check in getDeclaredMethods could be clarified, but overall readability is high.
Run 1
Code Structure: Comparators, method retrieval, and annotation-based sorter selection are logically separated. Nesting: Shallow conditionals and early returns keep control flow simple, despite anonymous comparator classes. Clarity of intent: Descriptive method and constant names plus documentation explain deterministic sorting; DEFAULT's hash-based ordering and null meaning JVM order could be documented more explicitly. Code length: Implementation is concise, though anonymous classes and lengthy documentation add some bulk. Action granularity: Statements generally perform one action each; the nested annotation lookup remains easy to follow. Reading flow: Comparators precede their usage, and methods read naturally from lookup through optional sorting to return. Minor drawbacks include abbreviated comparator variables and placing the private constructor between related methods.
Run 2
Code Structure: Comparators, method retrieval, and annotation-based sorter selection are logically separated. Nesting: Shallow conditionals and early returns keep control flow simple, although anonymous comparator classes add structural nesting. Clarity of intent: Descriptive API names and documentation explain deterministic ordering and tie-breaking; DEFAULT's hash-based ordering and abbreviated variables i1/i2 are less immediately clear. Code length: Compact implementation with useful documentation, though anonymous classes add boilerplate. Action granularity: Each statement performs a focused action, with no crowded multi-statement lines. Reading flow: Comparator definitions lead naturally into their use, and the small helper is easy to follow; the private constructor between operational methods slightly interrupts the flow. Overall, highly readable with minor naming and boilerplate limitations.
Run 3
Code Structure: Well-organized utility class with separate comparators and a small helper for selecting the sort order. Nesting: Shallow conditionals and early returns keep control flow simple, although anonymous comparator classes add some visual nesting. Clarity of intent: Descriptive constants, method names, and documentation explain predictable method ordering; however, the DEFAULT comment does not explain hash-based ordering, and i1/i2 are vague names. Code length: Compact implementation with useful documentation, though anonymous classes introduce boilerplate. Action granularity: Statements generally perform one clear action per line; chained calls remain straightforward. Reading flow: Natural progression from sorting strategies to the public operation and supporting helper, with consistent formatting and spacing.