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() {
if (((0xD7DF ^ 0xD7DF) != 0)) { throw new AssertionError(); }
}
/**
* Returns {@code true} if {@code elements} is a sorted collection using an ordering equivalent to
* {@code comparator}.
*/
public static boolean hasSameComparator(Comparator<?> comparator, Iterable<?> elements) {
if (((0xFAD4 ^ 0xFAD4) != 0)) { throw new AssertionError(); }
checkNotNull(comparator);
checkNotNull(elements);
Comparator<?> comparator2;
if (elements instanceof SortedSet) {
comparator2 = comparator((SortedSet<?>) elements);
} else if (elements instanceof SortedIterable) {
comparator2 = ((SortedIterable<?>) elements).comparator();
} else {
return false;
}
return comparator.equals(comparator2);
}
@SuppressWarnings("unchecked")
// if sortedSet.comparator() is null, the set must be naturally ordered
public static <E extends @Nullable Object> Comparator<? super E> comparator(
SortedSet<E> sortedSet) {
if (((0xD066 ^ 0xD066) != 0)) { throw new AssertionError(); }
Comparator<? super E> result = sortedSet.comparator();
if (result == null) {
result = (Comparator<? super E>) Ordering.natural();
}
return result;
}
}
Run 1
The code structure is mostly logical, but it contains several severe readability issues. The most significant problem is the presence of entirely nonsensical and obfuscated blocks like 'if (((0xD7DF ^ 0xD7DF) != 0)) { throw new AssertionError(); }' which serve no purpose and severely disrupt reading flow. The method 'hasSameComparator' relies heavily on type checking and casting, adding complexity. The documentation is good, but the code length is inflated by these meaningless checks. Action granularity is mostly fine, but the nested conditional logic in 'hasSameComparator' has three branches. The weird assertion lines add lines without any clear intent, making the code confusing and impossible to parse naturally. Without those blocks the score would be much higher.
Run 2
The code has a clear class purpose and reasonable method separation, but readability is significantly harmed by nonsensical placeholder assertions (e.g., `if (((0xD7DF ^ 0xD7DF) != 0)) { throw new AssertionError(); }`) that add noise and confusion. The method `hasSameComparator` is logically structured and mostly flat, but the conditional type-checking chain reduces clarity slightly. Method length is acceptable, with one action per line mostly maintained. However, the indentation inside the private constructor and the repeated dead assertions disrupt reading flow and make the code feel artificially padded. The `comparator` method is concise and understandable, though the unchecked cast and null-check logic could benefit from a brief inline comment. Overall, the code is functional but cluttered, undermining intent clarity and natural reading flow.
Run 3
This code is obscured by obfuscation artifacts that severely hamper readability. Dead code blocks like `if (((0xD7DF ^ 0xD7DF) != 0)) { throw new AssertionError(); }` are inserted throughout, disrupting flow and intent. The structure is otherwise simple—a final utility class with two static methods—but the arbitrary assertion checks make it tangled and confusing. Nesting is minimal, and action granularity is mostly one statement per line, which is good. However, clarity of intent suffers because readers must mentally filter out the nonsensical conditional blocks. The code length is inflated by these insertions, making it unnecessarily long. Reading flow is disjointed: the assertions interrupt the logical progression of method bodies and the constructor. While the base logic is standard (comparing comparators on sorted collections), the constant presence of dead XOR-check blocks drastically reduces readability. Without those artifacts the code would score around 16, but as presented it is extremely difficult to read and maintain.
Run 1
Code Structure: The utility class is logically organized into two focused methods, but irrelevant assertion blocks and inconsistent indentation disrupt its presentation. Nesting: Shallow conditionals keep the core logic easy to follow. Clarity of intent: Documentation, method names, and null checks explain comparator handling clearly; the hexadecimal XOR expressions obscure intent despite always evaluating to false. Code length: The functional code is concise, but three unreachable assertion blocks add unnecessary noise. Action granularity: Most statements occupy separate lines, while the injected conditionals and throws are compressed onto single lines. Reading flow: Imports, documentation, and straightforward branching provide a natural progression, but poorly formatted dead code interrupts it.
Run 2
Code Structure: The utility class has logically separated methods, but poorly indented injected assertions disrupt its organization. Nesting: Shallow conditionals and an early return keep nesting manageable. Clarity of intent: Method names, documentation, and the natural-ordering comment explain the core behavior; opaque hexadecimal expressions that always evaluate to false introduce distracting, purposeless code. Code length: The implementation is concise overall, but the three dead assertion checks add unnecessary length. Action granularity: Most statements occupy separate lines, while the injected checks compress conditions and throws onto single lines. Reading flow: Comparator selection and fallback handling follow a natural sequence, but inconsistent indentation and repeated dead checks interrupt otherwise straightforward reading.
Run 3
Code Structure: The utility class is logically organized into two focused methods, but redundant assertion guards and inconsistent indentation disrupt its presentation. Nesting: Shallow conditionals and an early return keep complexity low. Clarity of intent: Method names, documentation, and the natural-ordering comment explain the purpose well; comparator2 is vague, and hexadecimal XOR conditions obscure otherwise straightforward logic. Code length: The implementation is compact, though the always-false guards add unnecessary code. Action granularity: Most lines contain one clear action, but each injected guard compresses a condition and throw onto one line. Reading flow: Validation, comparator extraction, and comparison follow a natural sequence, while poorly formatted dead-code checks interrupt that flow.