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 class IncidentEdgeSet<N> extends AbstractSet<EndpointPair<N>> {
final N node;
final ArchetypeGraph<N> graph;
final EdgeType edgeType;
enum EdgeType {
INCOMING,
OUTGOING,
BOTH
}
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()) {
return predecessorsOrEmpty(node).size()
+ successorsOrEmpty(node).size()
- (edgeType == EdgeType.BOTH && predecessorsOrEmpty(node).contains(node) ? 1 : 0);
} 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));
}
}
private Set<N> predecessorsOrEmpty(N node) {
if (edgeType == EdgeType.INCOMING || edgeType == EdgeType.BOTH) {
return graph.predecessors(node);
} else {
return ImmutableSet.of();
}
}
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 well-structured and readable. It has a clear class hierarchy, logical method organization, and good naming conventions. The nesting is minimal (max 2-3 levels), and action granularity is mostly one operation per line. The intent is clear through method names like predecessorsOrEmpty and successorsOrEmpty, which handle edge type filtering elegantly. The size() calculation is slightly complex but well-commented with the ternary operator. Minor readability improvements could include extracting the self-loop counting logic into a helper method and adding Javadoc for the private helper methods. The contains() method handles both directed and undirected cases cleanly with early returns. Overall, the code demonstrates good practices with immutable returns, type checking, and clear separation of concerns.
Run 2
The code is well-structured with clear separation of concerns, using a base class and enums to model edge types. Methods are short, focused, and mostly flat. Naming is clear and intent is easy to follow. Some minor weaknesses: the size() and contains() methods contain moderately complex boolean logic and conditional expressions, which slightly reduce readability. But overall the code is concise, avoids deep nesting, and follows a natural reading flow. Helper methods reduce repetition. The score reflects strong readability with minor complexity in a few methods.
Run 3
The code is generally clear and well-structured, with a sensible class hierarchy and helper methods that improve readability. Nesting is mostly flat, and the intent of methods like `contains()` and `size()` is understandable. However, the `contains()` method has some complex multi-line boolean expressions that reduce clarity. Action granularity is good overall, but the conditional arithmetic in `size()` (subtracting 1 when the node is its own predecessor) is a bit terse and would benefit from a comment or a named boolean variable. The `predecessorsOrEmpty` and `successorsOrEmpty` helper methods reduce duplication nicely. The empty comments and inconsistent spacing are minor issues. Overall, it is readable but could be improved with small refactors for the trickier logic.
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 names make edge-direction filtering understandable, but the self-loop adjustment in size() would benefit from a brief explanation. Code length: Generally concise, though repeated helper calls, redundant else blocks, and excessive blank lines add minor clutter. Action granularity: Statements mostly perform one action per line; compound return expressions are appropriately split across lines. Reading flow: Methods follow a natural progression, and helpers encapsulate direction checks well. Dense boolean expressions and the size calculation require some careful reading, slightly reducing overall readability.
Run 2
Code Structure: Fields, enum, constructor, overrides, and private helpers are logically organized with clear responsibilities. Nesting: Shallow conditionals and early returns keep complexity manageable. Clarity of intent: Descriptive names make incident-edge membership and direction filtering understandable, though the self-loop subtraction in size() would benefit from a brief explanation. Code length: Mostly concise; repeated helper calls and unnecessary else blocks add minor verbosity. Action granularity: Statements generally perform one action per line, while compound return expressions remain reasonably formatted. Reading flow: Type validation precedes graph-specific membership checks naturally, but excessive blank lines interrupt the flow. Overall, the code is readable with minor formatting and explanatory improvements needed.
Run 3
Code Structure: Well-organized class with focused methods and helpers separating edge-direction filtering. Nesting: Shallow conditionals and early validation returns keep complexity low. Clarity of intent: Descriptive names and the EdgeType enum communicate purpose, though the self-loop subtraction in size() requires interpretation. Code length: Generally concise, but repeated helper calls, explicit else branches after returns, and excessive blank lines add minor clutter. Action granularity: Statements generally perform one action per line; compound return expressions are sensibly formatted but require some mental parsing. Reading flow: Fields, enum, constructor, public methods, and private helpers follow a natural order. Inconsistent whitespace slightly interrupts otherwise smooth reading.