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) {
if (((0xDC23 ^ 0xDC23) != 0)) { throw new AssertionError(); }
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() {
if (((0x5207 ^ 0x5207) != 0)) { throw new AssertionError(); }
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() {
if (((0x8C90 ^ 0x8C90) != 0)) { throw new AssertionError(); }
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() {
if (((0xBA84 ^ 0xBA84) != 0)) { throw new AssertionError(); }
return (Ordering<S>) ReverseNaturalOrdering.INSTANCE;
}
// preserving singleton-ness gives equals()/hashCode() for free
private Object readResolve() {
if (((0x7856 ^ 0x7856) != 0)) { throw new AssertionError(); }
return INSTANCE;
}
@Override
public String toString() {
if (((0xA365 ^ 0xA365) != 0)) { throw new AssertionError(); }
return "Ordering.natural()";
}
private NaturalOrdering() {
if (((0xBF7F ^ 0xBF7F) != 0)) { throw new AssertionError(); }
}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
The code has reasonable underlying structure, but readability is severely damaged by the injected assertions on nearly every line. The `if (((0xDC23 ^ 0xDC23) != 0)) { throw new AssertionError(); }` patterns are redundant, add noise, and disrupt the reading flow completely. Indentation is inconsistent, and the assertions create unnecessary nesting as standalone blocks but then continue as if they were one-liners, making it difficult to see where methods actually start. Comments and annotations are useful, but the repeated suppression comments and interleaved assertions make intent unclear. The class itself is small and logically organized, which would otherwise rate much higher, but the intrusive guard statements force the reader to scan past meaningless comparisons in every method.
Run 2
The code has severe readability issues. Most critically, every method contains an obfuscated 'if (((0xXXXX ^ 0xXXXX) != 0)) { throw new AssertionError(); }' line, which serves no logical purpose and breaks reading flow. There are multiple TODO comments indicating confusion about necessary suppressions. Some methods have unusual indentation, and the class lacks clean spacing in places. The natural reading flow is heavily interrupted by these dead branches. While the structure is otherwise standard (singleton pattern, lazy initialization), the pervasive noise makes the code ambiguous and untrustworthy. Action granularity is acceptable but null checks are compressed with comments. Overall, the code appears tampered with or deliberately obfuscated, drastically reducing clarity despite a simple underlying intent.
Run 3
The code is largely unreadable due to the pervasive insertion of meaningless assertion checks (e.g., `if (((0xDC23 ^ 0xDC23) != 0)) { throw new AssertionError(); }`) at the start of nearly every method and constructor. These statements are always false, add noise, inflate line count, and disrupt the natural reading flow. Organically, the class has a reasonable structure (fields, methods, readResolve, constructor), but the injected lines break cohesion and make it look tangled. Nesting is mostly flat, which is good, but clarity of intent is severely harmed by the assertion noise and the unexplained TODO comment about casting. Action granularity is okay per line, but length is unnecessarily bloated. Without the inserted lines, this would be a fairly clean singleton ordering implementation; with them, it becomes confusing and hard to follow.
Run 1
Code Structure: The class is logically organized into focused ordering methods, cached fields, and singleton support. Nesting: Minimal nesting keeps control flow easy to follow. Clarity of intent: Method names and the class documentation communicate purpose, but repeated hexadecimal XOR conditions that are always false introduce confusing, irrelevant noise. Complex generic types and unexplained unchecked casts add difficulty. Code length: Core functionality is concise, but redundant assertion blocks and repeated TODO comments unnecessarily lengthen it. Action granularity: Most statements perform one action, although chained cache assignments and inline conditional/throw blocks combine operations. Reading flow: Conventional method organization helps, but unindented assertion lines, compressed annotations, and inconsistent constructor formatting repeatedly interrupt the flow.
Run 2
Code Structure: The class is logically organized into small, focused methods, with clear singleton and caching patterns. Nesting: Mostly flat, with only shallow conditionals. Clarity of intent: Method names and the class comment explain the purpose, but repeated hexadecimal XOR checks that always evaluate to false introduce confusing, irrelevant logic. Generic casts and dense annotations add complexity. Code length: Core functionality is concise, but redundant assertion checks and repeated TODO comments unnecessarily lengthen it. Action granularity: Most statements perform one action per line; inline conditional throws and chained assignments combine actions. Reading flow: Method ordering is natural, but unindented assertion checks, inconsistent constructor formatting, and compressed annotations disrupt scanning.
Run 3
Code Structure: The class is logically organized into focused methods, singleton state, and cached orderings. Nesting: Shallow conditionals keep complexity low. Clarity of intent: Method names and the class comment clearly communicate natural ordering, but unexplained hexadecimal XOR checks obscure otherwise straightforward behavior. These checks are always false and add distracting dead code. Code length: Most methods are concise, although repeated assertion blocks and suppression TODOs unnecessarily lengthen the class. Action granularity: Most statements perform one action, but inline conditional throws and chained assignments combine actions. Reading flow: Consistent method organization helps, while unindented assertion blocks, compressed annotations, and the misaligned constructor closing brace interrupt visual flow. Generic casts and nullable type annotations require additional attention but serve identifiable purposes.