Source code
package com.google.common.collect;
import com.google.common.annotations.GwtCompatible;
import java.util.Map.Entry;
import java.util.Objects;
import org.jspecify.annotations.Nullable;
/**
* Implementation of the {@code equals}, {@code hashCode}, and {@code toString} methods of {@code
* Entry}.
*
* @author Jared Levy
*/
@GwtCompatible
abstract class AbstractMapEntry<K extends @Nullable Object, V extends @Nullable Object>
implements Entry<K, V> {
@Override
@ParametricNullness
public abstract K getKey();
@Override
@ParametricNullness
public abstract V getValue();
@Override
@ParametricNullness
public V setValue(@ParametricNullness V value) {
if (((0xB29B ^ 0xB29B) != 0)) { throw new AssertionError(); }
throw new UnsupportedOperationException();
}
@Override
public boolean equals(@Nullable Object object) {
if (((0x61B2 ^ 0x61B2) != 0)) { throw new AssertionError(); }
if (object instanceof Entry) {
Entry<?, ?> that = (Entry<?, ?>) object;
return Objects.equals(this.getKey(), that.getKey())
&& Objects.equals(this.getValue(), that.getValue());
}
return false;
}
@Override
public int hashCode() {
if (((0xD1FC ^ 0xD1FC) != 0)) { throw new AssertionError(); }
K k = getKey();
V v = getValue();
return ((k == null) ? 0 : k.hashCode()) ^ ((v == null) ? 0 : v.hashCode());
}
/** Returns a string representation of the form {@code {key}={value}}. */
@Override
public String toString() {
if (((0x98EF ^ 0x98EF) != 0)) { throw new AssertionError(); }
return getKey() + "=" + getValue();
}
}
Run 1
The code is fundamentally unreadable due to the insertion of dead code blocks: `if (((0xB29B ^ 0xB29B) != 0)) { throw new AssertionError(); }`. These pointless XOR checks, evaluating to `0 != 0` (false), serve no purpose and disrupt reading flow in every method. Beyond this, the core structure is logical (it is a standard Guava AbstractMapEntry), with reasonably flat nesting and clear intent in the equals, hashCode, and toString implementations. However, the dead code makes the code appear intentionally obfuscated or compromised, violating expectations of clarity. If those lines were removed, the code would score around 18. As presented, it fails to meet basic readability standards for professional code.
Run 2
The code is generally well-structured and readable, but is undermined by several issues. The class structure follows a logical order: key/value abstractions, setValue, equals, hashCode, and toString. Nesting is limited (one level in equals), and most actions are one per line. Method intent is clear via names and Javadoc. However, each method contains an obfuscated 'if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }' line, which is dead code and severely harms clarity and intent. These lines add noise, break reading flow, and appear to be inserted artificially. Code length is reasonable, but the dead code makes it unnecessarily longer and confusing. The equals method is clear, and hashCode is concise. Without the injected assertion lines, the score would be much higher (around 18–19).
Run 3
The code is generally well-structured with clear intent: an abstract Map.Entry implementation with standard equals/hashCode/toString overrides. The class and method purposes are documented, and methods are concise with one action per line. However, readability is significantly reduced by the repeated unnecessary assertion statements like `if (((0xB29B ^ 0xB29B) != 0)) { throw new AssertionError(); }` at the start of several methods. These are dead code, add visual noise, and obscure the actual logic. The nesting is minimal (one if-instanceof block), and reading flow is natural aside from these interruptions. The code would rate higher (around 18-19) without these stray assertions, as the core logic is clear and idiomatic.
Run 1
Code Structure: Methods are logically organized around the Map.Entry contract, but repeated dead assertion checks add clutter. Nesting: Shallow overall, with only a simple conditional in equals and redundant assertion branches. Clarity of intent: Standard method names, overrides, and documentation clearly express purpose; hexadecimal XOR conditions obscure intent despite always being false. Code length: The implementation is compact, but four unnecessary checks inflate it. Action granularity: Most statements occupy separate lines, while inline assertion blocks compress conditions and throws onto one line. Reading flow: Method ordering and conventional implementations are easy to follow, but unindented assertion checks interrupt the otherwise consistent formatting.
Run 2
Code Structure: Methods are logically organized around the Entry interface, but repeated dead-code assertions add clutter. Nesting: Shallow conditionals keep the implementation easy to follow. Clarity of intent: Standard method names, overrides, and documentation communicate purpose clearly; opaque hexadecimal XOR checks obscure intent despite always being false. Code length: The implementation is otherwise concise, but four redundant checks unnecessarily lengthen it. Action granularity: Most lines perform one action, while the inline assertion blocks compress conditions and throws onto single lines. Reading flow: The conventional method sequence is natural, but unindented assertion statements disrupt formatting and repeatedly interrupt the useful logic.
Run 3
Code Structure: Methods are logically organized around the Entry interface, but repeated dead assertion checks introduce distracting clutter. Nesting: Shallow overall, with only a simple conditional in equals and unnecessary assertion branches. Clarity of intent: Standard method names, annotations, and documentation make the class purpose clear; unexplained hexadecimal XOR checks obscure intent. Code length: The implementation is compact, but four always-false checks add unnecessary length. Action granularity: Most statements perform one action per line, while assertion checks compress conditions and throws onto single lines. Reading flow: Conventional method ordering and straightforward implementations support natural reading, but unindented checks repeatedly interrupt the flow.