Sample

int-f7ec88687689-I06

Invert eligible conditions and exchange their branches

Matched original source

Lines82

Scores

MethodScoreScale
Posnett0.0460–1; higher is more readable
Scalabrino0.8530–1; higher is more readable
Dorn0.7660–1; higher is more readable
Mi0.3820–1; higher is more readable
LLOC15Logical lines; fewer is more readable
DeepSeek V4 Pro180–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.6870–1; higher is more readable

Views

Source code

package com.google.common.io; import com.google.common.annotations.GwtIncompatible; import com.google.common.annotations.J2ktIncompatible; import com.google.errorprone.annotations.CanIgnoreReturnValue; import java.io.DataInput; import java.io.IOException; import org.jspecify.annotations.Nullable; /** * An extension of {@code DataInput} for reading from in-memory byte arrays; its methods offer * identical functionality but do not throw {@link IOException}. * * <p><b>Warning:</b> The caller is responsible for not attempting to read past the end of the * array. If any method encounters the end of the array prematurely, it throws {@link * IllegalStateException} to signify <i>programmer error</i>. This behavior is a technical violation * of the supertype's contract, which specifies a checked exception. * * @author Kevin Bourrillion * @since 1.0 */ @J2ktIncompatible @GwtIncompatible public interface ByteArrayDataInput extends DataInput { @Override void readFully(byte[] b); @Override void readFully(byte[] b, int off, int len); // not guaranteed to skip n bytes so result should NOT be ignored // use ByteStreams.skipFully or one of the read methods instead @Override int skipBytes(int n); @CanIgnoreReturnValue // to skip a byte @Override boolean readBoolean(); @CanIgnoreReturnValue // to skip a byte @Override byte readByte(); @CanIgnoreReturnValue // to skip a byte @Override int readUnsignedByte(); @CanIgnoreReturnValue // to skip some bytes @Override short readShort(); @CanIgnoreReturnValue // to skip some bytes @Override int readUnsignedShort(); @CanIgnoreReturnValue // to skip some bytes @Override char readChar(); @CanIgnoreReturnValue // to skip some bytes @Override int readInt(); @CanIgnoreReturnValue // to skip some bytes @Override long readLong(); @CanIgnoreReturnValue // to skip some bytes @Override float readFloat(); @CanIgnoreReturnValue // to skip some bytes @Override double readDouble(); @CanIgnoreReturnValue // to skip a line @Override @Nullable String readLine(); @CanIgnoreReturnValue // to skip a field @Override String readUTF(); }

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.1135.35−37.467
Source linesThe number of non-empty source lines.82+32.8
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.828−7.241

Intercept 8.87 + feature contributions = -3.038 (log-odds).
Score = sigmoid(-3.038) = 0.046.

Score0.853

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.83−1.902
Indentation frequencyHow rapidly indentation changes from line to line.57+1.234
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.98.699+0.788
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.81.832+0.734
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.88−0.565
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.053+0.431
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 1.188 (log-odds).
Score = sigmoid(1.188) = 0.766.

Score0.382
Score15
Run 1

The code is highly readable due to its logical structure and clear intent. The interface declaration is straightforward, with a concise yet informative Javadoc explaining the behavior and contract deviations. Method declarations are flat, with no nesting, and each method is presented on a single line, making the structure easy to scan. The use of @Override and @CanIgnoreReturnValue annotations is consistent, and the brief comments for each method clarify the intended use when return values are ignored. Imports are organized and limited. The code avoids unnecessary length, with only essential methods and documentation. Reading flow is natural, grouping related read methods logically. Overall, this is an exemplary implementation of a well-documented, minimal interface.

Run 2

The code is highly readable due to its logical structure, flat nesting, and clear intent. It is a concise interface definition that extends DataInput, with a well-documented Javadoc explaining the key behavioral difference (no IOException). Each method is declared on a single line, often with a brief comment clarifying the return value's purpose, which aids readability. The use of annotations like @CanIgnoreReturnValue is consistent and purposeful. The only minor deductions are for the slightly repetitive comments on every method, which some might consider verbose, and the warning in the Javadoc about unchecked exceptions is important but could be overlooked by readers scanning quickly. Overall, it demonstrates excellent clarity and adherence to clean code principles.

Run 3

This code is highly readable. It is a well-structured interface extending DataInput, with clear Javadoc explaining its purpose and the important deviation from the parent contract. The organization is logical: imports, documentation, then method declarations grouped by type. Nesting is non-existent as it is an interface. The annotations (@CanIgnoreReturnValue) and concise comments clarify the intent for each method override, which is critical for understanding why the return values might be ignored. The code is concise, with only necessary method signatures, and each declaration is on its own line, maintaining a clean, natural reading flow.

Run 1

Code Structure: A well-organized interface with logically grouped read operations and consistent declarations. Nesting: Completely flat, with no nested control flow. Clarity of intent: The interface name, familiar DataInput method names, and detailed documentation clearly explain its purpose and exception behavior; abbreviated parameter names are a minor weakness. Code length: Appropriate for redeclaring the inherited API without checked exceptions, though repeated annotations and comments add some visual repetition. Action granularity: Each method declaration occupies its own line, with annotations clearly associated with it. Reading flow: Consistent spacing and ordering make scanning natural; the lack of a blank line after the package declaration slightly reduces visual separation.

Run 2

Code Structure: The interface is logically organized, with imports, contract documentation, and consistently formatted method declarations. Nesting: There is no nested control flow; all declarations are flat. Clarity of intent: The documentation clearly explains the purpose and exception behavior, while standard DataInput method names make operations recognizable. Brief parameter names are a minor clarity limitation. Code length: The code is appropriately concise; repeated annotations are useful API metadata rather than unnecessary verbosity. Action granularity: Each method declaration occupies its own line, with annotations clearly separated. Reading flow: Consistent spacing and ordering make the interface easy to scan. Minor presentation issues include the lack of separation between the package and imports and slightly repetitive inline comments.

Run 3

Code Structure: A well-organized interface with consistent method declarations and logical grouping of related reads. Nesting: Completely flat aside from the interface scope. Clarity of intent: The Javadoc clearly explains the purpose, exception behavior, and caller responsibilities; annotations and comments clarify return-value handling. Code length: Concise for the API exposed, although repeated annotations and skip comments add minor visual repetition. Action granularity: Each method declaration occupies its own line, with annotations cleanly separated. Reading flow: Predictable formatting and method ordering make scanning easy. Minor drawbacks are abbreviated parameter names and the lack of spacing between the package declaration and imports.