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() {
return "Ordering.natural()";
}
private NaturalOrdering() {}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0; }
Run 1
This code is extremely difficult to read. The structure is tangled, with multiple statements crammed onto single lines and inconsistent formatting throughout. There is deep nesting due to collapsed one-line methods and if blocks sharing lines. While individual method purposes are fairly clear, the visual presentation obscures intent. Action granularity is poor, with multiple actions per line making it hard to follow logic. Reading flow is disorganized and jarring. The code appears to have had its line breaks stripped, turning otherwise reasonable Java into a dense, unreadable mess. It violates nearly every readability principle: poor indentation, collapsed braces, excessive horizontal scrolling, and mixed import placement. Even though the domain logic is straightforward, the formatting makes it nearly impossible to scan and understand without reformatting first.
Run 2
The code suffers from severe readability issues. Structure is tangled: multiple annotations and fields are compressed onto single lines, making the class definition difficult to scan. Nesting is mostly flat, but the lack of line breaks obscures method boundaries — e.g., compare() packs null checks and the return statement together. Clarity of intent is hurt by missing documentation and unresolved TODO comments that don't explain the actual logic. Code length is reasonable, but action granularity is poor, with multiple actions per line. Reading flow is disorganized: fields, constructors, and methods are interleaved inconsistently, and serialVersionUID appears at the very end. This appears to be auto-formatted or deliberately compacted code, violating basic readability conventions despite the underlying logic being straightforward.
Run 3
The code has clear intent and functional logic, but readability is severely compromised by formatting. Multiple statements are crammed onto single lines, breaking the 'one action per line' guideline and disrupting natural reading flow. Nesting is minimal, which is good, but the dense line packing makes the structure hard to parse. Code length is reasonable, but vertical compression harms clarity. The comments are helpful but lost amid the clutter. Overall, the logic is simple but the presentation is disorganized, forcing readers to mentally reformat before understanding.
Run 1
Code Structure: The class has logically grouped responsibilities, but compressed declarations and method boundaries obscure its organization. Nesting: Very shallow, with only simple null checks, making control flow easy to understand. Clarity of intent: Descriptive names and straightforward methods communicate natural ordering, cached null handling, and singleton preservation; generic casts and annotations add some complexity. Code length: Appropriately short for its functionality, though excessive line compression reduces readability rather than meaningfully improving concision. Action granularity: Multiple imports, fields, statements, and even method boundaries share lines, making individual actions harder to scan. Reading flow: Inconsistent formatting, inline closing braces, and annotations attached to preceding methods interrupt otherwise natural progression through the class.
Run 2
Code Structure: The class has a logical organization, with a singleton instance, cached orderings, and focused methods, but compressed formatting obscures boundaries. Nesting: Shallow conditionals keep control flow simple. Clarity of intent: Descriptive method names and straightforward comparison logic communicate purpose, though complex generic types and unchecked casts add reading effort. Code length: The implementation is reasonably concise without substantial unnecessary logic. Action granularity: Multiple imports, declarations, assignments, and method boundaries share lines, making individual actions harder to distinguish. Reading flow: Inconsistent line breaks, crowded annotations, and closing braces followed immediately by new methods disrupt scanning. Overall, the underlying design is readable, but presentation significantly reduces accessibility.
Run 3
Code Structure: The class has a coherent purpose and logically separated methods, but compressed imports, fields, annotations, and method boundaries obscure that organization. Nesting: Shallow conditionals and short methods make the control logic easy to follow. Clarity of intent: Descriptive names and familiar ordering operations communicate purpose, though generic casts and lazy initialization require some attention. Code length: The implementation is reasonably concise without substantial unnecessary code; readability suffers from compression rather than length. Action granularity: Multiple declarations, statements, and chained assignments appear on single lines, making individual actions harder to distinguish. Reading flow: Inconsistent line breaks, inline closing braces, and annotations attached to preceding methods disrupt scanning. Conventional formatting would substantially improve readability without changing the implementation.