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> backing, ImmutableList<E> backing2) {
super(backing, backing2);
}
@Override
ImmutableSortedSet<E> delegate() {
return (ImmutableSortedSet<E>) super.delegateCollection();
}
@Override
public Comparator<? super E> com() {
return delegate().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 index(@Nullable Object tar) {
int ind = delegate().indexOf(tar);
// 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().
return (ind >= 0 && get(ind).equals(tar)) ? ind : -1;
}
@GwtIncompatible // ImmutableSortedSet.indexOf
@Override
public int last(@Nullable Object tar2) {
return index(tar2);
}
@Override
public boolean con(@Nullable Object tar3) {
// Necessary for ISS's with comparators inconsistent with equals.
return index(tar3) >= 0;
}
@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> sub(int from, int to) {
ImmutableList<E> parent = super.subListUnchecked(from, to);
return new RegularImmutableSortedSet<E>(parent, com()).asList();
}
@Override
public Spliterator<E> spl() {
return CollectSpliterators.indexed(
size(),
ImmutableList.SPLITERATOR_CHARACTERISTICS | Spliterator.SORTED | Spliterator.DISTINCT,
delegateList()::get,
com());
}
// redeclare to help optimizers with b/310253115
@SuppressWarnings("RedundantOverride")
@Override
@J2ktIncompatible
@GwtIncompatible
Object write() {
return super.writeReplace();
}
}
Run 1
The code is generally readable with clear class hierarchy and purpose (immutable sorted list view). Documentation comments and TODO items help explain intent. Structure is logical with related methods grouped together. However, readability is affected by several factors: abbreviated method names (com, sub, spl, index, last, con, write) that obscure their meaning; inconsistent parameter naming (tar, tar2, tar3); multiple annotations on single lines creating visual clutter; and incomplete comments referencing TODO fixes. The nesting is minimal which is good, and action granularity is reasonable. The code is concise, though several overrides exist primarily for performance optimization which adds complexity. The reading flow suffers from scattered annotation blocks and abbreviated names requiring the reader to infer purpose from context rather than clear naming conventions.
Run 2
The code is generally structured and follows consistent patterns, but suffers from poor naming conventions that obscure intent. Method names like 'com()', 'index()', 'last()', 'con()', 'sub()', 'spl()', and 'write()' are overly abbreviated and fail to clearly convey their purpose, reducing readability. The code is relatively flat with minimal nesting, which is positive, and actions are mostly separated per line. Comments provide some context but are incomplete or reference TODOs that add confusion. The class hierarchy and use of annotations are standard, but the inconsistent and cryptic abbreviations throughout the code significantly hinder readability. While the overall organization is logical, the unclear naming and incomplete documentation make the code harder to follow than necessary.
Run 3
The code is generally well-structured within a single class, with clear logical organization by method. Nesting is minimal, and each method performs a single, clear action. Variable names like 'ind' and 'tar' are overly abbreviated and reduce clarity. Several method names (e.g., 'com', 'index', 'last', 'con', 'sub', 'spl') are non-standard and obscure intent, likely due to a rename in the provided snippet. Comments are helpful, explaining non-obvious performance considerations. The class-level Javadoc is missing from this snippet but referenced. The code could be more readable with descriptive method names that match standard Java conventions.
Run 1
Code Structure: The class is logically organized into small, focused methods, though annotations and TODO comments add clutter. Nesting: Methods are flat, with no deeply nested control flow. Clarity of intent: The class documentation and comparator-related comments help, but abbreviated names such as com, index, last, con, sub, spl, and write obscure familiar operations; backing2 and tar2/tar3 are also weak names. Some comments reference conventional method names rather than the actual declarations, increasing confusion. Code length: Implementations are concise, although lengthy compatibility comments interrupt otherwise compact code. Action granularity: Most lines perform one clear action; the conditional return and chained construction remain manageable. Reading flow: Delegation and related lookup methods follow a natural sequence, but inconsistent indentation in write(), dense annotations, and cryptic naming reduce fluency.
Run 2
Code Structure: Logically organized into small overrides around a backing sorted set, though annotations and lengthy TODOs add clutter. Nesting: Very flat, with no nested control flow. Clarity of intent: Class documentation and comparator-consistency comments help, but abbreviated method names (com, index, last, con, sub, spl, write) and parameters (backing2, tar2, tar3, ind) obscure meaning; comments referencing different method names increase confusion. Code length: Implementations are concise, although maintenance comments occupy substantial space. Action granularity: Generally one operation per statement, with a compact, understandable conditional return. Reading flow: Delegation and lookup methods follow a sensible sequence, but annotation blocks, inconsistent indentation on write(), and cryptic naming interrupt otherwise straightforward reading.
Run 3
Code Structure: Logically organized into small overrides, with delegation keeping responsibilities clear. Nesting: Very flat; no nested control flow and only a simple conditional expression. Clarity of intent: Comments explain comparator consistency and performance concerns, but abbreviated names such as com, con, spl, tar, and backing2 obscure meaning. Comments referencing indexOf and lastIndexOf do not match the actual method names, creating confusion. Code length: Methods are concise, although lengthy compatibility comments and annotations add visual overhead. Action granularity: Statements generally perform one action per line; chained calls and the conditional return remain manageable. Reading flow: Consistent method layout mostly supports natural reading, but cryptic naming, framework-specific details, and inconsistent indentation on write interrupt it.