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 a();
@Override
@ParametricNullness
public abstract V b();
@Override
@ParametricNullness
public V c(@ParametricNullness V a) {
throw new UnsupportedOperationException();
}
@Override
public boolean d(@Nullable Object b) {
if (b instanceof Entry) {
Entry<?, ?> c = (Entry<?, ?>) b;
return Objects.equals(this.a(), c.getKey())
&& Objects.equals(this.b(), c.getValue());
}
return false;
}
@Override
public int e() {
K d = a();
V e = b();
return ((d == null) ? 0 : d.hashCode()) ^ ((e == null) ? 0 : e.hashCode());
}
/** Returns a string representation of the form {@code {key}={value}}. */
@Override
public String f() {
return a() + "=" + b();
}
}
Run 1
The code is heavily obfuscated with meaningless single-letter method names (a, b, c, d, e, f) that replace standard methods like getKey, getValue, setValue, equals, hashCode, and toString. This destroys clarity of intent and reading flow. The structure is logical but hidden behind cryptic names. Nesting is shallow, code length is concise, and action granularity is reasonable, but these positives are negated by the opaque naming. The generic wildcard cast and null checks are standard but the names make even simple logic hard to follow. Overall, the code requires constant mental mapping from single letters to methods, making it unreadable despite clean formatting.
Run 2
The code structure is mostly logical with clear method separation, but the intentional obfuscation of method names (a(), b(), c(), d(), e(), f()) severely hurts readability. The original entry methods like getKey(), getValue(), setValue(), equals(), hashCode(), and toString() have been replaced with meaningless single-letter names, making the code ambiguous and hard to follow. Nesting is shallow, which is good, and the logic is concise with one action per line. The reading flow is natural in terms of order, but the abstract method names break the mental mapping to standard Map.Entry semantics. The Javadoc comment explains the purpose, but it cannot compensate for the lost method name clarity. The code would be much more readable if the standard method names were preserved.
Run 3
The code structure is logical but heavily obfuscated. Method names like a(), b(), c(), d(), e(), and f() give no indication of their purpose, making the intent completely unclear. While nesting is minimal and reading flow is reasonable, the code requires external knowledge to understand what methods do. The equals/hashCode/toString implementations are concise and follow good practices, but the single-letter naming destroys clarity. Action granularity is generally good, but the ternary operations could be clearer. The code appears to be deliberately obfuscated, perhaps as a test or demonstration, but in its current form it would be unmaintainable. Real code should use descriptive names like getKey(), getValue(), setValue(), equals(), hashCode(), and toString(). Without the class-level documentation, this code would be nearly impossible to decipher.
Run 1
Code Structure: Methods are logically separated, with consistent formatting and annotations. Nesting: Only one shallow conditional; control flow is easy to follow. Clarity of intent: Single-letter method and variable names obscure their roles. The documentation suggests standard Entry operations, but the renamed methods do not match Entry or Object methods despite @Override annotations, creating confusion. Code length: Compact, without unnecessary repetition. Action granularity: Statements generally perform one action per line; compound equality and hash calculations remain manageable. Reading flow: The apparent accessor, mutation, equality, hash, and string-method sequence is natural, but readers must repeatedly infer meanings from implementation rather than names.
Run 2
Code Structure: Logically organized into short methods with consistent formatting and annotations. Nesting: Minimal; only one conditional block. Clarity of intent: Severely weakened by single-letter method and variable names, which obscure key/value access and equality, hashing, and string conversion. The documentation helps, but the renamed methods do not match the Entry interface or the documented Object overrides, making the @Override annotations misleading and the code invalid as shown. Code length: Concise without unnecessary repetition. Action granularity: Generally one action per line; the combined hash expression is compact but readable. Reading flow: Method ordering is natural, but readers must repeatedly infer what a(), b(), and other identifiers represent.
Run 3
Code Structure: Logically organized into small methods within a single abstraction. Nesting: Very shallow, with only one conditional block. Clarity of intent: Severely weakened by single-letter method and variable names; readers must infer key/value access, equality, hashing, and string conversion from implementations. The @Override annotations conflict with these renamed methods under the standard Entry interface, further confusing intent. Code length: Concise, without unnecessary implementation detail. Action granularity: Generally one declaration, return, or throw per statement; compound expressions remain manageable. Reading flow: Method ordering and documentation provide a natural progression, but ambiguous identifiers repeatedly interrupt comprehension.