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 hasSameComparator(Comparator<?> comparator, Iterable<?> elements) {
{int lI0O_eb500e93=0,lI0O_1ffabb85=0;while(lI0O_1ffabb85<2){lI0O_eb500e93^=(lI0O_1ffabb85<<1)^0x5;lI0O_1ffabb85++;}lI0O_eb500e93^=lI0O_eb500e93;}
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) {
Comparator<? super E> result = sortedSet.comparator();
if (result == null) {
result = (Comparator<? super E>) Ordering.natural();
}
return result;
}
}
Run 1
The code has a clear package structure, imports, and Javadoc comments, but readability is severely impacted by a suspicious, obfuscated snippet (a while loop performing meaningless bitwise operations) that appears to be injected code and serves no purpose. The methods are relatively short and have clear intent, but this dead code breaks the reading flow and structure. Additionally, the if-else chain is shallow and readable, but the overall code length is inflated by the junk code. Action granularity and nesting are generally okay aside from the injected block, but clarity of intent is compromised because the purpose of that block is ambiguous. Without this block, readability would be much higher.
Run 2
The code is largely readable due to clear method names, appropriate use of preconditions, and a logical structure. However, a significant readability issue is the nonsensical obfuscated block inside `hasSameComparator` (the `while` loop with mangled variable names), which has no clear purpose and severely disrupts clarity. Additionally, the conditional logic checking `instanceof SortedSet` and `SortedIterable` is only slightly nested and understandable. The method length is reasonable, but the hidden dummy code inflates it unnecessarily. Action granularity is mostly one action per line, and the reading flow is natural until the inserted block. Overall, the code is understandable except for the intentionally confusing segment, which detracts heavily from readability, clarity, and intent.
Run 3
The code is severely damaged by an obfuscated, meaningless line inserted at the start of the `hasSameComparator` method. This line contains an arbitrary loop with cryptic variable names (`lI0O_eb500e93`, `lI0O_1ffabb85`), performing pointless XOR operations that obscure intent and introduce dead code. This directly violates clarity of intent, code length, and action granularity (multiple operations crammed into one line). The surrounding structure is otherwise logical and the methods are short, but the injection destroys the reading flow and makes the purpose of the method ambiguous. Nesting is minimal and the original logic is simple, but the obfuscated line collapses readability. Even ignoring the inserted code, this artifact demonstrates how a single confusing line can make an otherwise clean utility class appear untrustworthy and unreadable.
Run 1
Code Structure: The utility class and two focused methods are logically organized, but an unrelated computation block disrupts the first method. Nesting: Functional logic is shallow; the extraneous block adds an unnecessary scope and loop. Clarity of intent: Documentation, method names, and comparator handling clearly convey purpose, while cryptic variable names and meaningless bitwise operations obscure intent. Code length: Most code is concise, but the unused computation adds needless complexity. Action granularity: Normal statements generally perform one action per line; the injected block compresses declarations, iteration, and several operations onto one line. Reading flow: Validation, type checks, and comparator comparison follow naturally, and the natural-order fallback is straightforward. However, the unindented, dense block before validation sharply interrupts that flow.
Run 2
Code Structure: The utility class is logically organized into two focused methods, but an unrelated computation block disrupts the first method. Nesting: The main logic is shallow; the inserted block adds an unnecessary scope and loop. Clarity of intent: Documentation, method names, and comparator handling clearly convey the purpose, while cryptic variable names and meaningless bitwise operations obscure it locally. Code length: The functional implementation is concise, but the extraneous block adds needless code. Action granularity: Most statements perform one action per line; the inserted block compresses declarations, loop control, and several operations onto one line. Reading flow: Validation, type checks, and comparison follow naturally, and the helper handles natural ordering clearly. However, the dense block before validation sharply interrupts that flow.
Run 3
Code Structure: The utility class is logically organized into two focused methods, but an unrelated block disrupts hasSameComparator. Nesting: The meaningful logic is shallow; the added block and loop introduce unnecessary nesting. Clarity of intent: Documentation, method names, and standard comparator checks communicate purpose well, while opaque variable names and no-op arithmetic obscure intent. Code length: The useful implementation is concise, but the extraneous loop adds needless code. Action granularity: Most statements perform one action per line; the inserted block compresses declarations, looping, increments, and arithmetic onto one line. Reading flow: The normal validation, type checks, and return sequence reads naturally, but the dense block before validation interrupts that flow.