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 get();
@Override
@ParametricNullness
public abstract V get2();
@Override
@ParametricNullness
public V set(@ParametricNullness V val) {
throw new UnsupportedOperationException();
}
@Override
public boolean equ(@Nullable Object obj) {
if (obj instanceof Entry) {
Entry<?, ?> tha = (Entry<?, ?>) obj;
return Objects.equals(this.get(), tha.getKey())
&& Objects.equals(this.get2(), tha.getValue());
}
return false;
}
@Override
public int hash() {
K k = get();
V v = get2();
return ((k == null) ? 0 : k.hashCode()) ^ ((v == null) ? 0 : v.hashCode());
}
/** Returns a string representation of the form {@code {key}={value}}. */
@Override
public String to() {
return get() + "=" + get2();
}
}
Run 1
The code is logically organized but contains several readability issues. The class has a clear purpose and methods are separated appropriately, but method names are abbreviated inconsistently ('equ', 'hash', 'to', 'get2'), which obscures intent and deviates from standard Java conventions. The instanceof pattern with casting is slightly verbose but acceptable. Nesting is minimal, which is good. Code length is concise. Action granularity is reasonable—one operation per line for the most part. Reading flow is hampered by non-standard naming and incomplete Javadoc on some methods. The structure is flat and modular, but clarity of intent suffers significantly due to the abbreviated method names. With conventional naming (equals, hashCode, toString, getValue), the score would be 18 or higher. As written, it requires extra cognitive effort to map abbreviated names to their intended semantics, especially for readers unfamiliar with the codebase.
Run 2
The code has a clear, logical structure with a class-level Javadoc, annotated overrides, and a flat hierarchy with minimal nesting. However, it contains several naming issues that harm clarity: methods are incorrectly named 'get2', 'equ', 'hash', and 'to' instead of 'getValue', 'equals', 'hashCode', and 'toString', making the intent ambiguous. The method 'set' also lacks a Javadoc explaining the unsupported operation. Action granularity is mostly one action per line, and reading flow is natural within methods. Code length is concise but the naming mistakes undermine readability. The 'hash' method uses a ternary expression that is slightly dense but still acceptable. Overall, structure and flow are good, but naming errors and missing documentation reduce clarity significantly.
Run 3
The code shows reasonable structure with clear method separation and flat nesting, but has several readability issues. The method names 'equ', 'hash', 'to', and 'get2' are non-standard and ambiguous - they should be 'equals', 'hashCode', 'toString', and 'getValue'. The 'equ' method has unnecessary nested logic that could be flattened with early returns. Type casting is done in one line mixed with assignment. The abstract class structure is clear, and each method performs one action, but the weird naming creates confusion about intent. The code is concise but the abbreviated names damage readability despite good formatting and minimal nesting.
Run 1
Code Structure: Methods are logically grouped in a compact class, with annotations and documentation providing context. Nesting: Very shallow; only one conditional block appears. Clarity of intent: The documentation explains the intended Entry behavior, but names such as get, get2, equ, hash, to, and tha obscure meaning. These renamed methods also conflict with the Entry contract and @Override annotations, creating confusion. Code length: Concise, with little unnecessary code. Action granularity: Statements generally perform one action per line; the compound equality and hash expressions remain manageable. Reading flow: The progression from accessors to mutation, equality, hashing, and string conversion is natural, but misleading method names interrupt comprehension.
Run 2
Code Structure: Methods are logically grouped in a compact abstract class, though the renamed methods do not match Entry's interface or the documented Object overrides. Nesting: Minimal, with only one conditional block. Clarity of intent: Documentation and familiar equality/hash patterns help, but get, get2, equ, hash, and to obscure standard method meanings; tha is also unclear. Code length: Concise, with little unnecessary code. Action granularity: Generally one action per line; compound return expressions remain manageable. Reading flow: Natural progression from accessors to mutation, equality, hashing, and string conversion, but misleading @Override annotations and inconsistent naming interrupt understanding.
Run 3
Code Structure: Methods are logically grouped in a small class, with annotations and documentation consistently placed. Nesting: Only one shallow conditional keeps control flow simple. Clarity of intent: The documentation explains the intended Entry behavior, but names such as get, get2, equ, hash, to, and tha obscure meaning. These renamed methods also do not match the Entry/Object methods implied by @Override, making the contract confusing. Code length: The implementation is concise without substantial redundancy. Action granularity: Statements generally perform one action per line; the combined hash expression is compact but slightly harder to scan. Reading flow: Method ordering is natural, although ambiguous names repeatedly force readers to infer key/value roles and intended standard methods.