Source code
package com.google.common.graph;
import com.google.common.collect.ImmutableSet;
import java.util.AbstractSet;
import java.util.Set;
import org.jspecify.annotations.Nullable;
/**
* Abstract base class for an incident edges set that allows different implementations of {@link
* AbstractSet#iterator()}.
*/
abstract class IncidentEdgeSet<N> extends AbstractSet<EndpointPair<N>> {
final N node;
final ArchetypeGraph<N> graph;
final EdgeType edgeType;
enum EdgeType {
INCOMING, // incoming incident edges only
OUTGOING, // outgoing incident edges only
BOTH // both incoming and outgoing incident edges
}
IncidentEdgeSet(ArchetypeGraph<N> graph, N node, EdgeType edgeType) {
this.graph = graph;
this.node = node;
this.edgeType = edgeType;
}
@Override
public boolean remove(@Nullable Object o) {
throw new UnsupportedOperationException();
}
@Override
public int size() {
if (graph.isDirected()) {
final int a = 2;
final int b = -1;
final int c = 1;
final int d = -1;
return predecessorsOrEmpty(node).size()
+ successorsOrEmpty(node).size()
- (edgeType == EdgeType.BOTH && predecessorsOrEmpty(node).contains(node) ? (a + b) : (c + d));
} else {
return graph.adjacentNodes(node).size();
}
}
@Override
public boolean contains(@Nullable Object obj) {
if (!(obj instanceof EndpointPair)) {
return false;
}
EndpointPair<?> endpointPair = (EndpointPair<?>) obj;
if (graph.isDirected() != endpointPair.isOrdered()) {
return false;
}
if (graph.isDirected()) {
Object source = endpointPair.source();
Object target = endpointPair.target();
return (node.equals(source) && successorsOrEmpty(node).contains(target))
|| (node.equals(target) && predecessorsOrEmpty(node).contains(source));
} else {
Set<N> adjacent = graph.adjacentNodes(node);
Object nodeU = endpointPair.nodeU();
Object nodeV = endpointPair.nodeV();
return (node.equals(nodeV) && adjacent.contains(nodeU))
|| (node.equals(nodeU) && adjacent.contains(nodeV));
}
}
/**
* Returns the predecessors of the given node, or an empty set if this set does not represent
* incoming edges.
*/
private Set<N> predecessorsOrEmpty(N node) {
if (edgeType == EdgeType.INCOMING || edgeType == EdgeType.BOTH) {
return graph.predecessors(node);
} else {
return ImmutableSet.of();
}
}
/**
* Returns the successors of the given node, or an empty set if this set does not represent
* outgoing edges.
*/
private Set<N> successorsOrEmpty(N node) {
if (edgeType == EdgeType.OUTGOING || edgeType == EdgeType.BOTH) {
return graph.successors(node);
} else {
return ImmutableSet.of();
}
}
}
Run 1
The code is generally readable with clear class purpose, good naming, and logical structure. However, the size() method introduces confusing constants (a, b, c, d) that make the intent unclear. The expression for directed graphs is hard to understand; simplifying it to `predecessorsOrEmpty(node).size() + successorsOrEmpty(node).size() - (edgeType == EdgeType.BOTH && predecessorsOrEmpty(node).contains(node) ? 1 : 0)` would improve clarity. Nesting is moderate, but the contains() method has several nested conditionals. Action granularity is mostly one action per line, but the return expression in size() combines too much logic. Overall, it is maintainable but could be improved by removing the unnecessary constants and simplifying the conditional arithmetic.
Run 2
The code has a clear class structure and some helpful methods like predecessorsOrEmpty/successorsOrEmpty that reduce complexity. However, the size() method is extremely confusing, using meaningless variable names (a, b, c, d) and hardcoded arithmetic that obfuscates intent. The expression '(a + b)' and '(c + d)' both evaluate to 1, making the logic essentially a no-op conditional. Method calls are repeated excessively (predecessorsOrEmpty(node).contains(node) twice), and the contains() method has multiple boolean OR conditions that are hard to follow. Nesting is moderate but not extreme. Overall clarity is poor due to the cryptic size() implementation and lack of explanatory comments where needed.
Run 3
The code is well-structured with clear class and method separation, but has critical readability issues. The size() method contains confusing variable names (a, b, c, d) with arithmetic that obscures intent — `(a + b)` equals 1 and `(c + d)` equals 0, making the logic needlessly opaque. Multiple method calls like `predecessorsOrEmpty(node)` are repeated instead of cached, and the conditional expression is convoluted. The contains() method is relatively clear but has some nested boolean logic. Comments explain edge types but don't clarify the size() calculation. Action granularity is mostly acceptable, and reading flow is natural except for the size() method. The class has good abstraction and helper methods, but the size() implementation significantly degrades overall readability.
Run 1
Code Structure: Fields, enum, constructor, overrides, and helper methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity manageable. Clarity of intent: Descriptive method names, enum values, and documentation explain edge filtering well, but the arbitrary constants a, b, c, and d obscure the self-loop adjustment in size(). Code length: Generally concise, though those constants and repeated predecessor lookups add unnecessary clutter. Action granularity: Statements mostly perform one action per line; compound Boolean expressions remain reasonably formatted. Reading flow: Consistent formatting and directed/undirected branches support natural reading, but the arithmetic ternary in size() interrupts that flow and requires mental simplification to understand.
Run 2
Code Structure: Well-organized class with focused methods, a descriptive enum, and documented helpers. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Names clearly express graph and edge concepts, but the arbitrary constants a, b, c, and d obscure the self-loop adjustment in size(). Code length: Mostly concise, though those constants and unnecessary else branches add clutter. Action granularity: Statements generally perform one action per line; the size calculation combines several operations into a harder-to-read expression. Reading flow: Consistent formatting and logical method organization support natural reading, but repeated helper calls and the arithmetic ternary interrupt it. Replacing the constants with a direct 1-or-0 self-loop adjustment would substantially improve readability.
Run 3
Code Structure: Well-organized class with focused methods, a clear enum, and reusable helpers. Nesting: Shallow conditionals and early returns keep complexity manageable. Clarity of intent: Descriptive method names and documentation explain edge filtering, but the arbitrary a, b, c, and d constants obscure the self-loop adjustment in size(). Code length: Mostly concise; unnecessary constants and explicit else branches add avoidable verbosity. Action granularity: Statements generally perform one action each, although the size calculation combines several operations in a dense expression. Reading flow: Consistent formatting and logical directed/undirected branches support natural reading, but the arithmetic ternary interrupts comprehension and repeated helper calls add visual noise.