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();
}
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 and well-structured. The package declaration and imports are organized, and the Javadoc clearly explains the interface's purpose and its contract deviation regarding IOException. The interface extends DataInput logically, and each method is declared on a single line with consistent @Override annotation. The nesting is minimal—only one method parameter list per line. The @CanIgnoreReturnValue annotations with brief comments clarify why the return value might be ignored, enhancing intent. The reading flow follows the natural order of DataInput methods. Overall, the code is concise, clear, and adheres to clean code principles with virtually no ambiguity.
Run 3
The code is highly readable. It has a clear, logical structure with a descriptive Javadoc explaining purpose and behavior. Nesting is minimal (single interface declaration). Intent is unambiguous—an in-memory DataInput that does not throw IOException. Length is appropriate: each method is a one-line override, avoiding unnecessary verbosity. Action granularity is excellent—each method and annotation is on its own line, improving scanability. Reading flow is natural, with grouping by logical categories (bulk reads, skipping, primitive reads). Minor deduction for slight repetition in '@CanIgnoreReturnValue' comments, but those comments actually enhance clarity of intent. Overall, an exemplary clean interface definition.
Run 1
Code Structure: A clean interface with logically ordered methods matching DataInput. Nesting: Flat declarations with no nested control flow. Clarity of intent: Descriptive method names and thorough class documentation clearly explain the purpose and exception behavior; annotations clarify return-value handling and nullability. Code length: Appropriate for the API, though repeated annotations and comments add minor verbosity. Action granularity: Each method declaration occupies its own line, with annotations clearly separated. Reading flow: Consistent formatting and spacing make scanning straightforward; the missing blank line after the package declaration is a minor stylistic weakness.
Run 2
Code Structure: The interface is logically organized, grouping related read operations in a consistent declaration format. Nesting: It is flat, with no nested control flow. Clarity of intent: The interface name, standard DataInput method names, and detailed documentation clearly explain its purpose and exception behavior; abbreviated parameters are a minor weakness. Code length: It is concise for the API exposed, with necessary repetition of declarations and annotations. Action granularity: Each method declaration occupies its own line, with annotations clearly separated. Reading flow: Consistent spacing and predictable method ordering make scanning easy. Minor drawbacks include repetitive annotation comments and the lack of spacing between the package and import sections.
Run 3
Code Structure: A clearly organized interface with related methods presented consistently. Nesting: Entirely flat apart from the interface scope. Clarity of intent: The class documentation explains its purpose and exception behavior; familiar DataInput method names and annotations clarify usage. Short parameter names are slightly less descriptive. Code length: Concise for a complete interface, although repeated annotations and comments add minor visual overhead. Action granularity: Each method declaration occupies its own line, with annotations separated cleanly. Reading flow: Predictable ordering, consistent spacing, and useful comments make scanning easy; missing separation between the package declaration and imports is a minor formatting weakness.