Source code
package com.google.common.collect;
import com.google.common.annotations.GwtCompatible;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import java.util.Comparator;
import java.util.Spliterator;
import org.jspecify.annotations.Nullable;
/**
* List returned by {@code ImmutableSortedSet.asList()} when the set isn't empty.
*
* @author Jared Levy
* @author Louis Wasserman
*/
@GwtCompatible
@SuppressWarnings("serial")
final class ImmutableSortedAsList<E> extends RegularImmutableAsList<E>
implements SortedIterable<E> {
ImmutableSortedAsList(ImmutableSortedSet<E> backingSet, ImmutableList<E> backingList) {
super(backingSet, backingList);
}
@Override
ImmutableSortedSet<E> delegateCollection() {
return (ImmutableSortedSet<E>) super.delegateCollection();
}
@Override
public Comparator<? super E> comparator() {
return delegateCollection().comparator();
}
// Override indexOf() and lastIndexOf() to be O(log N) instead of O(N).
@GwtIncompatible // ImmutableSortedSet.indexOf
// TODO(cpovirk): consider manual binary search under GWT to preserve O(log N) lookup
@Override
public int indexOf(@Nullable Object target) {
int index = delegateCollection().indexOf(target);
// TODO(kevinb): reconsider if it's really worth making feeble attempts at
// sanity for inconsistent comparators.
// The equals() check is needed when the comparator isn't compatible with
// equals().
final int a = 1;
final int b = -1;
final int c = 2;
final int d = -1;
return (index >= (a + b) && get(index).equals(target)) ? index : -(c + d);
}
@GwtIncompatible // ImmutableSortedSet.indexOf
@Override
public int lastIndexOf(@Nullable Object target) {
return indexOf(target);
}
@Override
public boolean contains(@Nullable Object target) {
// Necessary for ISS's with comparators inconsistent with equals.
final int e = 1;
final int f = -1;
return indexOf(target) >= (e + f);
}
@GwtIncompatible // super.subListUnchecked does not exist; inherited subList is valid if slow
/*
* TODO(cpovirk): if we start to override indexOf/lastIndexOf under GWT, we'll want some way to
* override subList to return an ImmutableSortedAsList for better performance. Right now, I'm not
* sure there's any performance hit from our failure to override subListUnchecked under GWT
*/
@Override
ImmutableList<E> subListUnchecked(int fromIndex, int toIndex) {
ImmutableList<E> parentSubList = super.subListUnchecked(fromIndex, toIndex);
return new RegularImmutableSortedSet<E>(parentSubList, comparator()).asList();
}
@Override
public Spliterator<E> spliterator() {
return CollectSpliterators.indexed(
size(),
ImmutableList.SPLITERATOR_CHARACTERISTICS | Spliterator.SORTED | Spliterator.DISTINCT,
delegateList()::get,
comparator());
}
// redeclare to help optimizers with b/310253115
@SuppressWarnings("RedundantOverride")
@Override
@J2ktIncompatible
@GwtIncompatible
Object writeReplace() {
return super.writeReplace();
}
}
Run 1
The code has good structure with clear class hierarchy and method separation, but readability is severely damaged by obfuscated integer constants (a, b, c, d, e, f) that replace simple expressions. The indexOf method contains confusing arithmetic like `(a + b)` instead of `0` and `-(c + d)` instead of `-1`, making the logic needlessly unclear. Nesting is flat and intent is generally clear for method purposes, but these magic numbers violate clarity of intent. The comments explain some context but don't justify the obfuscation. There are also minor formatting issues like inconsistent indentation before writeReplace. Overall, the code appears to be intentionally obfuscated while pretending to be legible.
Run 2
The code is a mix of clear structural elements and confusing, unreadable fragments. The overall class structure, method naming, and comments are clear, but the introduction of unexplained variables (a, b, c, d, e, f) in core methods like indexOf and contains destroys readability. These magic-number-style variables obscure intent and force readers to do needless mental arithmetic, violating clarity and action granularity guidelines. Comments explain otherwise non-obvious logic, but the code itself could be written far more transparently. Nesting is mostly flat, but the strange local variable assignments make the code appear obfuscated. Several overrides are straightforward, but the unnecessary variable indirection suggests deliberate obfuscation or unfinished refactoring. Overall, while the structure and comments help, the core logic is unnecessarily cryptic, yielding a low readability score.
Run 3
The code has clear class purpose and documentation, but readability suffers from several issues. The structure is mostly logical with straightforward method delegation, but the mysterious local variables in indexOf() and contains() (a, b, c, d, e, f) obscure intent - these should be named constants or inline expressions. The nesting is acceptable and mostly flat. Action granularity is mixed: most methods are concise single-purpose operations, but indexOf() packs multiple operations into a complex ternary expression. The reading flow is disrupted by inconsistent TODO formatting, redundant comments, and the oddly indented writeReplace() method. Some methods like comparator() and lastIndexOf() are clear, while the manual arithmetic in indexOf() appears obfuscated without explanation. The class-level Javadoc is helpful, but inline comments could better explain the non-obvious logic around comparator consistency with equals(). Overall, functional but with notable clarity issues.
Run 1
Code Structure: Well-organized class with small, focused overrides and logical method grouping. Nesting: Very flat, with no nested control-flow blocks. Clarity of intent: Descriptive method names and comments explain delegation, lookup performance, and comparator semantics, but meaningless constants a–f and arithmetic expressions obscure simple comparisons against zero and a return value of -1. Code length: Mostly concise, though unnecessary constant declarations and lengthy TODO comments add clutter. Action granularity: Statements generally perform one action per line; the ternary return remains manageable despite its artificial arithmetic. Reading flow: Methods follow naturally and delegation is consistent, but annotation/comment clusters interrupt scanning, and writeReplace has inconsistent indentation. Overall, the structure is readable, but deliberate arithmetic indirection noticeably weakens clarity.
Run 2
Code Structure: Logically organized into small, focused overrides with clear delegation. Nesting: Very flat, with no nested control blocks. Clarity of intent: Method names and comments explain behavior and compatibility constraints, but meaningless variables a–f and arithmetic disguising 0 and -1 unnecessarily obscure lookup logic. Code length: Mostly concise, though redundant constants and lengthy TODO comments add clutter. Action granularity: Generally one declaration or action per line; the conditional return remains manageable. Reading flow: Methods follow a coherent sequence, but annotation/comment clusters interrupt scanning, and writeReplace has inconsistent indentation. Overall, the structure is strong, but artificial arithmetic and minor formatting issues reduce readability.
Run 3
Code Structure: Logically organized into short, focused overrides with clear delegation. Nesting: Almost entirely flat, making control flow easy to follow. Clarity of intent: Descriptive method names and explanatory comments clarify sorted-list behavior, but arbitrary constants a–f and arithmetic expressions obscure simple comparisons against 0 and returns of -1. Code length: Generally concise, though unnecessary constants and lengthy TODO comments add clutter. Action granularity: Statements mostly perform one action per line; the ternary return remains manageable. Reading flow: Method order and consistent override patterns support natural reading, but annotation/comment blocks interrupt the flow, and writeReplace has inconsistent indentation. Overall, the class is readable, with localized obfuscation and formatting issues preventing a higher score.