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 encode();
@Override
@ParametricNullness
public abstract V saveUser();
@Override
@ParametricNullness
public V sendData(@ParametricNullness V cache) {
throw new UnsupportedOperationException();
}
@Override
public boolean export(@Nullable Object client) {
if (client instanceof Entry) {
Entry<?, ?> node = (Entry<?, ?>) client;
return Objects.equals(this.encode(), node.getKey())
&& Objects.equals(this.saveUser(), node.getValue());
}
return false;
}
@Override
public int checkKey() {
K key = encode();
V map = saveUser();
return ((key == null) ? 0 : key.hashCode()) ^ ((map == null) ? 0 : map.hashCode());
}
/** Returns a string representation of the form {@code {key}={value}}. */
@Override
public String findData() {
return encode() + "=" + saveUser();
}
}
Run 1
The code has a clear, logical structure with a single class extending an interface and properly ordered methods. Nesting is minimal with only one level inside the equals method. However, the method names are confusing and misleading - 'encode', 'saveUser', 'sendData', 'export', 'checkKey', and 'findData' do not match their actual purposes (getKey, getValue, setValue, equals, hashCode, and toString respectively). This severely impacts clarity of intent and makes the code harder to understand. The code length is appropriate and concise, with one action per line in most cases, and the reading flow is natural though hindered by the opaque naming. The use of standard Java utilities like Objects.equals shows good practice, but the obfuscated method names significantly reduce overall readability.
Run 2
The structure is mostly logical with clear method separation, but the class is heavily obfuscated by misleading method names ('encode', 'saveUser', 'sendData', 'export', 'checkKey', 'findData') that do not reflect their actual roles in an Entry implementation. This severely harms clarity of intent, making it difficult to understand that these are really getKey, getValue, setValue, equals, hashCode, and toString. Nesting is acceptable at two levels in the equals method. Action granularity is mostly one action per line, and the reading flow is decent. However, the naming problem overwhelms the otherwise clean structure, reducing readability substantially.
Run 3
The code is well-structured with clear method separation and minimal nesting, making it readable. However, the method names (encode, saveUser, sendData, export, checkKey, findData) are misleading — they suggest unrelated operations rather than the standard getKey, getValue, setValue, equals, hashCode, and toString that the class actually implements. This obfuscates intent despite the class-level documentation. The overriding and annotation usage is clear, and each method performs a single focused action with good formatting. The conditional logic in export() is flat and straightforward. While the code is concise and follows consistent indentation, the non-standard naming increases cognitive load because readers must map unusual names to well-known Map.Entry semantics. Using conventional names would make the code nearly ideal.
Run 1
Code Structure: Methods are logically separated in a compact class, but their names conflict with the documented Map.Entry purpose and @Override contracts. Nesting: Minimal, with only one conditional block. Clarity of intent: Poor naming significantly obscures intent; encode, saveUser, sendData, export, checkKey, and findData appear to represent getKey, getValue, setValue, equals, hashCode, and toString. Variables such as client, node, cache, and map add confusion. Code length: Concise, with little unnecessary code. Action granularity: Most statements perform one action; the combined hash calculation is compact but slightly harder to scan. Reading flow: Method ordering and formatting are natural, but readers must mentally translate misleading identifiers to understand the implementation. The renamed methods also make several @Override annotations invalid, undermining confidence in the apparent design.
Run 2
Code Structure: Methods are logically separated within a compact class, with consistent annotations and formatting. Nesting: Only one shallow conditional appears, making control flow easy to follow. Clarity of intent: The documentation describes standard map-entry behavior, but misleading names such as encode, saveUser, export, checkKey, and findData obscure that intent. These names also conflict with the Entry interface methods implied by @Override, creating confusion. Variables such as client, node, and map further weaken semantic clarity. Code length: The implementation is concise, without unnecessary boilerplate beyond useful annotations. Action granularity: Statements generally perform one action each; the combined hash calculation is compact and conventional. Reading flow: Method ordering and formatting support a natural progression, but readers must repeatedly translate misleading names into key access, value access, equality, hashing, and string conversion.
Run 3
Code Structure: Small, logically separated methods provide a clear class layout. Nesting: Only one shallow conditional; complexity is low. Clarity of intent: The documentation indicates standard Map.Entry behavior, but misleading names such as encode, saveUser, export, checkKey, and findData obscure that purpose. These names also conflict with the claimed overrides of Entry and Object methods, making the code confusing and invalid as written. Variables such as client, node, cache, and map further weaken semantic clarity. Code length: Concise, with little unnecessary code. Action granularity: Most lines contain one declaration, operation, or return; the combined hash expression remains manageable. Reading flow: Consistent formatting and straightforward method bodies support easy scanning, but readers must repeatedly translate arbitrary names into key, value, equality, hashing, and string conversion concepts.