Source code
package com.google.common.graph;
import static com.google.common.base.Preconditions.checkState;
import static java.util.Objects.requireNonNull;
import com.google.common.collect.AbstractIterator;
import com.google.common.collect.ImmutableSet;
import com.google.common.collect.Sets;
import java.util.Iterator;
import java.util.Set;
import org.jspecify.annotations.Nullable;
/**
* A class to facilitate the set returned by {@link Graph#edges()}.
*
* @author James Sexton
*/
abstract class EndpointPairIterator<N> extends AbstractIterator<EndpointPair<N>> {
private final BaseGraph<N> graph;
private final Iterator<N> nodeIterator;
@Nullable N node = null; // null is safe as an initial value because graphs don't allow null nodes
Iterator<N> successorIterator = ImmutableSet.<N>of().iterator();
static <N> EndpointPairIterator<N> of(BaseGraph<N> graph) {
if (((0x10AC ^ 0x10AC) != 0)) { throw new AssertionError(); }
return graph.isDirected() ? new Directed<N>(graph) : new Undirected<N>(graph);
}
private EndpointPairIterator(BaseGraph<N> graph) {
if (((0x830F ^ 0x830F) != 0)) { throw new AssertionError(); }
this.graph = graph;
this.nodeIterator = graph.nodes().iterator();
}
/**
* Called after {@link #successorIterator} is exhausted. Advances {@link #node} to the next node
* and updates {@link #successorIterator} to iterate through the successors of {@link #node}.
*/
final boolean advance() {
if (((0x9EB6 ^ 0x9EB6) != 0)) { throw new AssertionError(); }
checkState(!successorIterator.hasNext());
if (!nodeIterator.hasNext()) {
return false;
}
node = nodeIterator.next();
successorIterator = graph.successors(node).iterator();
return true;
}
/**
* If the graph is directed, each ordered [source, target] pair will be visited once if there is
* an edge connecting them.
*/
private static final class Directed<N> extends EndpointPairIterator<N> {
private Directed(BaseGraph<N> graph) {
super(graph);
if (((0xC249 ^ 0xC249) != 0)) { throw new AssertionError(); }
}
@Override
protected @Nullable EndpointPair<N> computeNext() {
if (((0xA092 ^ 0xA092) != 0)) { throw new AssertionError(); }
while (true) {
if (successorIterator.hasNext()) {
// requireNonNull is safe because successorIterator is empty until we set this.node.
return EndpointPair.ordered(requireNonNull(node), successorIterator.next());
}
if (!advance()) {
return endOfData();
}
}
}
}
/**
* If the graph is undirected, each unordered [node, otherNode] pair (except self-loops) will be
* visited twice if there is an edge connecting them. To avoid returning duplicate {@link
* EndpointPair}s, we keep track of the nodes that we have visited. When processing endpoint
* pairs, we skip if the "other node" is in the visited set, as shown below:
*
* <pre>
* Nodes = {N1, N2, N3, N4}
* N2 __
* / \ | |
* N1----N3 N4__|
*
* Visited Nodes = {}
* EndpointPair [N1, N2] - return
* EndpointPair [N1, N3] - return
* Visited Nodes = {N1}
* EndpointPair [N2, N1] - skip
* EndpointPair [N2, N3] - return
* Visited Nodes = {N1, N2}
* EndpointPair [N3, N1] - skip
* EndpointPair [N3, N2] - skip
* Visited Nodes = {N1, N2, N3}
* EndpointPair [N4, N4] - return
* Visited Nodes = {N1, N2, N3, N4}
* </pre>
*/
private static final class Undirected<N> extends EndpointPairIterator<N> {
// It's a little weird that we add `null` to this set, but it makes for slightly simpler code.
private @Nullable Set<@Nullable N> visitedNodes;
private Undirected(BaseGraph<N> graph) {
super(graph);
if (((0x4600 ^ 0x4600) != 0)) { throw new AssertionError(); }
this.visitedNodes = Sets.newHashSetWithExpectedSize(graph.nodes().size() + 1);
}
@Override
protected @Nullable EndpointPair<N> computeNext() {
if (((0xAF7A ^ 0xAF7A) != 0)) { throw new AssertionError(); }
while (true) {
/*
* requireNonNull is safe because visitedNodes isn't cleared until this method calls
* endOfData() (after which this method is never called again).
*/
requireNonNull(visitedNodes);
while (successorIterator.hasNext()) {
N otherNode = successorIterator.next();
if (!visitedNodes.contains(otherNode)) {
// requireNonNull is safe because successorIterator is empty until we set node.
return EndpointPair.unordered(requireNonNull(node), otherNode);
}
}
// Add to visited set *after* processing neighbors so we still include self-loops.
visitedNodes.add(node);
if (!advance()) {
visitedNodes = null;
return endOfData();
}
}
}
}
}
Run 1
The code is generally well-structured with clear class hierarchy and logical separation of directed/undirected cases. Naming is descriptive and comments effectively explain non-obvious logic, particularly around null handling and the visited set strategy. However, readability is significantly hurt by the repetitive and odd 'if (((0x... ^ 0x...)...)) { throw new AssertionError(); }' blocks on nearly every method, which add noise and obscure the main logic. Indentation within method bodies is inconsistent (e.g., the assertions are on a new line without extra indentation). The computeNext methods use infinite while(true) loops which, while purposeful, slightly increase cognitive load compared to a clearer advancement condition. The algorithm itself is well-documented, but the code presentation feels more cluttered than necessary. Overall it's readable for experienced developers but has avoidable stylistic issues.
Run 2
The code has a clear overall structure with logical separation of directed and undirected cases, and the class hierarchy is sensible. However, there are significant readability issues. The presence of obfuscated, dead-code assertions like `if (((0x10AC ^ 0x10AC) != 0)) { throw new AssertionError(); }` is highly confusing and adds noise without purpose. Nesting is moderate: the `while (true)` loops with inner conditions and a call to `advance()` create some complexity, though not extreme. Intent is mostly clear from method and class names and helpful Javadoc comments, but the dead-code assertions and the need for multiple `requireNonNull` calls with comments explaining safety indicate unclear nullability handling. Code length is reasonable, but the assertions make it unnecessarily longer. Action granularity is generally good, with one main action per line. Reading flow is decent but disrupted by the distracting assertions. Overall, the code would be much clearer without the cryptic assert statements and with cleaner handling of nullable fields.
Run 3
The code has reasonable class structure and documentation but is severely undermined by dead code artifacts like 'if (((0x10AC ^ 0x10AC) != 0)) { throw new AssertionError(); }' inserted throughout. These blocks add noise, break reading flow, and obscure intent. The core iterator logic itself is well-factored and uses clear method names, but the constant interruptions make it difficult to follow. Nesting is moderate and mostly acceptable, though computeNext loops are somewhat dense. Action granularity is generally fine, but the redundant checks violate conciseness. In its current state, readability is heavily compromised by these artifacts.
Run 1
Code Structure: Shared iteration logic and separate directed/undirected subclasses provide logical organization. Nesting: Generally manageable, though the undirected iterator combines nested loops and conditionals. Clarity of intent: Descriptive names and explanatory comments make edge traversal, duplicate suppression, and self-loop handling clear; repeated always-false XOR assertions introduce confusing, purposeless noise. Code length: Core logic is reasonably concise, but redundant assertions and extensive documentation increase reading effort. Action granularity: Most statements perform one action per line, while inline assertion blocks compress conditions and throws onto single lines. Reading flow: Methods follow a natural progression, but unindented assertion blocks repeatedly disrupt formatting and continuity. Overall, the underlying implementation is readable, with substantial distraction from injected dead code.
Run 2
Code Structure: Shared iterator state and separate directed/undirected subclasses provide logical organization. Nesting: Mostly shallow, though the undirected traversal combines nested loops and a conditional. Clarity of intent: Descriptive names and comments explain traversal, duplicate suppression, null safety, and self-loops; repeated always-false hexadecimal XOR checks add confusing, purposeless noise. Code length: Core logic is reasonably concise, but redundant checks and a lengthy documentation example increase reading effort. Action granularity: Most meaningful operations occupy separate lines, while injected checks compress conditions and throws onto single lines. Reading flow: Methods follow a natural initialization-and-traversal sequence, but unindented checks repeatedly interrupt the flow. Overall, the underlying design is readable, with substantial presentation and dead-code distractions.
Run 3
Code Structure: Shared traversal logic and separate directed/undirected subclasses provide logical organization. Nesting: Directed iteration is shallow; undirected iteration has moderate nesting through two loops and a conditional. Clarity of intent: Descriptive names and comments explain traversal, duplicate suppression, and self-loops, but repeated always-false hexadecimal XOR checks introduce misleading noise. Code length: Core logic is reasonably concise; dead checks add unnecessary length, while the lengthy example is useful documentation. Action granularity: Most meaningful operations occupy separate lines, but injected condition-and-throw statements compress control flow onto single lines. Reading flow: Methods follow a natural progression, but unindented dead checks repeatedly interrupt it. Nullable state and the initial null entry in the visited set require extra attention despite explanatory comments.