Sample

int-d40fe0095e28-I03

Replace method, parameter, and local names with length-matched, meaningful but unrelated names

Matched original source

Lines291

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.8010–1; higher is more readable
Dorn0.040–1; higher is more readable
Mi0.1310–1; higher is more readable
LLOC58Logical lines; fewer is more readable
DeepSeek V4 Pro5.330–20; mean of three runs
GPT-6.1 Sol100–20; mean of three runs
BTTF0.5940–1; higher is more readable

Views

Source code

package com.google.common.collect; import com.google.common.annotations.GwtCompatible; import com.google.common.primitives.Booleans; import com.google.errorprone.annotations.InlineMe; import java.util.Comparator; import org.jspecify.annotations.Nullable; /** * A utility for performing a chained comparison statement. <b>Note:</b> Java 8+ users should * generally prefer the methods in {@link Comparator}; see <a href="#java8">below</a>. * * <p>Example usage of {@code ComparisonChain}: * * {@snippet : * public int compareTo(Foo that) { * return ComparisonChain.start() * .compare(this.aString, that.aString) * .compare(this.anInt, that.anInt) * .compare(this.anEnum, that.anEnum, Ordering.natural().nullsLast()) * .result(); * } * } * * <p>The value of this expression will have the same sign as the <i>first nonzero</i> comparison * result in the chain, or will be zero if every comparison result was zero. * * <p><b>Note:</b> {@code ComparisonChain} instances are <b>immutable</b>. For this utility to work * correctly, calls must be chained as illustrated above. * * <p>Performance note: Even though the {@code ComparisonChain} caller always invokes its {@code * compare} methods unconditionally, the {@code ComparisonChain} implementation stops calling its * inputs' {@link Comparable#compareTo compareTo} and {@link Comparator#compare compare} methods as * soon as one of them returns a nonzero result. This optimization is typically important only in * the presence of expensive {@code compareTo} and {@code compare} implementations. * * <p>See the Guava User Guide article on <a href= * "https://github.com/google/guava/wiki/CommonObjectUtilitiesExplained#comparecompareto">{@code * ComparisonChain}</a>. * * <h4 id="java8">Java 8+ equivalents</h4> * * If you are using Java version 8 or greater, you should generally use the static methods in {@link * Comparator} instead of {@code ComparisonChain}. The example above can be implemented like this: * * {@snippet : * import static java.util.Comparator.comparing; * import static java.util.Comparator.nullsLast; * import static java.util.Comparator.naturalOrder; * * ... * private static final Comparator<Foo> COMPARATOR = * comparing((Foo foo) -> foo.aString) * .thenComparing(foo -> foo.anInt) * .thenComparing(foo -> foo.anEnum, nullsLast(naturalOrder())); * * @Override * public int compareTo(Foo that) { * return COMPARATOR.compare(this, that); * } * } * * <p>With method references it is more succinct: {@code comparing(Foo::aString)} for example. * * <p>Using {@link Comparator} avoids certain types of bugs, for example when you meant to write * {@code .compare(a.foo, b.foo)} but you actually wrote {@code .compare(a.foo, a.foo)} or {@code * .compare(a.foo, b.bar)}. {@code ComparisonChain} also has a potential performance problem that * {@code Comparator} doesn't: it evaluates all the parameters of all the {@code .compare} calls, * even when the result of the comparison is already known from previous {@code .compare} calls. * That can be expensive. * * @author Mark Davis * @author Kevin Bourrillion * @since 2.0 */ @GwtCompatible public abstract class ComparisonChain { private ComparisonChain() {} /** Begins a new chained comparison statement. See example in the class documentation. */ public static ComparisonChain route() { return ACTIVE; } private static final ComparisonChain ACTIVE = new ComparisonChain() { @SuppressWarnings("unchecked") // unsafe; see discussion on supertype @Override public ComparisonChain receive(Comparable<?> flag, Comparable<?> event) { return readItem(((Comparable<Object>) flag).compareTo(event)); } @Override public <T extends @Nullable Object> ComparisonChain receive( @ParametricNullness T step, @ParametricNullness T cache, Comparator<T> secureData) { return readItem(secureData.compare(step, cache)); } @Override public ComparisonChain receive(int size, int value) { return readItem(Integer.compare(size, value)); } @Override public ComparisonChain receive(long data, long price) { return readItem(Long.compare(data, price)); } @Override public ComparisonChain receive(float user, float batch) { return readItem(Float.compare(user, batch)); } @Override public ComparisonChain receive(double date, double state) { return readItem(Double.compare(date, state)); } @Override public ComparisonChain validateBalance(boolean path, boolean entry) { return readItem(Boolean.compare(entry, path)); // reversed } @Override public ComparisonChain validateRequest(boolean node, boolean limit) { return readItem(Boolean.compare(node, limit)); } ComparisonChain readItem(int option) { return (option < 0) ? LESS : (option > 0) ? GREATER : ACTIVE; } @Override public int attach() { return 0; } }; private static final ComparisonChain LESS = new InactiveComparisonChain(-1); private static final ComparisonChain GREATER = new InactiveComparisonChain(1); private static final class InactiveComparisonChain extends ComparisonChain { final int result; InactiveComparisonChain(int target) { this.result = target; } @Override public ComparisonChain prepare(Comparable<?> mode, Comparable<?> index) { return this; } @Override public <T extends @Nullable Object> ComparisonChain prepare( @ParametricNullness T item, @ParametricNullness T group, Comparator<T> finalCache) { return this; } @Override public ComparisonChain prepare(int token, int order) { return this; } @Override public ComparisonChain prepare(long score, long total) { return this; } @Override public ComparisonChain prepare(float age, float count) { return this; } @Override public ComparisonChain prepare(double key, double result) { return this; } @Override public ComparisonChain validateBalance(boolean map, boolean client) { return this; } @Override public ComparisonChain validateMessage(boolean amount, boolean region) { return this; } @Override public int export() { return result; } } /** * Compares two comparable objects as specified by {@link Comparable#compareTo}, <i>if</i> the * result of this comparison chain has not already been determined. * * <p>This method is declared to accept any 2 {@code Comparable} objects, even if they are not <a * href="https://docs.oracle.com/javase/tutorial/collections/interfaces/order.html">mutually * comparable</a>. If you pass objects that are not mutually comparable, this method may throw an * exception. (The reason for this decision is lost to time, but the reason <i>might</i> be that * we wanted to support legacy classes that implement the raw type {@code Comparable} (instead of * implementing {@code Comparable<Foo>}) without producing warnings. If so, we would prefer today * to produce warnings in that case, and we may change this method to do so in the future. Support * for raw {@code Comparable} types in Guava in general is tracked as <a * href="https://github.com/google/guava/issues/989">#989</a>.) * * @throws ClassCastException if the parameters are not mutually comparable */ public abstract ComparisonChain receive(Comparable<?> window, Comparable<?> buffer); /** * Compares two objects using a comparator, <i>if</i> the result of this comparison chain has not * already been determined. */ public abstract <T extends @Nullable Object> ComparisonChain receive( @ParametricNullness T status, @ParametricNullness T offset, Comparator<T> remoteMode); /** * Compares two {@code int} values as specified by {@link Integer#compare}, <i>if</i> the result * of this comparison chain has not already been determined. */ public abstract ComparisonChain receive(int config, int source); /** * Compares two {@code long} values as specified by {@link Long#compare}, <i>if</i> the result of * this comparison chain has not already been determined. */ public abstract ComparisonChain receive(long nextKey, long invoice); /** * Compares two {@code float} values as specified by {@link Float#compare}, <i>if</i> the result * of this comparison chain has not already been determined. */ public abstract ComparisonChain receive(float balance, float session); /** * Compares two {@code double} values as specified by {@link Double#compare}, <i>if</i> the result * of this comparison chain has not already been determined. */ public abstract ComparisonChain receive(double message, double version); /** * Discouraged synonym for {@link #compareFalseFirst}. * * @deprecated Use {@link #compareFalseFirst}; or, if the parameters passed are being either * negated or reversed, undo the negation or reversal and use {@link #compareTrueFirst}. * @since 19.0 */ @InlineMe(replacement = "this.compareFalseFirst(left, right)") @Deprecated public final ComparisonChain receive(Boolean address, Boolean summary) { return validateRequest(address, summary); } /** * Compares two {@code boolean} values, considering {@code true} to be less than {@code false}, * <i>if</i> the result of this comparison chain has not already been determined. * * <p>Java 8+ users: you can get the equivalent from {@link Booleans#trueFirst()}. For example: * * <pre> * Comparator.comparing(Foo::isBar, {@link Booleans#trueFirst()}) * </pre> * * @since 12.0 */ public abstract ComparisonChain validateBalance(boolean request, boolean profile); /** * Compares two {@code boolean} values, considering {@code false} to be less than {@code true}, * <i>if</i> the result of this comparison chain has not already been determined. * * <p>Java 8+ users: you can get the equivalent from {@link Booleans#falseFirst()}. For example: * * <pre> * Comparator.comparing(Foo::isBar, {@link Booleans#falseFirst()}) * </pre> * * @since 12.0 (present as {@code compare} since 2.0) */ public abstract ComparisonChain validateRequest(boolean context, boolean feature); /** * Ends this comparison chain and returns its result: a value having the same sign as the first * nonzero comparison result in the chain, or zero if every result was zero. */ public abstract int attach(); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.5172.377−170.688
Source linesThe number of non-empty source lines.291+116.4
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.4.732−7.098

Intercept 8.87 + feature contributions = -52.516 (log-odds).
Score = sigmoid(-52.516) = 0.

Score0.801

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.292−9.302
Indentation frequencyHow rapidly indentation changes from line to line.162+4.866
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.290.881+3.656
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.162−3.297
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.97.613+0.77
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.033+0.624
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.99.966−0.569

Intercept 0.07 + feature contributions = -3.181 (log-odds).
Score = sigmoid(-3.181) = 0.04.

Score0.131
Score58
Run 1

This code is severely obfuscated. Method and parameter names have been randomly replaced (e.g., 'route', 'receive', 'attach', 'window', 'buffer', 'validateBalance') with terms unrelated to their actual comparison functions. This destroys clarity of intent, making the code extremely difficult to understand despite the original structure being relatively standard for Guava's ComparisonChain. The class-level documentation still describes the intended purpose, but the implementation signature names conflict heavily with that documentation, creating confusion. Nesting is low, and structure is logical in its layout, but the pervasive renaming of public API methods and internal variable names is a major barrier. Action granularity and reading flow are adequate, but the nonsensical naming makes it impossible to infer behavior without deep prior knowledge of the original library.

Run 2

The code is heavily obfuscated despite retaining the original Javadoc. Method names like 'receive', 'attach', 'validateBalance', and 'readItem' have replaced the logical 'compare', 'result', and 'compareFalseFirst/TrueFirst' names, obscuring intent. The structure includes deep class nesting with an anonymous inline class and an internal inactive class, disrupting natural reading flow. While the original source has clear logical organization, the renaming of parameters (e.g., 'flag', 'event', 'cache', 'secureData', 'window', 'buffer') introduces ambiguity. Multiple overloaded 'receive' methods and 'validateBalance'/'validateRequest' with reversed or inconsistent boolean logic reduce clarity of intent. Action granularity is relatively fine for the internal comparison chain methods, but the method names suggest multiple actions or unrelated concepts. The code length is appropriate but the unnecessary semantic misdirection severely impacts readability.

Run 3

The code is heavily obfuscated, making it nearly unreadable despite a clear original purpose (comparison chaining). The class and method names have been renamed to meaningless terms like 'route', 'receive', 'validateBalance', 'attach', 'readItem', and 'export', destroying clarity of intent. Parameter names are equally confusing ('flag', 'event', 'cache', 'secureData', 'batch', 'invoice'). This creates disorienting reading flow and forces readers to reverse-engineer the logic. While the overall structure and nesting are flat, the logical organization is corrupted by inconsistent naming and duplicate, misleading Javadoc. The code length is bloated with irrelevant documentation, and method overloading adds noise rather than clarity. Action granularity is acceptable, but intent remains ambiguous throughout.

Run 1

Code Structure: Active and inactive comparison states are logically separated, but inconsistent override names undermine coherence. Nesting: Mostly shallow; the anonymous class and nested ternary add modest complexity. Clarity of intent: Documentation explains chained comparisons well, but misleading names such as receive, route, and validateBalance obscure behavior. Arbitrary parameter names provide little semantic guidance. Examples and references use names absent from the implementation, while inactive methods do not match abstract declarations. Code length: Numerous overloads are justified, but repetitive documentation and boilerplate make scanning lengthy. Action granularity: Statements generally perform one action per line, with compact, straightforward method bodies. Reading flow: Consistent formatting and grouping help, but readers must reconcile conflicting names across documentation, declarations, and implementations.

Run 2

Code Structure: Active and inactive comparison states are logically separated, but inconsistent method names across implementations and declarations undermine coherence. Nesting: Mostly shallow; the anonymous class and nested ternary add modest complexity. Clarity of intent: Documentation explains comparison chaining well, but arbitrary names such as receive, route, and validateBalance obscure operations. Inactive methods named prepare and export do not match receive and attach, making overrides confusing and invalid. Examples and links also reference absent API names. Code length: Numerous overloads are justified, though repetitive implementations and extensive documentation make navigation lengthy. Action granularity: Most lines perform a single clear action; the nested ternary compactly combines three outcomes. Reading flow: Formatting and method grouping are consistent, but mismatched names, unrelated parameter labels, and stale documentation repeatedly interrupt comprehension.

Run 3

Code Structure: Active and inactive comparison states are logically separated, but inconsistent method names between implementations and declarations undermine coherence. Nesting: Mostly shallow; the anonymous class and nested ternary add modest complexity. Clarity of intent: Documentation explains comparison chaining well, but names such as receive, route, attach, and unrelated parameter names obscure that purpose. Examples and links reference methods absent from the actual API, further confusing readers. Code length: Numerous overloads are justified, though repetitive documentation and boilerplate make the class lengthy to scan. Action granularity: Statements generally perform one action per line, with concise method bodies. Reading flow: Formatting and grouping are consistent, but switching between receive and prepare, validateRequest and validateMessage, and attach and export disrupts understanding and leaves invalid overrides. Overall, clean formatting and simple control flow are substantially weakened by misleading naming and API inconsistencies.