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 read(byte[] b);
@Override
void read(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 skip(int n);
@CanIgnoreReturnValue // to skip a byte
@Override
boolean read2();
@CanIgnoreReturnValue // to skip a byte
@Override
byte read3();
@CanIgnoreReturnValue // to skip a byte
@Override
int read4();
@CanIgnoreReturnValue // to skip some bytes
@Override
short read5();
@CanIgnoreReturnValue // to skip some bytes
@Override
int read6();
@CanIgnoreReturnValue // to skip some bytes
@Override
char read7();
@CanIgnoreReturnValue // to skip some bytes
@Override
int read8();
@CanIgnoreReturnValue // to skip some bytes
@Override
long read9();
@CanIgnoreReturnValue // to skip some bytes
@Override
float read10();
@CanIgnoreReturnValue // to skip some bytes
@Override
double read11();
@CanIgnoreReturnValue // to skip a line
@Override
@Nullable String read12();
@CanIgnoreReturnValue // to skip a field
@Override
String read13();
}
Run 1
The code is an interface extending DataInput with clear intent, but it is severely unreadable due to obfuscated method names like read2() through read13(). These names completely obscure the actual methods they are intended to override (e.g., readBoolean, readByte, readInt, readUTF, etc.). The comments like 'to skip a byte' do not clarify what the method actually reads; they only indicate a use case for ignoring the return value. This makes the code ambiguous and the reading flow disorganized. The structure is flat and concise, which slightly helps, but the lack of meaningful method identifiers breaks clarity of intent and action granularity. Overall, the code is technically valid but practically unreadable for anyone trying to understand or maintain the API.
Run 2
The code structure is logical but the method names (read2 through read13) severely undermine clarity of intent. They appear to be artificially renamed versions of standard DataInput methods (readBoolean, readByte, etc.), making the interface ambiguous and misleading. Nesting is flat and code length is concise, but the naming convention forces readers to cross-reference or guess what each method actually reads. Action granularity and reading flow are adequate, with one method per line and consistent annotations. However, the comments repeatedly state 'to skip a byte/some bytes' without clarifying what data type is being read, further obscuring the purpose. The Javadoc is helpful but the core API design is cryptic. While formatting and structure are clean, the severe naming ambiguity significantly reduces readability.
Run 3
The code suffers from severe readability issues primarily due to the nonsensical method names `read2()` through `read13()`, which obscure intent and violate standard naming conventions. The original DataInput methods (e.g., readBoolean, readByte, readChar) are replaced with meaningless numeric suffixes, making the code ambiguous and unreadable. The Javadoc and annotations are clear, but the method-level comments are repetitive and do not compensate for the poor naming. The structure is flat and concise, with one action per line, but the clarity of intent is critically undermined. The code is technically organized, but the naming choices destroy readability.
Run 1
Code Structure: The interface is logically organized, with imports, documentation, and consistently formatted declarations. Nesting: There is no nested control flow, making scanning easy. Clarity of intent: Class documentation explains the purpose and exception behavior, but numbered names such as read2 through read13 obscure what each method reads. The claimed overrides also do not match DataInput method names, confusing the inheritance contract. Code length: Reasonably concise for an interface; repeated annotations and comments add some visual bulk but convey useful information. Action granularity: Each method declaration occupies its own line, and annotations are clearly separated. Reading flow: Consistent spacing and ordering support smooth reading, but readers must infer semantics from return types because the method names are uninformative.
Run 2
Code Structure: The interface is logically organized, with consistent annotations and separated method declarations. Nesting: Flat structure makes scanning easy. Clarity of intent: The class documentation clearly explains its purpose and exception behavior, but names such as read2 through read13 conceal what each method reads. Several declarations also do not match DataInput methods despite @Override, creating confusion about the intended contract. Code length: Reasonably concise, although repeated annotations and generic skipping comments add visual noise. Action granularity: Each declaration occupies its own line, with annotations clearly associated with methods. Reading flow: Formatting and sequential declarations provide a predictable flow, but readers must infer method semantics from return types and numbered names, substantially reducing readability.
Run 3
Code Structure: The interface is logically organized, with imports, class documentation, and consistently formatted method declarations. Nesting: There is no deep nesting, making the layout easy to scan. Clarity of intent: The interface documentation clearly explains its purpose and exception behavior, but numbered names such as read2 through read13 obscure what each method reads. These names also conflict with the apparent intent of overriding DataInput methods. Code length: The code is reasonably concise; repeated annotations and comments add some visual bulk but communicate usage expectations. Action granularity: Each declaration occupies its own line, with annotations clearly separated. Reading flow: Consistent spacing and sequential declarations support scanning, but readers must infer method semantics from return types and vague comments rather than descriptive names.