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;
@J2ktIncompatible
@GwtIncompatible
public interface ByteArrayDataInput extends DataInput {
@Override
void readFully(byte[] b);
@Override
void readFully(byte[] b, int off, int len);
@Override
int skipBytes(int n);
@CanIgnoreReturnValue
@Override
boolean readBoolean();
@CanIgnoreReturnValue
@Override
byte readByte();
@CanIgnoreReturnValue
@Override
int readUnsignedByte();
@CanIgnoreReturnValue
@Override
short readShort();
@CanIgnoreReturnValue
@Override
int readUnsignedShort();
@CanIgnoreReturnValue
@Override
char readChar();
@CanIgnoreReturnValue
@Override
int readInt();
@CanIgnoreReturnValue
@Override
long readLong();
@CanIgnoreReturnValue
@Override
float readFloat();
@CanIgnoreReturnValue
@Override
double readDouble();
@CanIgnoreReturnValue
@Override
@Nullable String readLine();
@CanIgnoreReturnValue
@Override
String readUTF();
}
Run 1
The code is an interface declaration that is highly readable due to its logical structure and clear intent. It follows standard Java conventions with proper imports and annotations, and each method override is concise with one action per line. The use of @CanIgnoreReturnValue annotations before each method consistently communicates return value handling expectations. The nesting is minimal (only one level), and the reading flow is natural, grouping similar methods together. The minor deduction is due to the excessive blank lines between the imports and the interface declaration, which slightly disrupts visual flow, and the unnecessary @Nullable annotation on readLine (which returns an empty string, not null, according to DataInput contract). Overall, the code is exceptionally clear and maintainable.
Run 2
The code is highly readable. It has a clear, logical structure: package declaration, imports, annotations, then an interface extending DataInput with overridden methods. Nesting is flat—there are no nested blocks or conditionals. Intent is unambiguous: it defines a byte-array-compatible DataInput. Code length is appropriate, with each method declared on adjacent lines without unnecessary verbosity. Action granularity is good—annotations and method declarations are mostly on separate lines, which aids scanning. Reading flow is natural, following the method order of DataInput. Minor deductions: excessive blank lines after imports, and repeated `@CanIgnoreReturnValue` annotations add slight visual noise but remain conventional for this API.
Run 3
This code is highly readable. It is an interface declaration with a clean, flat structure—no nesting or branching logic. Each method is declared on one line, with consistent annotations (@CanIgnoreReturnValue, @Override) that aid clarity. The class-level annotations and imports are organized at the top. The extensive blank lines before the interface are harmless but slightly unnecessary. The method names and signatures clearly follow the DataInput contract, making intent obvious. The code is concise and well-structured, with no superfluous logic or fragmentation. Minor dedentation of some annotations is a trivial style issue.
Run 1
Code Structure: A logically organized interface with consistent method declarations and annotations. Nesting: Flat, with no nested control flow. Clarity of intent: The interface name, DataInput inheritance, and conventional method names clearly communicate its purpose, although documentation would help explain why methods are redeclared without checked exceptions. Code length: Appropriately concise for the API, but excessive blank lines and an unused IOException import add clutter. Action granularity: Each method declaration occupies its own line; annotations are generally separated cleanly. Reading flow: Methods follow a natural sequence from bulk reads to primitive and string reads, though inconsistent whitespace and the inline Nullable annotation slightly disrupt visual consistency.
Run 2
Code Structure: The package, imports, annotations, and interface methods follow a conventional, logical organization. Nesting: The interface is flat, with no nested control flow. Clarity of intent: Standard DataInput method names clearly communicate operations, although documentation would clarify why they are redeclared without checked exceptions. Code length: Declarations are concise, but excessive blank lines, repeated annotations, and an unused IOException import add clutter. Action granularity: Each method declaration and annotation occupies its own line, making individual elements easy to identify. Reading flow: Consistent method formatting and familiar ordering support scanning, but irregular whitespace interrupts the flow.
Run 3
Code Structure: Imports, interface annotations, and method declarations are logically organized and consistent. Nesting: The interface is flat, with no nested control flow. Clarity of intent: Familiar DataInput method names clearly communicate operations, but documentation would clarify why methods are redeclared without checked exceptions. Code length: Declarations are concise, although excessive blank lines and the unused IOException import add clutter. Action granularity: Each method declaration and annotation occupies a separate line, making individual elements easy to scan. Reading flow: Consistent formatting and related method grouping support natural reading, but large whitespace gaps and trailing spaces interrupt the presentation.