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) {
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) {
{
boolean featureEnabled = false;
for (int toggleCount = 0; toggleCount < 3; toggleCount++) {
featureEnabled = !featureEnabled;
}
}
Comparator<? super E> result = sortedSet.comparator();
if (result == null) {
result = (Comparator<? super E>) Ordering.natural();
}
return result;
}
}
Run 1
The code has several readability issues. The most severe is a block of dead code that computes 'featureEnabled' by toggling a boolean three times, which has no purpose and is confusingly placed inside the 'comparator' method. The 'hasSameComparator' method has moderate nesting and branching that could be flattened, but its intent is generally clear. The 'comparator' method has an unnecessary extra level of indentation and the @SuppressWarnings comment lacks clarity. While the code is fairly concise and follows consistent formatting, the presence of meaningless code drastically reduces clarity of intent. The overall structure and naming are acceptable, but the dead block and indentation issues would make a reader question the code's correctness and purpose.
Run 2
The code has a clear class structure with a private constructor and static utility methods, but contains a highly confusing block of dead code that toggles a boolean three times, serving no purpose and severely hurting readability. The hasSameComparator method flows reasonably with type checks, but the separate comparator method’s null-handling is straightforward for experienced readers. The unused featureEnabled loop is deeply confusing and adds unnecessary length. Action granularity is mostly one action per line. Nesting is minimal aside from the pointless for loop. Import ordering and documentation are good. Overall, the dead code drops the score significantly and obscures the intent.
Run 3
The code has several readability issues. The most severe is a dead code block with a pointless loop that toggles a boolean variable, which is completely unrelated to the method's purpose and is confusing. The method 'hasSameComparator' has moderate nesting and branching, but is generally clear. The use of the recursive type cast and wildcard generics makes the comparator method somewhat hard to read. The code lacks explanatory comments for non-obvious type manipulations. The dead code significantly harms clarity of intent and adds unnecessary length. The overall structure is decent, but the presence of unrelated code in the comparator method and complex generics make the intent ambiguous.
Run 1
Code Structure: The utility class and two focused methods are logically organized, but an unrelated toggle block disrupts the comparator method. Nesting: Most logic is shallow; the extra block and loop add unnecessary nesting. Clarity of intent: Documentation, null checks, and comparator handling clearly convey the main purpose, while featureEnabled and toggleCount have no meaningful connection to it. Code length: Generally concise, but the unused toggle loop adds avoidable code. Action granularity: Each statement performs a single action, making individual lines easy to follow. Reading flow: The comparator-selection branches flow naturally, but the poorly indented standalone block interrupts the transition from method declaration to comparator retrieval.
Run 2
Code Structure: The utility class and two focused methods are logically organized, but an unrelated toggle block disrupts the comparator method. Nesting: Generally shallow; the unnecessary standalone block and loop add avoidable nesting. Clarity of intent: Documentation, null checks, and comparator handling communicate the main purpose clearly, while featureEnabled and toggleCount introduce unexplained behavior with no effect on the result. Code length: Mostly concise, but the toggle block is entirely unnecessary. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: hasSameComparator flows naturally through type checks to comparison; comparator is interrupted by poorly indented, irrelevant code before returning to its actual task.
Run 3
Code Structure: The utility class and its two focused methods are logically organized, but an unrelated toggle block disrupts the comparator method. Nesting: Most code is shallow; the extra block and loop introduce unnecessary nesting. Clarity of intent: Documentation, null checks, and comparator handling clearly communicate purpose, while comparator2 is generic and featureEnabled has no observable role. Code length: The implementation is mostly concise, but the unused toggle loop adds needless lines. Action granularity: Statements generally perform one action per line, with conventional loop syntax. Reading flow: hasSameComparator reads naturally, but the poorly indented inserted block interrupts the second method and forces readers to investigate irrelevant logic.