Source code
package com.google.common.collect;
import static com.google.common.base.Preconditions.checkNotNull;
import com.google.common.annotations.GwtCompatible;
import java.util.Comparator;
import java.util.SortedSet;
import org.jspecify.annotations.Nullable;
/**
* Utilities for dealing with sorted collections of all types.
*
* @author Louis Wasserman
*/
@GwtCompatible
final class SortedIterables {
private SortedIterables() {}
/**
* Returns {@code true} if {@code elements} is a sorted collection using an ordering equivalent to
* {@code comparator}.
*/
public static boolean a(Comparator<?> a, Iterable<?> b) {
checkNotNull(a);
checkNotNull(b);
Comparator<?> c;
if (b instanceof SortedSet) {
c = b((SortedSet<?>) b);
} else if (b instanceof SortedIterable) {
c = ((SortedIterable<?>) b).comparator();
} else {
return false;
}
return a.equals(c);
}
@SuppressWarnings("unchecked")
// if sortedSet.comparator() is null, the set must be naturally ordered
public static <E extends @Nullable Object> Comparator<? super E> b(
SortedSet<E> d) {
Comparator<? super E> e = d.comparator();
if (e == null) {
e = (Comparator<? super E>) Ordering.natural();
}
return e;
}
}
Run 1
The code has logical structure with appropriate package imports, clear class purpose, and Javadoc. However, method names (a, b) are completely opaque, obfuscating intent. The original parameter names are replaced with meaningless single letters (a, b, c, d, e), which severely hurts readability. Nesting is minimal (only one if-else chain), and action granularity is generally one action per line. Reading flow is broken by poor naming. Code length is reasonable but could be more concise elsewhere. Overall, the structure is sound but naming choices are poor, making the code difficult to understand without context. The one-letter names appear to be an artifact of obfuscation rather than intentional design.
Run 2
This code is severely unreadable due to obfuscated identifiers and unclear intent. The method names 'a' and 'b' are meaningless, obscuring their purpose, while parameter names like 'a', 'b', 'c', 'd', 'e' further compound confusion. The code structure is not inherently tangled, but the abbreviated names destroy clarity of intent, making even simple logic difficult to follow. Nesting is flat, which is good, but this minor positive is negated by the absence of descriptive variable names. Code length is concise, but this brevity harms readability instead of helping, as readers must infer semantics from generic names. Action granularity is mostly one action per line, yet each line remains cryptic due to poor naming. The reading flow is unnatural: a reader must constantly cross-reference types and context to guess what each variable represents. The Javadoc comments provide some context, but they do not compensate for the opaque identifiers. Overall, this code appears intentionally obfuscated, likely due to source transformation or experimental obfuscation, failing nearly all readability criteria despite straightforward logic.
Run 3
The code structure is generally logical, with a private constructor and two static utility methods. However, readability is significantly reduced by the use of single-letter method names ('a', 'b') and single-letter parameter/variable names ('a', 'b', 'c', 'd', 'e'), which obscure the intent. The nesting level is moderate (one if-else chain and one nested expression), but the type-checking logic could be clearer. The code is concise, but this conciseness comes at the expense of clarity. Reading flow is disrupted by the non-descriptive identifiers, despite the presence of a helpful comment explaining the SortedSet behavior. The method names and parameters fail to convey purpose, which forces the reader to analyze the implementation details carefully to understand what the code does.
Run 1
Code Structure: The utility class cleanly separates comparator matching from comparator extraction. Nesting: Shallow conditional branches and an early return keep complexity low. Clarity of intent: Javadoc and the natural-ordering comment explain the behavior, but single-letter method and variable names obscure meaning and make calls harder to follow. Code length: Concise, with no unnecessary logic; the split helper signature is slightly awkward. Action granularity: Each statement performs one clear action, and null checks are separate. Reading flow: Validation, collection-type detection, and comparator comparison follow a natural sequence, though ambiguous identifiers and tightly grouped package/import declarations reduce readability.
Run 2
Code Structure: The utility class is logically organized into two focused methods, with validation preceding comparison. Nesting: Shallow conditionals and an early return keep control flow simple. Clarity of intent: Documentation explains the purpose, but single-letter method and variable names obscure meaning; naming both a parameter and a method 'b' adds confusion. Code length: The implementation is concise without significant redundancy. Action granularity: Each statement performs one main action, making individual steps easy to follow. Reading flow: The sequence from validation to comparator extraction and equality checking is natural, although cryptic identifiers and an awkwardly wrapped method signature interrupt readability.
Run 3
Code Structure: The utility class is logically organized into two focused methods, with validation before processing. Nesting: Shallow conditional branches and an early return keep complexity low. Clarity of intent: Documentation explains the purpose and natural-order fallback, but single-letter method and variable names obscure meaning; the method b and parameter b are particularly confusing. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one clear action, and null checks are separated. Reading flow: Execution proceeds naturally from validation to comparator selection and comparison, although cryptic identifiers and the split helper-method signature slightly interrupt readability.