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 validateSession(Comparator<?> finalValue, Iterable<?> finalKey) {
checkNotNull(finalValue);
checkNotNull(finalKey);
Comparator<?> activeCache;
if (finalKey instanceof SortedSet) {
activeCache = buildToken((SortedSet<?>) finalKey);
} else if (finalKey instanceof SortedIterable) {
activeCache = ((SortedIterable<?>) finalKey).comparator();
} else {
return false;
}
return finalValue.equals(activeCache);
}
@SuppressWarnings("unchecked")
// if sortedSet.comparator() is null, the set must be naturally ordered
public static <E extends @Nullable Object> Comparator<? super E> buildToken(
SortedSet<E> nextIndex) {
Comparator<? super E> offset = nextIndex.comparator();
if (offset == null) {
offset = (Comparator<? super E>) Ordering.natural();
}
return offset;
}
}
Run 1
The code has clear structure with appropriate imports, documentation, and a private constructor for a utility class. However, it suffers from confusing naming conventions that hurt readability. Parameters like 'finalValue' and 'finalKey' don't reflect their actual roles (they're actually comparator and iterable respectively), while local variables like 'activeCache' and 'buildToken' suggest caching or tokenization rather than comparator extraction. This creates a disconnect between intent and implementation. The method name 'validateSession' is misleading for what actually checks sorted collection compatibility. Nesting is acceptable with only one level of conditional logic, and action granularity is reasonable. Type checking logic (instanceof checks) could be clearer through method extraction or better naming. Overall, the code structure is solid but the obfuscated naming pattern significantly reduces clarity and maintainability.
Run 2
The code is reasonably readable but has several clarity issues. The class structure is logical, and methods are short with minimal nesting. However, the naming is confusing and obscures intent: 'validateSession', 'buildToken', 'finalValue', 'finalKey', 'activeCache', 'offset', and 'nextIndex' don't reflect their actual roles as comparator and iterable. This makes the purpose ambiguous despite the Javadoc. The first method has shallow nesting and one action per line mostly, but the conditional chain checking types could be clearer with early returns. The second method is concise but relies on a comment to explain null handling. The mixing of misleading parameter names with generic types increases cognitive load. Overall, the code is formatted cleanly but fails to be self-documenting because of poor naming choices.
Run 3
The code is logically organized with clear method separation and documentation, but it suffers from confusing naming. Names like `validateSession`, `finalKey`, `finalValue`, `activeCache`, `buildToken`, and `nextIndex` do not reflect their actual purpose, which obscures intent. The method logic is simple and nesting is minimal, aiding readability, but the misleading identifiers undermine clarity. The code is concise and avoids unnecessary length, with one action per line in most cases. However, the parameter names are poor, especially in `validateSession`, where `finalValue` and `finalKey` suggest unrelated concepts. Overall, the structure is reasonable, but the naming significantly reduces readability.
Run 1
Code Structure: Two small, focused methods and a private constructor provide clear organization. Nesting: Shallow conditionals and an early return keep complexity low. Clarity of intent: The main weakness is misleading naming: validateSession, buildToken, finalValue, finalKey, activeCache, nextIndex, and offset obscure comparator-related operations. Documentation explains the actual purpose, but references parameter names that do not match the signature. Code length: Concise, with no unnecessary logic. Action granularity: Statements generally perform one action per line; casts and method calls remain manageable. Reading flow: Null checks, collection-type detection, and comparator comparison follow a natural sequence, while the helper cleanly handles natural ordering. Import spacing could improve visual separation.
Run 2
Code Structure: Well organized into two focused utility methods, with validation before comparator selection. Nesting: Shallow conditionals and an early return keep complexity low. Clarity of intent: Documentation explains the functionality, but misleading names such as validateSession, buildToken, finalValue, finalKey, activeCache, nextIndex, and offset obscure the sorted-collection purpose. Code length: Concise, with no substantial redundancy. Action granularity: Each statement performs a single clear operation. Reading flow: The control flow is natural, and the null-comparator comment clarifies natural ordering; however, unrelated identifiers conflict with the documentation and require readers to mentally translate their roles.
Run 3
Code Structure: The utility class is logically organized, with a private constructor and two focused methods. Nesting: Shallow conditionals and an early return keep control flow simple. Clarity of intent: Documentation explains the actual behavior, but misleading names such as validateSession, buildToken, finalValue, finalKey, activeCache, nextIndex, and offset obscure comparator-related operations and conflict with the documented purpose. Code length: The implementation is concise without unnecessary repetition. Action granularity: Statements generally perform one action per line; casts and comparator calls remain manageable. Reading flow: Null checks, collection-type detection, and comparator comparison follow a natural sequence, although readers must mentally translate the unrelated identifiers. The natural-order fallback comment usefully explains the null comparator case.