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 has(Comparator<?> com2, Iterable<?> ele) {
checkNotNull(com2);
checkNotNull(ele);
Comparator<?> comparator;
if (ele instanceof SortedSet) {
comparator = com((SortedSet<?>) ele);
} else if (ele instanceof SortedIterable) {
comparator = ((SortedIterable<?>) ele).comparator();
} else {
return false;
}
return com2.equals(comparator);
}
@SuppressWarnings("unchecked")
// if sortedSet.comparator() is null, the set must be naturally ordered
public static <E extends @Nullable Object> Comparator<? super E> com(
SortedSet<E> sorted) {
Comparator<? super E> res = sorted.comparator();
if (res == null) {
res = (Comparator<? super E>) Ordering.natural();
}
return res;
}
}
Run 1
The code is moderately readable but suffers from unclear naming and inconsistent terminology. The class has a logical structure with a private constructor and static utility methods, and the nesting is shallow (one level of if-else). However, the parameter names 'com2' and 'ele' are ambiguous, making intent harder to grasp. The method 'has' checks whether an iterable is sorted by a given comparator, but neither the method name nor parameter names clearly convey this purpose. Some lines combine multiple actions (e.g., casting and method calls in one expression), reducing action granularity. The reading flow feels slightly disjointed because of the generic type handling and the inlined type checks. The Javadoc on the second method is helpful, but the suppression and inline comment add slight clutter. Overall, the code is concise and functional but could be more readable with better naming and separation of concerns.
Run 2
The code is generally readable but suffers from poor naming and inconsistent style. The class structure is logical, with clear separation between methods, but parameter names like 'com2', 'ele', 'com', and 'sorted' are cryptic and hurt clarity of intent. Nesting is minimal and acceptable. The has() method has unclear logic flow—the variable 'comparator' is assigned in different branches which makes it harder to follow. Method names 'has' and 'com' are too abbreviated and don't convey purpose. Code length is reasonable and action granularity is mostly one action per line. Reading flow is acceptable but could be improved with better names and more explicit variable declarations. The Javadoc comments are helpful but the parameter names in comments don't match actual parameters. Overall, the functionality is understandable but the naming choices significantly reduce readability.
Run 3
The code is structurally clear, with a logical organization into two well-named methods. Nesting is minimal, and intent is mostly understandable via Javadoc. However, readability is undermined by poor naming—'com2', 'ele', 'has', and 'com' obscure meaning, requiring extra effort to interpret. Method length is reasonable, but action granularity is slightly compressed (e.g., multiple checkNotNull calls in sequence). The use of compressed names harms the overall clarity and reading flow, despite good structural practices.
Run 1
Code Structure: Well-organized utility class with two focused methods and a private constructor. Nesting: Shallow conditional branches make control flow easy to follow. Clarity of intent: Documentation, null checks, and the natural-ordering comment explain behavior, but abbreviated names such as has, com, com2, ele, and res obscure purpose. Code length: Concise, with no unnecessary logic or repetition. Action granularity: Each statement performs one clear action, and operations are separated appropriately. Reading flow: Execution proceeds naturally from validation to comparator selection and comparison; however, cramped import spacing and weak naming slightly interrupt readability.
Run 2
Code Structure: The utility class cleanly separates comparator matching from comparator extraction. Nesting: Shallow conditionals and an early return keep complexity low. Clarity of intent: Documentation explains the purpose, but abbreviated names such as has, com, com2, ele, and res obscure meaning; the Javadoc also references parameter names that no longer match the signature. Code length: Both methods are concise without unnecessary logic. Action granularity: Each statement performs a single clear action. Reading flow: Validation, collection-type detection, and comparison follow a natural sequence, while the natural-order fallback is easy to follow. Minimal spacing around imports and the awkwardly wrapped helper signature slightly reduce polish.
Run 3
Code Structure: A focused utility class with two logically separated methods and a private constructor. Nesting: Shallow conditionals and an early return keep complexity low. Clarity of intent: Documentation and the natural-ordering comment explain behavior, but names such as has, com, com2, ele, and res are vague; the has documentation also references parameter names that do not match the signature. Code length: Concise, with no unnecessary repetition. Action granularity: Each statement performs one clear operation. Reading flow: Validation, collection-type detection, comparator extraction, and comparison proceed naturally. Minor formatting issues, including tightly grouped imports and an awkwardly wrapped helper signature, slightly reduce polish.