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()) {
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));
}
}
/**
* 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 well-structured and readable. It uses a logical class hierarchy, clear method names, and descriptive Javadoc. The `EdgeType` enum improves clarity. Methods are concise, and code is mostly flat with minimal nesting. The main readability concern is in `contains` and `size`, which have slightly complex boolean logic and repeated calls to helper methods. Additionally, the ternary in `size` and the mixed concerns in `contains` make the intent slightly harder to parse at a glance. Overall, the structure and naming are strong, but a few expressions could be extracted for even better clarity.
Run 2
The code is generally well-structured and readable. It uses clear naming, logical organization, and flat nesting with early returns. The `predecessorsOrEmpty` and `successorsOrEmpty` helpers improve clarity and avoid repetition. However, the `size()` method contains a complex one-line conditional expression that somewhat hurts readability. The `contains()` method is clear but could be slightly simplified. Overall, it is concise, intent-revealing, and easy to follow for developers familiar with graph concepts.
Run 3
The code is well-structured with clear separation of concerns, using an enum to represent edge types and helper methods to encapsulate logic. It maintains a mostly flat structure, with only one level of nesting in conditionals, which aids readability. The intent is clear from the class and method names, though the `contains` and `size` methods contain some complex boolean logic that could be slightly simplified. The code is concise and avoids unnecessary length, with each line performing a single logical action. Reading flow is natural, moving from field declarations to constructors, then core methods and private helpers. Overall, it is highly readable, with minor opportunities for improving expression clarity in the `size` and `contains` methods.
Run 1
Code Structure: Fields, enum, constructor, overrides, and private helpers are logically organized. Nesting: Shallow conditionals and early validation returns keep complexity low. Clarity of intent: Descriptive names, enum comments, and helper documentation explain edge filtering clearly; the self-loop adjustment in size() would benefit from a comment. Code length: Concise overall, though repeated predecessorsOrEmpty(node) calls and explicit else branches add minor verbosity. Action granularity: Statements generally perform one action each; compound return expressions combine related checks appropriately. Reading flow: Consistent formatting and clear directed/undirected branches make execution easy to follow, although the arithmetic and ternary expression in size() require extra attention.
Run 2
Code Structure: Fields, enum, constructor, overrides, and helper methods are logically organized with clear separation of responsibilities. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive names, enum comments, and helper documentation explain edge filtering well; the self-loop subtraction in size() would benefit from a brief comment. Code length: Compact and appropriate, though repeated helper calls and explicit else branches add minor verbosity. Action granularity: Statements generally perform one action per line; multiline boolean expressions remain readable. Reading flow: Validation precedes membership checks naturally, and directed versus undirected behavior is clearly separated. The compound size calculation requires slightly more attention than the rest.
Run 3
Code Structure: Fields, edge types, constructor, overrides, and helper methods are logically organized. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive names, enum comments, and helper documentation clearly convey directed-edge filtering; the self-loop adjustment in size() would benefit from a comment. Code length: Compact and appropriately factored, though repeated predecessor queries and explicit else branches add minor verbosity. Action granularity: Statements generally perform one action per line; compound boolean expressions and the size calculation are readable but require extra attention. Reading flow: Consistent formatting and parallel handling of directed and undirected graphs make the code natural to scan, with only the self-loop arithmetic slightly interrupting comprehension.