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 a(byte[] a);
@Override
void a(byte[] b, int c, int d);
// not guaranteed to skip n bytes so result should NOT be ignored
// use ByteStreams.skipFully or one of the read methods instead
@Override
int b(int e);
@CanIgnoreReturnValue // to skip a byte
@Override
boolean c();
@CanIgnoreReturnValue // to skip a byte
@Override
byte d();
@CanIgnoreReturnValue // to skip a byte
@Override
int e();
@CanIgnoreReturnValue // to skip some bytes
@Override
short f();
@CanIgnoreReturnValue // to skip some bytes
@Override
int g();
@CanIgnoreReturnValue // to skip some bytes
@Override
char h();
@CanIgnoreReturnValue // to skip some bytes
@Override
int i();
@CanIgnoreReturnValue // to skip some bytes
@Override
long j();
@CanIgnoreReturnValue // to skip some bytes
@Override
float k();
@CanIgnoreReturnValue // to skip some bytes
@Override
double l();
@CanIgnoreReturnValue // to skip a line
@Override
@Nullable String m();
@CanIgnoreReturnValue // to skip a field
@Override
String n();
}
Run 1
This code is effectively unreadable due to deliberate obfuscation. Method names (a, b, c, d...) completely obscure intent, making it impossible to understand what each read operation does without external documentation or guessing from return types. The structure is flat and minimal, but the loss of semantic naming destroys readability. Comments attempt to clarify some intent (e.g., 'to skip a byte'), but they are awkward workarounds for what should be explicit method names like readByte() or readInt(). The class Javadoc is clear, but the interface body fails to convey purpose. Action granularity and nesting are fine, but clarity of intent is near zero. This reads like a code-golf exercise or a minified artifact, not production code.
Run 2
The code has a clear structure as an interface, with good documentation and consistent annotations. However, readability is significantly reduced by the non-descriptive method names (`a`, `b`, `c`, etc.) which obscure intent. This appears to be obfuscated or minimized code, not original source. The flat nesting and one-action-per-line structure are positives, and the comments explaining skip behavior are helpful. But the clarity of intent suffers because readers must infer each method's purpose from return types or surrounding comments rather than meaningful names. The code length is reasonable, and reading flow is logical, but the lack of descriptive identifiers is a major penalty. Overall, the structure and formatting are readable, but the naming choices drastically lower the score.
Run 3
The code has a clear overall structure as an interface with a descriptive Javadoc, but readability is severely hurt by obfuscated method names (a, b, c, d... n) that completely hide intent. The Javadoc explains the class purpose well, and the flat structure with no nesting is good. However, the action granularity and reading flow suffer because each method requires cross-referencing the original DataInput interface to understand what it does. The comments like '// to skip a byte' provide minimal intent but feel cryptic without the method names. Concise length is a plus, but the cost is clarity. The code would be far more readable with proper method names like readFully, skipBytes, readBoolean, readByte, readUnsignedByte, readShort, readUnsignedShort, readChar, readInt, readLong, readFloat, readDouble, readLine, and readUTF. As written, the code appears as a decompiled or obfuscated artifact rather than maintainable source code.
Run 1
Code Structure: Imports, interface documentation, and method declarations are logically organized. Nesting: The interface is flat, with no nested control flow. Clarity of intent: The overview explains the purpose well, but single-letter method and parameter names obscure individual operations. The renamed methods also conflict with the apparent intent of overriding DataInput methods, making the declarations misleading. Code length: Reasonably concise for an interface, though repeated annotations and comments add visual bulk. Action granularity: Each declaration occupies its own line, with annotations clearly separated. Reading flow: Consistent spacing and formatting support scanning, but readers must infer method meanings from return types, signatures, and skip-related comments rather than descriptive names.
Run 2
Code Structure: The interface is logically organized, with imports, documentation, annotations, and consistently separated declarations. Nesting: Flat, with no nested control flow. Clarity of intent: The class documentation clearly describes its purpose, but single-letter method and parameter names obscure individual operations. The renamed methods also make the @Override annotations inconsistent with DataInput, creating confusion. Code length: Appropriately concise for an interface; repeated annotations and comments add some visual bulk but convey useful information. Action granularity: Each declaration occupies its own line, with annotations clearly associated with methods. Reading flow: Formatting and spacing support scanning, but readers must infer method meanings from return types and comments rather than descriptive names. Overall, strong layout is undermined by severely ambiguous naming.
Run 3
Code Structure: The interface is logically organized, with imports, documentation, and consistently formatted declarations. Nesting: There is no nested control flow, making it easy to scan. Clarity of intent: Class documentation explains the overall purpose, but single-letter method and parameter names obscure individual operations. These names also conflict with the expected DataInput method names despite @Override annotations, making the intended contract confusing. Code length: Reasonably concise for an interface, though repeated annotations and comments add visual bulk. Action granularity: Each declaration occupies its own line, with no bundled operations. Reading flow: Spacing and annotation placement are consistent, but readers must infer method meanings from return types, ordering, and comments rather than descriptive names.