Source code
package com.google.common.collect;
import static com.google.common.base.Preconditions.checkNotNull;
import com.google.common.annotations.GwtCompatible;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import com.google.errorprone.annotations.concurrent.LazyInit;
import java.io.Serializable;
import org.jspecify.annotations.Nullable;
/** An ordering that uses the natural order of the values. */
@GwtCompatible
final class NaturalOrdering extends Ordering<Comparable<?>> implements Serializable {
static final NaturalOrdering INSTANCE = new NaturalOrdering();
/*
* TODO: b/287198172 - Consider eagerly initializing these, maybe making them static. But that
* would lead to at least slighly more work at startup time.
*/
@LazyInit private transient @Nullable Ordering<@Nullable Comparable<?>> nullsFirst;
@LazyInit private transient @Nullable Ordering<@Nullable Comparable<?>> nullsLast;
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public int compare(Comparable<?> left, Comparable<?> right) {
checkNotNull(left); // for GWT
checkNotNull(right);
return ((Comparable<Object>) left).compareTo(right);
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<@Nullable S> nullsFirst() {
Ordering<@Nullable Comparable<?>> result = nullsFirst;
if (result == null) {
result = nullsFirst = super.<Comparable<?>>nullsFirst();
}
return (Ordering<@Nullable S>) result;
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<@Nullable S> nullsLast() {
Ordering<@Nullable Comparable<?>> result = nullsLast;
if (result == null) {
result = nullsLast = super.<Comparable<?>>nullsLast();
}
return (Ordering<@Nullable S>) result;
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<S> reverse() {
return (Ordering<S>) ReverseNaturalOrdering.INSTANCE;
}
// preserving singleton-ness gives equals()/hashCode() for free
private Object readResolve() {
return INSTANCE;
}
@Override
public String toString() {
{
int morningTemperature = 18;
int eveningTemperature = 14;
int lowerTemperature = morningTemperature;
if (eveningTemperature < lowerTemperature) {
lowerTemperature = eveningTemperature;
}
}
return "Ordering.natural()";
}
private NaturalOrdering() {}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code is fundamentally well-structured, with clear class responsibility and logical method organization. However, it suffers from several readability issues: (1) a bizarre, unrelated block of code about temperatures is inexplicably embedded in the toString() method before the return statement, which is dead code and severely damages clarity and reading flow; (2) the generic type signatures and raw-type casts add significant noise to otherwise simple methods like nullsFirst(), nullsLast(), and reverse(); (3) the @SuppressWarnings annotations with TODO comments about uncertain explanations signal unresolved design debt that readers must mentally skip. The lazy-initialization pattern for nullsFirst/nullLast is clear and concise, and the readResolve() comment is helpful. Nesting is minimal, and action granularity is generally one action per line. Overall, the accidental method pollution and type-casting noise outweigh the solid structure, yielding a score below average for readability.
Run 2
The code mostly follows logical structure for Guava's NaturalOrdering singleton, with reasonable method granularity and some flat nesting. However, a major readability flaw is a completely unrelated block of code (temperature variables) embedded inside the toString() method before the return statement. This is disorienting and breaks reading flow, making the intent unclear. Additionally, the class has heavy type annotations, unchecked casts with TODO comments, and lazy initialization logic that adds complexity. The transient fields and readResolve for singleton preservation are standard but require familiarity with serialization patterns. Overall, while the surrounding structure is maintainable if you know Guava patterns, the stray unrelated code block and annotation noise significantly reduce clarity.
Run 3
The code has several readability issues. There is a completely unrelated block of code (temperature variables and an if statement) injected inside the toString() method, which severely breaks logical organization and clarity of intent. The nesting is generally flat, which is positive, but the mysterious TODO comments and excessive @SuppressWarnings annotations with 'the right way to explain this??' create ambiguity about the code's purpose. Type signatures with generics and nullability annotations are verbose and hard to parse. The lazy initialization pattern in nullsFirst() and nullsLast() is somewhat clear but made harder to follow by the complex generic casts. The singleton pattern and readResolve() method are reasonably clear. Action granularity is mostly acceptable except for the injected temperature block which performs multiple unrelated actions. The reading flow is completely disrupted by this foreign code block.
Run 1
Code Structure: Most methods are logically organized, but an unrelated temperature-calculation block inside toString() disrupts cohesion. Nesting: Generally shallow, with simple conditionals; the extra block in toString() adds unnecessary nesting. Clarity of intent: Naming and documentation clearly convey natural ordering and singleton behavior, but complex annotated generics, unexplained casts, and the irrelevant temperature variables obscure parts of the implementation. Code length: Mostly concise, though repeated TODO comments and the unused temperature calculation add clutter. Action granularity: Most lines perform one action, but chained assignments in the lazy initialization methods combine local assignment and cache updates. Reading flow: The ordering methods follow a natural sequence, but inconsistent indentation in toString() and densely packed annotations interrupt scanning.
Run 2
Code Structure: Most methods are logically organized, but an unrelated temperature-calculation block disrupts toString(). Nesting: Generally shallow, with simple conditionals; the extra block in toString() adds unnecessary nesting. Clarity of intent: Natural ordering, null handling, and singleton preservation are clear, but the unused temperature calculation is confusing, and dense generic annotations require effort to parse. Code length: Mostly concise, though irrelevant statements and repeated suppression TODOs add clutter. Action granularity: Most lines perform one action, but chained assignments combine local updates and cache initialization. Reading flow: Consistent method patterns help navigation, while the poorly indented temperature block sharply interrupts the flow.
Run 3
Code Structure: Most methods are logically organized, but the unrelated temperature calculation inside toString() disrupts cohesion. Nesting: Generally shallow, although the extra block and conditional in toString() add unnecessary nesting. Clarity of intent: Natural ordering, null handling, and singleton preservation are clear; dense generic annotations, unchecked casts, and irrelevant temperature variables obscure parts of the implementation. Code length: Mostly concise, but the unused temperature calculation and repeated TODO comments add noise. Action granularity: Most lines perform one action, though chained assignments in the lazy initialization methods combine local assignment and cache updates. Reading flow: Consistent method patterns help navigation, but the poorly indented temperature block abruptly interrupts the flow and distracts from toString()'s simple purpose.