Sample

int-3749a6b82f28-I11

Split eligible integer literals into pairs of short-named intermediate variables

Matched original source

Lines57

Scores

MethodScoreScale
Posnett0.9980–1; higher is more readable
Scalabrino0.9310–1; higher is more readable
Dorn0.7060–1; higher is more readable
Mi0.3350–1; higher is more readable
LLOC3Logical lines; fewer is more readable
DeepSeek V4 Pro17.670–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.6580–1; higher is more readable

Views

Source code

package com.google.common.collect; import com.google.common.annotations.GwtCompatible; import com.google.errorprone.annotations.CanIgnoreReturnValue; import com.google.errorprone.annotations.DoNotMock; import java.util.Iterator; import java.util.NoSuchElementException; import org.jspecify.annotations.Nullable; /** * An iterator that supports a one-element lookahead while iterating. * * <p>See the Guava User Guide article on <a href= * "https://github.com/google/guava/wiki/CollectionHelpersExplained#peekingiterator">{@code * PeekingIterator}</a>. * * @author Mick Killianey * @since 2.0 */ @DoNotMock("Use Iterators.peekingIterator") @GwtCompatible public interface PeekingIterator<E extends @Nullable Object> extends Iterator<E> { /** * Returns the next element in the iteration, without advancing the iteration. * * <p>Calls to {@code peek()} should not change the state of the iteration, except that it * <i>may</i> prevent removal of the most recent element via {@link #remove()}. * * @throws NoSuchElementException if the iteration has no more elements according to {@link * #hasNext()} */ @ParametricNullness E peek(); /** * {@inheritDoc} * * <p>The objects returned by consecutive calls to {@link #peek()} then {@link #next()} are * guaranteed to be equal to each other. */ @CanIgnoreReturnValue @Override @ParametricNullness E next(); /** * {@inheritDoc} * * <p>Implementations may or may not support removal when a call to {@link #peek()} has occurred * since the most recent call to {@link #next()}. * * @throws IllegalStateException if there has been a call to {@link #peek()} since the most recent * call to {@link #next()} and this implementation does not support this sequence of calls * (optional) */ @Override void remove(); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Source linesThe number of non-empty source lines.57+22.8
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.560.253−18.488
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.763−7.145

Intercept 8.87 + feature contributions = 6.037 (log-odds).
Score = sigmoid(6.037) = 0.998.

Score0.931

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.57−0.982
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.96.621+0.754
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.029+0.656
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.948−0.568
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.56.881+0.385
Indentation frequencyHow rapidly indentation changes from line to line.26+0.162

Intercept 0.07 + feature contributions = 0.876 (log-odds).
Score = sigmoid(0.876) = 0.706.

Score0.335
Score3
Run 1

The code is highly readable. It has clear structure as an interface with well-organized Javadoc comments, a single logical purpose, and no complex nesting. Intent is unambiguous through descriptive method names and documentation. The code is concise, with each method declaration on its own line and no unnecessary verbosity. Action granularity is appropriate for an interface definition. Reading flow is natural: the peek() method is defined first as the primary addition, followed by overridden next() and remove() with clarifying documentation. Minor deductions come from the long Javadoc blocks which somewhat interrupt the code flow, and the generic type parameter '<E extends @Nullable Object>' adds slight complexity. Overall, the interface is clean, well-documented, and easy to understand.

Run 2

This code is highly readable. It defines a single, clear interface with an obvious purpose: adding peek functionality to an iterator. The structure is logical, with imports, annotations, and methods arranged conventionally. Nesting is minimal; the code is flat and straightforward. Each method has a clear intent, supported by concise Javadoc that explains behavior and edge cases. The length is appropriate for the functionality, avoiding unnecessary complexity. Action granularity is one operation per line. Reading flow is natural, moving from interface declaration to method signatures with their contracts. The use of annotations and documentation enhances understanding without cluttering the code. Minor deductions are for some boilerplate annotations and the inherent verbosity of Javadoc, but these are standard practices that improve clarity for users of the API.

Run 3

This code is highly readable. The structure is logical, with clear separation between the interface declaration, method signatures, and documentation. Nesting is minimal, as the code is flat and straightforward. Intent is clearly conveyed through comprehensive Javadoc comments explaining the behavior and contract of each method. The code is concise and not unnecessarily long, although the Javadoc is detailed, which adds to clarity rather than detracting from it. Action granularity is appropriate—each method declaration occupies its own logical block with annotations and documentation. The reading flow is natural, starting with the package and imports, followed by the interface declaration and its methods in a logical order. Overall, this is an excellent example of clean, well-documented Java code.

Run 1

Code Structure: A well-organized interface with imports, type documentation, and logically ordered method declarations. Nesting: Flat declarations with no nested control flow. Clarity of intent: Descriptive names and precise Javadoc clearly explain lookahead behavior, guarantees, and removal restrictions. Code length: The interface is concise; its substantial documentation is useful rather than redundant. Action granularity: Each method declaration and annotation occupies its own line, with no bundled actions. Reading flow: The progression from peek() to next() to remove() naturally follows iterator usage. Minor distractions include tightly packed package/import formatting and awkward wrapping in the documentation link.

Run 2

Code Structure: A well-organized interface with imports, class-level documentation, and three clearly separated method declarations. Nesting: Flat structure with no nested control flow. Clarity of intent: Descriptive naming and precise Javadoc explain lookahead behavior, return guarantees, and removal constraints. Code length: Declarations are concise; documentation is longer but useful for defining the contract. Action granularity: Each declaration and annotation occupies its own line, with no combined actions. Reading flow: Methods follow a natural progression from peek to next to remove. Minor readability friction comes from annotation density, wrapped Javadoc links, and the missing blank line between the package declaration and imports.

Run 3

Code Structure: A small, logically organized interface with imports, class documentation, and clearly separated method contracts. Nesting: Flat declarations with no nested control flow. Clarity of intent: Descriptive names and precise Javadocs explain lookahead behavior, guarantees, and removal constraints. Code length: The interface is concise; documentation is longer than the declarations but provides useful contract details rather than unnecessary repetition. Action granularity: Each method declaration and annotation occupies its own line, with no combined operations. Reading flow: The progression from peek() to next() to remove() naturally follows iterator usage. Minor readability friction comes from annotation density and awkward wrapping in the documentation link.