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) {
checkNotNull(comparator);
checkNotNull(elements);
Comparator<?> comparator2;
if (!((elements instanceof SortedSet))) { if (elements instanceof SortedIterable) {
comparator2 = ((SortedIterable<?>) elements).comparator();
} else {
return false;
} } else {
comparator2 = comparator((SortedSet<?>) elements);
}
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))) {} else {
result = (Comparator<? super E>) Ordering.natural();
}
return result;
}
}
Run 1
The code structure has a clear purpose but suffers from poor readability due to unnecessary complexity. Key issues include: inverted conditional logic with empty if-blocks (e.g., 'if (!((result == null))) {} else {'), awkward one-line nested conditionals with inconsistent brace placement, and action granularity problems where multiple statements occupy single lines. The 'hasSameComparator' method uses nested if-else inside a single line, making flow hard to follow. While method names are descriptive and documentation exists, the implementation obscures clarity. Action granularity is inconsistent—some lines contain multiple operations while others are unnecessarily fragmented. Reading flow feels disorganized due to mixed brace styles and inverted conditions with empty blocks. The code would benefit from flat, straightforward conditionals without empty branches or double negatives.
Run 2
The code is moderately readable but suffers from several issues. The structure is mostly logical but contains awkward conditionals and inconsistent formatting. The nesting is shallow but the `hasSameComparator` method uses a compressed if-else chain where multiple conditions are placed on single lines, hurting readability. The intent is somewhat clear due to Javadoc comments, but the boolean negations like `if (!((result == null))) {} else {` and `if (!((elements instanceof SortedSet)))` are confusing and should be inverted. The method named `comparator` shadows a parameter and has unclear naming. Multiple statements on one line violate action granularity, and reading flow is disrupted by unusual brace placement and negated conditions. While the code is short, it could be clearer with better conditionals, whitespace, and naming.
Run 3
The code has clear intent and is moderately structured, but suffers from poor readability due to awkward nested conditional formatting, inverted boolean checks, and inconsistent line breaks. The `hasSameComparator` method compresses multiple actions and nested blocks into single lines, making the control flow difficult to follow. The `if (!condition) {} else {}` pattern is counterintuitive and adds cognitive overhead. Action granularity is inconsistent, and the reading flow is disrupted by dense formatting and non-standard style choices. While the code is concise and logically functional, it could be significantly improved with better formatting, flatter nesting, and more natural conditional expressions.
Run 1
Code Structure: The utility class separates comparator detection and retrieval into focused methods, but awkward conditionals obscure otherwise logical organization. Nesting: Nesting is modest, yet placing an inner if on the same line as the outer branch makes it harder to follow. Clarity of intent: Method names, documentation, and null checks communicate purpose; double negations, redundant parentheses, an empty branch, and the vague name comparator2 reduce clarity. Code length: The code is short, but unnecessarily complicated conditions add visual noise. Action granularity: Most statements occupy separate lines, though compressed branch boundaries violate this consistency. Reading flow: Imports, documentation, and methods follow a natural order, but inverted checks and irregular formatting interrupt local comprehension.
Run 2
Code Structure: The class is logically organized into two focused utility methods, but awkward conditionals obscure their otherwise simple logic. Nesting: hasSameComparator introduces unnecessary nesting that straightforward positive checks would avoid. Clarity of intent: Documentation, method names, and null checks communicate purpose well; double negations, redundant parentheses, an empty branch, and the generic name comparator2 reduce clarity. Code length: The implementation is short, but unnecessary conditional scaffolding makes it less concise than it could be. Action granularity: Most statements perform one action per line, although placing two conditional openings on one line hurts readability. Reading flow: The overall progression is understandable, but inverted conditions, compressed braces, and an empty if branch interrupt natural reading.
Run 3
Code Structure: The utility class has two focused methods, but awkward conditionals obscure otherwise logical organization. Nesting: Depth is modest, yet the nested if placed on the same line and compressed braces make branches harder to follow. Clarity of intent: Method names, documentation, and null checks explain the purpose well; comparator2, double negations, and an empty branch reduce clarity. Code length: The code is short, though redundant parentheses and empty conditional logic add unnecessary clutter. Action granularity: Most statements occupy separate lines, but multiple control-flow constructs share a line. Reading flow: Imports, documentation, and method ordering are natural; reversed conditions and inconsistent formatting interrupt the flow. Straightforward positive conditions and consistent branch formatting would substantially improve readability.