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 a(Comparable<?> a, Comparable<?> b) {
checkNotNull(a); // for GWT
checkNotNull(b);
return ((Comparable<Object>) a).compareTo(b);
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<@Nullable S> b() {
Ordering<@Nullable Comparable<?>> c = nullsFirst;
if (c == null) {
c = nullsFirst = super.<Comparable<?>>nullsFirst();
}
return (Ordering<@Nullable S>) c;
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<@Nullable S> c() {
Ordering<@Nullable Comparable<?>> d = nullsLast;
if (d == null) {
d = nullsLast = super.<Comparable<?>>nullsLast();
}
return (Ordering<@Nullable S>) d;
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<S> d() {
return (Ordering<S>) ReverseNaturalOrdering.INSTANCE;
}
// preserving singleton-ness gives equals()/hashCode() for free
private Object e() {
return INSTANCE;
}
@Override
public String f() {
return "Ordering.natural()";
}
private NaturalOrdering() {}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code has good structure with clear class purpose and single-line actions, but suffers from obfuscated method names (a, b, c, d, e, f) that destroy readability. While nesting is flat and imports are organized, the generic type casting and suppressed warnings add noise. The lazy initialization pattern is understandable but repetitive. The comments reference TODOs that indicate incomplete documentation. Overall, the code is structurally sound but the deliberate renaming of methods - likely for obfuscation in this example - severely hampers clarity of intent and reading flow.
Run 2
The code has reasonable structure with clear class-level organization, but suffers from several readability issues. Method names 'a', 'b', 'c', 'd', 'e', 'f' completely obscure intent - readers cannot understand what operations these represent without documentation. The null-checking lazy initialization pattern is repeated twice, creating avoidable duplication. There are multiple TODO comments indicating unclear implementation details. The code mixes concerns between null-handling logic, type safety suppression, and singleton patterns. Several @SuppressWarnings annotations with TODO comments suggest incomplete understanding. The reading flow is disrupted by unclear method semantics and excessive boilerplate around generic type handling. While the code is relatively flat with good action granularity, the naming choices and generic complexity make it difficult to comprehend quickly.
Run 3
The code is severely obfuscated due to meaningless method and variable names (a, b, c, d, e, f), making intent unclear. While the class structure is logical and nesting is minimal, the action granularity and reading flow are disrupted by the single-letter identifiers and excessive annotations/suppressions. The lazy initialization pattern is recognizable but obscured by poor naming. Comments reference TODOs that suggest incomplete work. Overall, the code requires significant mental effort to understand despite being relatively short, because semantics are hidden behind cryptic names rather than expressed clearly.
Run 1
Code Structure: The class is logically organized into singleton setup, cached orderings, comparison, and supporting methods. Nesting: Only single-level conditionals appear, making control flow easy to follow. Clarity of intent: The class documentation and descriptive field names help, but methods named a–f and locals c/d obscure their roles. Generic casts and dense annotations add reading effort, while unresolved suppression comments provide little explanation. Code length: Methods are short and the implementation is appropriately concise, although repeated annotation comments introduce clutter. Action granularity: Most statements perform one action, but chained assignments combine local assignment and cache updates. Reading flow: Consistent formatting and method grouping support a natural progression, though cryptic names and compressed annotation declarations interrupt comprehension.
Run 2
Code Structure: The class is logically organized into singleton state, comparison, cached orderings, and utility methods. Nesting: Only single-level conditionals appear, keeping control flow simple. Clarity of intent: The class documentation and descriptive field names help, but methods named a–f and local variables c and d obscure purpose significantly. Generic casts, nullability annotations, and unresolved suppression comments add cognitive overhead. Code length: Compact and generally appropriate, though repeated lazy-initialization patterns and comments introduce some repetition. Action granularity: Most lines perform one action, but chained assignments combine local updates and cache initialization. Reading flow: Method bodies are straightforward, but cryptic names, dense declarations, and tightly grouped imports interrupt otherwise natural reading.
Run 3
Code Structure: Well-organized class with separate methods for comparison, null handling, reversal, and singleton support. Nesting: Minimal; caching methods contain only one conditional level. Clarity of intent: The class description and descriptive field names help, but method names a–f and local names c/d obscure purpose. Generic casts and dense annotations add cognitive load, while unresolved suppression comments provide little explanation. Code length: Compact overall, with reasonable duplication between the two caching methods. Action granularity: Mostly one action per line, though chained assignments combine local assignment and cache updates, and some annotations share declaration lines. Reading flow: Methods follow a sensible progression, but cryptic naming, compressed formatting, and repeated TODO comments interrupt otherwise straightforward reading.