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))) {} else {
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))) {} else {
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() {
return "Ordering.natural()";
}
private NaturalOrdering() {}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code has a clear overall structure with logical organization and relatively flat nesting. It follows typical Java class conventions, with fields, constructors, and methods in a reasonable order. The intent of the class is straightforward: it implements natural ordering as a singleton. However, several aspects hurt readability. The lazy-initialization checks in `nullsFirst()` and `nullsLast()` use awkward empty-if blocks (`if (!((result == null))) {} else { ... }`) which are unconventional and harder to read than a simple `if (result == null) { ... }`. There are also unclear TODO comments about suppressing unchecked warnings, which leave intent ambiguous. Additionally, multiple actions are packed into single lines (e.g., assignment inside return, nested cast with assignment), reducing action granularity and reading flow. The code is concise but sometimes at the expense of clarity.
Run 2
The code has a clear purpose and mostly one action per line, but readability is undermined by several issues. The nullsFirst() and nullsLast() methods use an inverted if condition with an empty then-block and logic in the else, which disrupts natural reading flow and obscures intent. Type annotations and generics are verbose, reducing clarity. The structure is fairly flat and methods are short, but the repetitive and awkward conditional patterns hurt. Overall, it is understandable but not highly readable due to these unusual constructs and unnecessary complexity.
Run 3
The code is readable but has some awkward elements. Structure is logical: class declaration, fields, methods in a sensible order. Nesting is flat—no deep nesting beyond a single if-else in the nullsFirst/nullLast methods. Clarity of intent is mostly good, with clear method names (compare, reverse, nullsFirst) and a useful class-level comment, though the inverted if-else conditions (`if (!((result == null))) {} else { ... }`) are confusing and unconventional. Code length is reasonable; the class remains concise for what it does. Action granularity is mostly one action per line, though the nullsFirst/nullLast methods combine null check, assignment, and return in dense constructs. Reading flow is generally natural, but the TODO comments and the strange empty-if-block pattern disrupt it. The nullsFirst/nullLast methods would be clearer with standard null-check if statements. Overall, it is readable but has identifiable stylistic oddities that a reader must work through.
Run 1
Code Structure: The class is logically organized into singleton state, comparison, ordering variants, and serialization support. Nesting: Methods are shallow, but negated null checks with empty if branches and else blocks introduce unnecessary complexity. Clarity of intent: Names and the class description convey the purpose well; dense generic annotations, unchecked casts, and unresolved suppression comments add friction. Code length: The implementation is compact, though redundant parentheses and repeated awkward conditionals are avoidable. Action granularity: Most lines perform one action, but chained assignments combine updating the cache and local variable. Reading flow: Short methods and consistent overrides make navigation easy; the inverted conditionals interrupt otherwise natural flow and would be clearer as straightforward null checks.
Run 2
Code Structure: Well-organized class with focused methods, singleton handling, and clearly separated ordering operations. Nesting: Shallow, but empty if branches followed by else blocks introduce needless complexity. Clarity of intent: Descriptive names and the class comment communicate purpose; redundant negation and parentheses obscure straightforward null checks, while generic casts and annotations add visual noise. Code length: Mostly concise, though repeated suppression comments and awkward conditional forms are unnecessary. Action granularity: Most lines perform one action, but chained assignments combine local updates and cache initialization. Reading flow: Method organization is natural, yet the unusual conditionals interrupt comprehension, and densely packed annotations reduce scanability.
Run 3
Code Structure: Logically organized into a singleton, cached ordering variants, and small overrides. Nesting: Shallow throughout, but empty if branches followed by else blocks unnecessarily complicate simple null checks. Clarity of intent: Names and the class documentation clearly convey natural ordering; complex generic annotations, unchecked casts, and unresolved suppression comments add friction. Code length: Mostly concise, although repeated boilerplate and redundant condition parentheses are avoidable. Action granularity: Most lines perform one action, but chained assignments combine local updates with cache initialization, and some annotations share declaration lines. Reading flow: Method boundaries and straightforward returns support easy scanning, while negated null conditions and empty branches interrupt the otherwise natural flow.