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 an interface with poor formatting. The main issue is that multiple method declarations are placed on the same line (e.g., 'int readUnsignedByte(); @CanIgnoreReturnValue // to skip some bytes'), severely violating reading flow, action granularity, and clarity of intent. The annotations appear misplaced and comments are interleaved in a disorganized manner. While the Javadoc at the top is helpful and the structure is mostly logical, the inconsistent placement of @CanIgnoreReturnValue annotations and comments alongside the methods creates a confusing, tangled presentation. Nesting is low (good), and the code is not overly long, but the inconsistent line breaks and disorganized comments significantly hamper readability.
Run 2
The code interface is straightforward in purpose, but its formatting severely harms readability. Several method declarations are crammed onto single lines with annotations and comments, violating the 'one action per line' and 'reading flow' criteria. For example, `int readUnsignedByte(); @CanIgnoreReturnValue // to skip some bytes` and `short readShort(); @CanIgnoreReturnValue // to skip some bytes` combine multiple distinct elements (method, annotation, comment) on one line. This inconsistent formatting disrupts natural reading flow and makes the code appear tangled. The class-level Javadoc is clear, but the overall structure is messy. Spacing and line breaks are inconsistent: some annotations sit above methods while others trail them. This leads to poor action granularity and makes the code unnecessarily difficult to scan quickly. While the interface itself is not complex, the formatting choices make it significantly less readable than it could be.
Run 3
The code is difficult to read due to poor organization and formatting. Several method declarations and annotations are placed on the same line as other methods, creating a jumbled, run-on appearance (e.g., 'int readUnsignedByte(); @CanIgnoreReturnValue // to skip some bytes'). This violates the principle of one action per line and disrupts the reading flow. Deep nesting is not an issue since it is an interface, but structural clarity is severely harmed by inconsistent grouping and placement of annotations. The intent of the interface is documented in the Javadoc, which is a positive, but the formatting of the methods obscures the actual API. While the language is concise (no unnecessary code), the visual clutter and lack of consistent formatting make it ambiguous and unreadable.
Run 1
Code Structure: The interface is logically organized, with imports, documentation, and related method declarations. Nesting: There is no nesting, making the code easy to scan. Clarity of intent: The Javadoc clearly explains the interface's purpose and exception behavior; annotations and comments clarify return-value handling. Code length: It is concise, with little unnecessary content. Action granularity: Several lines combine method declarations with annotations belonging to the next method, weakening visual separation and making annotation ownership harder to follow. Reading flow: The familiar DataInput method order supports natural reading, but inconsistent annotation placement, compressed declarations, and limited spacing interrupt the flow. Consistent formatting with each annotation and declaration on its own line would substantially improve readability.
Run 2
Code Structure: The interface logically groups related input methods, but inconsistent annotation placement weakens organization. Nesting: Completely flat method declarations make scanning easy. Clarity of intent: Familiar method names and clear interface documentation explain the purpose and exception behavior; annotations placed after preceding declarations obscure which method they apply to. Code length: Concise and appropriate for an interface, with useful documentation rather than unnecessary implementation detail. Action granularity: Some lines combine a declaration with the next method's annotation, reducing visual separation. Reading flow: The method sequence is natural, but irregular line breaks, inline annotations, and attached comments interrupt otherwise straightforward reading.
Run 3
Code Structure: The interface is logically organized around DataInput methods, but inconsistent annotation placement weakens visual organization. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: The class documentation clearly explains its purpose and exception behavior; familiar method names and skipping comments reinforce intent. Code length: The declarations are concise, and documentation is useful rather than excessive. Action granularity: Several lines combine a method declaration with annotations belonging to the next method, obscuring boundaries and annotation ownership. Reading flow: The method sequence is natural, but mixed formatting, inline annotations, and missing spacing after the package declaration interrupt scanning. Consistent annotation placement and one declaration or annotation per line would substantially improve readability.