Sample

int-d3f97753e91a-I10

Remove about 40% of line-break groups while retaining structure

Matched original source

Lines228

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7210–1; higher is more readable
Dorn0.0040–1; higher is more readable
Mi0.1250–1; higher is more readable
LLOC58Logical lines; fewer is more readable
DeepSeek V4 Pro40–20; mean of three runs
GPT-6.1 Sol120–20; mean of three runs
BTTF0.5390–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 start() { return ACTIVE; } private static final ComparisonChain ACTIVE = new ComparisonChain() { @SuppressWarnings("unchecked") // unsafe; see discussion on supertype @Override public ComparisonChain compare(Comparable<?> left, Comparable<?> right) { return classify(((Comparable<Object>) left).compareTo(right)); } @Override public <T extends @Nullable Object> ComparisonChain compare( @ParametricNullness T left, @ParametricNullness T right, Comparator<T> comparator) { return classify(comparator.compare(left, right)); } @Override public ComparisonChain compare(int left, int right) { return classify(Integer.compare(left, right)); } @Override public ComparisonChain compare(long left, long right) { return classify(Long.compare(left, right)); } @Override public ComparisonChain compare(float left, float right) { return classify(Float.compare(left, right)); } @Override public ComparisonChain compare(double left, double right) { return classify(Double.compare(left, right)); } @Override public ComparisonChain compareTrueFirst(boolean left, boolean right) { return classify(Boolean.compare(right, left)); // reversed } @Override public ComparisonChain compareFalseFirst(boolean left, boolean right) { return classify(Boolean.compare(left, right)); } ComparisonChain classify(int result) { return (result < 0) ? LESS : (result > 0) ? GREATER : ACTIVE; } @Override public int result() { 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 result) { this.result = result; } @Override public ComparisonChain compare(Comparable<?> left, Comparable<?> right) { return this; } @Override public <T extends @Nullable Object> ComparisonChain compare( @ParametricNullness T left, @ParametricNullness T right, Comparator<T> comparator) { return this; } @Override public ComparisonChain compare(int left, int right) { return this; } @Override public ComparisonChain compare(long left, long right) { return this; } @Override public ComparisonChain compare(float left, float right) { return this; } @Override public ComparisonChain compare(double left, double right) { return this; } @Override public ComparisonChain compareTrueFirst(boolean left, boolean right) { return this; } @Override public ComparisonChain compareFalseFirst(boolean left, boolean right) { return this; } @Override public int result() { 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 compare(Comparable<?> left, Comparable<?> right); /** * 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 compare( @ParametricNullness T left, @ParametricNullness T right, Comparator<T> comparator); /** * 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 compare(int left, int right); /** * 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 compare(long left, long right); /** * 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 compare(float left, float right); /** * 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 compare(double left, double right); /** * 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 compare(Boolean left, Boolean right) { return compareFalseFirst(left, right); } /** * 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 compareTrueFirst(boolean left, boolean right); /** * 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 compareFalseFirst(boolean left, boolean right); /** * 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 result(); }

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.4600.914−151.83
Source linesThe number of non-empty source lines.228+91.2
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.767−7.151

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

Score0.721

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.229−7.072
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.214.983−5.441
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.227.833+2.775
Indentation frequencyHow rapidly indentation changes from line to line.99+2.687
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.214.987+2.664
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.99−1.851
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.033+0.617

Intercept 0.07 + feature contributions = -5.55 (log-odds).
Score = sigmoid(-5.55) = 0.004.

Score0.125
Score58
Run 1

The code is extremely difficult to read due to poor structure and formatting. Multiple statements are crammed onto single lines, violating the 'one action per line' principle. The class definition, constructor, and method declarations are jumbled together, making the logical organization unclear. Nesting is exacerbated by the lack of visual separation, particularly in the anonymous class and inner class definitions. While the intent of the overall class is explained in the extensive Javadoc, the implementation details are obscured by inconsistent spacing and line breaks. The code is unnecessarily long due to the verbose but poorly formatted abstract methods and their implementations. Reading flow is severely disrupted, forcing the reader to parse dense, unformatted blocks of code. This code would benefit immensely from standard formatting and separation of concerns.

Run 2

The code is structurally logical (using abstract class with active/inactive chain states), but its formatting is severely compressed. Multiple imports, methods, and comments are crammed onto single lines, making it difficult to scan. The nesting is moderate—mostly due to anonymous and inner classes—but the dense layout makes it feel deeper. Intent is documented well in Javadoc, but the compressed method bodies obscure the simple logic. Code length is excessive because of extensive comments, though the implementation itself is concise. Action granularity is poor: many lines contain multiple statements or method definitions. Reading flow is unnatural; the eye must parse long, dense lines instead of a consistent vertical rhythm. While the design is sound, the formatting drags readability down considerably.

Run 3

This code is extremely difficult to read. The import statements are crammed onto the same line as the package declaration, and multiple class member declarations are frequently placed on single lines, violating action granularity and reading flow. The structure is tangled: anonymous inner class implementation is interleaved with method bodies and closing braces, with methods like 'compare' and 'classify' mashed together. Javadoc comments are inconsistently formatted, sometimes on the same line as methods. Nesting is not deeply indented, but the lack of line breaks creates visual chaos. The intent is buried under formatting clutter despite clear method names. Overall, the code's logical organization is destroyed by formatting inconsistencies that make it nearly unreadable, despite the underlying design being sound.

Run 1

Code Structure: Logical separation into active/inactive states and a documented public API, but compressed formatting obscures boundaries. Nesting: Generally shallow; the anonymous implementation and nested class add modest complexity, while the nested ternary requires extra parsing. Clarity of intent: Descriptive names, comprehensive documentation, and examples clearly explain comparison chaining and short-circuit behavior. Code length: Individual methods are concise, but repeated overloads and extensive documentation make the file lengthy, mostly for legitimate API coverage. Action granularity: Many lines combine imports, declarations, annotations, braces, or multiple methods, undermining scanability despite simple method bodies. Reading flow: The conceptual progression is sensible, but inconsistent line breaks and comments attached to declarations repeatedly interrupt reading. Overall, understandable design and strong documentation are substantially weakened by irregular, crowded formatting.

Run 2

1. Code Structure: Logical separation into active/inactive comparison states and public API declarations, but compressed formatting obscures boundaries. 2. Nesting: Generally shallow; anonymous and nested classes add modest complexity, and the nested ternary requires some parsing. 3. Clarity of intent: Descriptive names, extensive documentation, and examples clearly explain chained comparison and short-circuit behavior. 4. Code length: Implementations are concise, but repeated overloads and lengthy documentation make scanning slower, although much is justified by the API. 5. Action granularity: Individual methods usually perform one action, but multiple imports, declarations, annotations, and method boundaries frequently share lines. 6. Reading flow: Conceptual ordering is sensible, yet inconsistent line breaks, inline braces, and comments attached to declarations repeatedly interrupt natural reading.

Run 3

Code Structure: Logically separates active comparisons, inactive states, and public API declarations, although compressed formatting obscures these boundaries. Nesting: Mostly shallow; the anonymous implementation and nested class add manageable complexity, while the nested ternary slightly hinders scanning. Clarity of intent: Descriptive names and extensive documentation clearly explain comparison chaining and short-circuit behavior. Code length: Individual methods are concise, but repeated overloads and lengthy documentation make the file cumbersome, though much is justified by the API. Action granularity: Most methods perform one action, but multiple imports, declarations, annotations, and method boundaries frequently share lines. Reading flow: Inconsistent line breaks, crowded braces, and comments attached to declarations interrupt an otherwise logical progression. Overall, the design is understandable, but formatting substantially reduces readability.