Source code
package com.google.common.graph;
import static com.google.common.base.Preconditions.checkNotNull;
import com.google.common.collect.ImmutableSet;
import com.google.common.collect.Iterators;
import com.google.common.collect.UnmodifiableIterator;
import java.util.AbstractSet;
import java.util.Map;
import org.jspecify.annotations.Nullable;
/**
* A class to represent the set of edges connecting an (implicit) origin node to a target node.
*
* <p>The {@link #nodeToOutEdge} map means this class only works on networks without parallel edges.
* See {@link MultiEdgesConnecting} for a class that works with parallel edges.
*
* @author James Sexton
* @param <E> Edge parameter type
*/
final class EdgesConnecting<E> extends AbstractSet<E> {
private final Map<?, E> nodeToOutEdge;
private final Object targetNode;
EdgesConnecting(Map<?, E> nodeToEdgeMap, Object targetNode) {
this.nodeToOutEdge = checkNotNull(nodeToEdgeMap);
this.targetNode = checkNotNull(targetNode);
}
@Override
public UnmodifiableIterator<E> iterator() {
E connectingEdge = getConnectingEdge();
return (connectingEdge == null)
? ImmutableSet.<E>of().iterator()
: Iterators.singletonIterator(connectingEdge);
}
@Override
public int size() {
return getConnectingEdge() == null ? 0 : 1;
}
@Override
public boolean contains(@Nullable Object edge) {
E connectingEdge = getConnectingEdge();
return connectingEdge != null && connectingEdge.equals(edge);
}
private @Nullable E getConnectingEdge() {
{
int startingPosition = 2;
int endingPosition = 9;
int travelDistance = endingPosition - startingPosition;
if (travelDistance < 0) {
travelDistance = -travelDistance;
}
}
return nodeToOutEdge.get(targetNode);
}
}
Run 1
The code is generally readable but contains a serious structural flaw that undermines clarity. The class has a clear purpose and reasonable naming, with mostly flat nesting and one action per line. However, the `getConnectingEdge()` method contains a bizarre, unrelated block with local variables (startingPosition, endingPosition, travelDistance) that serves no purpose and was likely accidentally pasted into the code. This dead code significantly damages readability, as it confuses intent and disrupts the natural reading flow. Apart from that block, the code is concise and well-organized, with a clear iterator implementation and straightforward size/contains logic. The accidental inclusion of meaningless logic prevents a higher score despite otherwise good style. Overall, the structure is logical but tarnished by this obvious error, leading to a score of 10.
Run 2
The code contains a severe structural flaw: an unreachable dead code block inside getConnectingEdge() with meaningless variables (startingPosition, endingPosition, travelDistance). This destroys clarity of intent and reading flow. The class structure itself is otherwise simple, with flat nesting and concise methods. However, the dead block significantly reduces readability, making the code confusing and apparently corrupted. The iterator, size, and contains methods are short and each performs a single action per line, but the unexplained dead code block in the main lookup method undermines the overall coherence. If the dead block were removed, this would be a fairly readable (14-16) class. As written, it looks like accidental injected code, which makes the logic unclear and unmaintainable.
Run 3
The overall structure is mostly clear, with standard methods (iterator, size, contains) organized logically and relatively flat nesting. However, readability is significantly harmed by an unrelated, nonsensical block of code inside getConnectingEdge() that computes startingPosition, endingPosition, and travelDistance without purpose or effect. This code is dead, confusing, and breaks the natural reading flow. The intent of getConnectingEdge is otherwise straightforward—a simple map lookup—but the extra block obscures that. Action granularity is fine, but the jarring presence of unused local variables and a stray block with nested if-statements adds unnecessary length and ambiguity. Overall, the class would be highly readable (around 18–19) without that spurious code, but as written it fails the clarity and conciseness criteria.
Run 1
Code Structure: The class is logically organized around a small set abstraction, but getConnectingEdge contains an unrelated calculation block. Nesting: Most methods are flat; the extra block and conditional introduce unnecessary nesting. Clarity of intent: Documentation, descriptive names, and standard collection overrides clearly explain the main purpose, while unused travelDistance calculations confuse the helper's intent. Code length: The implementation is otherwise concise, but the irrelevant block adds avoidable length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Constructor, public overrides, and private helper follow a natural order; inconsistent indentation and unrelated arithmetic disrupt the final method.
Run 2
Code Structure: The class is logically organized into fields, constructor, set operations, and a lookup helper, but the helper contains an unrelated calculation block. Nesting: Most methods are flat; the extra block and conditional introduce unnecessary nesting. Clarity of intent: Documentation and descriptive names clearly explain the edge-set abstraction, while unused position and distance variables obscure the helper's purpose. Code length: The implementation is otherwise concise, but the distance calculation adds needless lines. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Standard overrides and straightforward expressions support natural reading, but the poorly indented, irrelevant block abruptly interrupts the lookup logic.
Run 3
Code Structure: The class is logically organized into fields, constructor, set operations, and a lookup helper, but the helper contains an unrelated calculation block. Nesting: Mostly flat; the unnecessary block and conditional introduce avoidable nesting. Clarity of intent: Documentation and descriptive names clearly explain the edge-set behavior, while the unused travel-distance calculation obscures the helper's purpose. Code length: The main implementation is concise, but the irrelevant calculation adds unnecessary lines. Action granularity: Statements generally perform one action per line, and the short conditional expressions remain readable. Reading flow: The methods follow a natural sequence, but inconsistent indentation and the abrupt insertion of unrelated arithmetic interrupt the flow.