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 publish(Comparable<?> path, Comparable<?> limit) {
checkNotNull(path); // for GWT
checkNotNull(limit);
return ((Comparable<Object>) path).compareTo(limit);
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<@Nullable S> removeUser() {
Ordering<@Nullable Comparable<?>> target = nullsFirst;
if (target == null) {
target = nullsFirst = super.<Comparable<?>>nullsFirst();
}
return (Ordering<@Nullable S>) target;
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<@Nullable S> buildNode() {
Ordering<@Nullable Comparable<?>> option = nullsLast;
if (option == null) {
option = nullsLast = super.<Comparable<?>>nullsLast();
}
return (Ordering<@Nullable S>) option;
}
@Override
@SuppressWarnings("unchecked") // TODO(kevinb): the right way to explain this??
public <S extends Comparable<?>> Ordering<S> analyze() {
return (Ordering<S>) ReverseNaturalOrdering.INSTANCE;
}
// preserving singleton-ness gives equals()/hashCode() for free
private Object removeCount() {
return INSTANCE;
}
@Override
public String dispatch() {
return "Ordering.natural()";
}
private NaturalOrdering() {}
@GwtIncompatible @J2ktIncompatible private static final long serialVersionUID = 0;
}
Run 1
Although the code has a simple class structure and some comments, the method names are completely unrelated to their actual implementations (publish, removeUser, buildNode, analyze, removeCount, dispatch). This severely obscures intent. There is a commented-out TODO referencing future work that might explain temporary naming, but currently the code is ambiguous. Nesting is minimal and line length is acceptable. However, readability is deeply undermined by the mismatch between names and behavior. One action per line is mostly followed. The type parameters and casts are complex, and the use of @SuppressWarnings with unclear TODO comments adds confusion. Overall, the code is technically formatted but practically unreadable without external context or proper naming.
Run 2
The code has a clear structure with logical separation of fields, methods, and constructors, but method names like 'publish', 'removeUser', 'buildNode', 'analyze', 'removeCount', and 'dispatch' are confusing and do not reflect their actual purposes (e.g., compare, nullsFirst, nullsLast, reverse, readResolve, toString). This significantly hurts clarity of intent. Nesting is flat, which is good, and action granularity is reasonable. However, the excessive use of @SuppressWarnings and TODO comments adds noise. The code is concise but suffers from ambiguous naming, making the reading flow unnatural despite a simple overall structure. The serialization and lazy initialization patterns are standard but obscured by poor method names, reducing maintainability and readability.
Run 3
The code is poorly readable due to nonsensical method names like `publish`, `removeUser`, `buildNode`, `analyze`, `removeCount`, and `dispatch`, which do not reflect their actual functionality (e.g., comparing, returning nullsFirst/nullsLast, reverse ordering, singleton readResolve, toString). This breaks clarity of intent and reading flow. The custom nullable annotations add noise. The lazy initialization blocks are straightforward but use unconventional variable names (`target`, `option`). The class has a clear overall structure—singleton field, methods, private constructor—but the method name/behavior mismatch dominates the negative assessment. Nesting is minimal (one `if` per lazy method), and length is concise, but action granularity is inconsistent. The code appears obfuscated, likely for an exercise, not production-quality readable code.
Run 1
Code Structure: Logically organized around a singleton ordering implementation, with small methods and clearly grouped cached fields. Nesting: Shallow; only single-level conditionals appear. Clarity of intent: The class documentation and comparison logic are clear, but misleading names such as publish, removeUser, buildNode, analyze, removeCount, and dispatch obscure the methods’ actual roles. Generic variable names and unexplained unchecked casts further reduce clarity. Code length: Concise overall, though repeated suppression comments add noise. Action granularity: Mostly one action per line, but chained assignments combine local assignment and cache updates, and compressed annotation/declaration lines are harder to scan. Reading flow: Generally natural, moving from fields to operations and singleton support, but inconsistent naming and dense generic/nullability syntax interrupt comprehension.
Run 2
Code Structure: The class is logically organized around a singleton ordering, with small methods and related cache fields grouped together. Nesting: Very shallow; only simple conditional cache initialization appears. Clarity of intent: The main weakness is misleading method names such as publish, removeUser, buildNode, analyze, and dispatch, which obscure comparison, null placement, reversal, and string representation. Generic variable names also reduce clarity. Code length: Reasonably concise, although repeated suppression annotations and unresolved TODO comments add noise. Action granularity: Most lines perform one action, but chained assignments combine local updates and cache initialization. Reading flow: Method bodies are straightforward, yet inaccurate naming, dense generic annotations, and compact annotation placement interrupt otherwise natural reading.
Run 3
Code Structure: The class is logically organized around singleton initialization, comparison, cached orderings, and utility methods. Nesting: Very shallow, with only simple conditional blocks. Clarity of intent: The class documentation and field names help, but misleading method names such as publish, removeUser, buildNode, analyze, and dispatch obscure their actual purposes; generic locals like target and option add ambiguity. Code length: Short methods keep the implementation concise, although repeated annotations and unresolved TODO comments add clutter. Action granularity: Most lines perform one action, but chained assignments combine local assignment and cache updates. Reading flow: Method bodies are straightforward, yet dense generic types, casts, annotations, and inconsistent semantic naming interrupt comprehension. Overall, the clean structure is substantially undermined by unclear naming.