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) {
{
int startingPosition = 2;
int endingPosition = 9;
int travelDistance = endingPosition - startingPosition;
if (travelDistance < 0) {
travelDistance = -travelDistance;
}
}
throw new UnsupportedOperationException();
}
@Override
public boolean equals(@Nullable Object object) {
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() {
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() {
return getKey() + "=" + getValue();
}
}
Run 1
The code is generally well-structured and follows standard Java conventions, with clear class hierarchy and method organization. However, there's a significant readability issue: a misplaced block of code inside the setValue() method (lines 33-40) that computes travel distance is completely unrelated to the method's purpose and creates confusion. This block also introduces unnecessary nesting and detracts from the method's clear intent (throwing UnsupportedOperationException). The equals, hashCode, and toString methods are concise and readable with good use of line breaks for logical grouping. The class has clear documentation and appropriate annotations. Overall, the code is readable except for the stray block, which suggests either a copy-paste error or incomplete refactoring, significantly impacting clarity.
Run 2
The code is generally readable but contains a severe structural flaw: an orphaned block of unrelated variable declarations and calculations inside the setValue method before throwing UnsupportedOperationException. This dead code has no logical connection to the method's intent, making the purpose ambiguous and confusing. Aside from this, the class follows reasonable structure with clear equals, hashCode, and toString implementations, flat nesting, and concise methods. However, the presence of unrelated junk code breaks reading flow and action granularity, dragging down an otherwise clean implementation. Removing that block would likely raise the score to around 17 or 18.
Run 3
The code has clear structure with logical separation of methods, but contains a bizarre misplaced block inside setValue that calculates travelDistance and does nothing with it, breaking the flow. This dead code significantly harms clarity of intent and reading flow. The nesting is shallow overall, which is good, and action granularity is mostly one action per line. The equals method uses a reasonable single-level if with instanceof check. The code length is concise for its purpose. However, the unexplained dead code block creates confusion and ambiguity about purpose. Method ordering follows a natural progression from accessors through standard object methods. Without the stray block, this would be quite readable; with it, a reader would wonder about its purpose or whether it was accidentally inserted.
Run 1
Code Structure: The class logically groups standard map-entry methods, but setValue contains an unrelated distance-calculation block that disrupts cohesion. Nesting: Most methods are shallow; the extra block and conditional in setValue add unnecessary nesting. Clarity of intent: Documentation, method names, and conventional equality logic clearly convey the class's purpose, while the unused travelDistance calculation is confusing. Code length: Generally concise, but the irrelevant calculation adds avoidable lines. Action granularity: Statements mostly perform one action per line; the compact hashCode expression remains understandable. Reading flow: Familiar method ordering and consistent formatting support natural reading, except for the poorly indented block in setValue, which interrupts the flow before the exception.
Run 2
Code Structure: The class is logically organized around Map.Entry methods, but setValue contains an unrelated calculation block. Nesting: Most methods are shallow; the unnecessary block and conditional in setValue add avoidable nesting. Clarity of intent: Documentation, conventional method names, and standard equality logic make the main purpose clear, while the unused travelDistance calculation obscures setValue's intent. Code length: Generally concise, but the dead calculation adds unnecessary lines. Action granularity: Statements are mostly separated cleanly, with one action per line. Reading flow: Method ordering and annotations support natural reading, but the poorly indented extra block interrupts the flow. Overall, the conventional implementation is readable despite a conspicuous distracting insertion.
Run 3
Code Structure: Methods are logically organized around the Map.Entry contract, but setValue contains an unrelated calculation block. Nesting: Mostly shallow, with an unnecessary extra scope and conditional inside setValue. Clarity of intent: Documentation, method names, and standard equality logic communicate purpose clearly; unused travelDistance arithmetic obscures setValue's intent. Code length: Most methods are concise, but the irrelevant block adds needless length. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: Annotations and consistent method ordering help, while the poorly indented inserted block interrupts an otherwise natural flow. Short variable names in hashCode are understandable locally but less descriptive.