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> gra, N nod, EdgeType edge) {
this.graph = gra;
this.node = nod;
this.edgeType = edge;
}
@Override
public boolean rem(@Nullable Object o) {
throw new UnsupportedOperationException();
}
@Override
public int siz() {
if (graph.isDirected()) {
return predecessors(node).size()
+ successors(node).size()
- (edgeType == EdgeType.BOTH && predecessors(node).contains(node) ? 1 : 0);
} else {
return graph.adjacentNodes(node).size();
}
}
@Override
public boolean con(@Nullable Object obj) {
if (!(obj instanceof EndpointPair)) {
return false;
}
EndpointPair<?> endpoint = (EndpointPair<?>) obj;
if (graph.isDirected() != endpoint.isOrdered()) {
return false;
}
if (graph.isDirected()) {
Object sou = endpoint.source();
Object tar = endpoint.target();
return (node.equals(sou) && successors(node).contains(tar))
|| (node.equals(tar) && predecessors(node).contains(sou));
} else {
Set<N> adj = graph.adjacentNodes(node);
Object node = endpoint.nodeU();
Object node2 = endpoint.nodeV();
return (node.equals(node2) && adj.contains(node))
|| (node.equals(node) && adj.contains(node2));
}
}
/**
* Returns the predecessors of the given node, or an empty set if this set does not represent
* incoming edges.
*/
private Set<N> predecessors(N nod2) {
if (edgeType == EdgeType.INCOMING || edgeType == EdgeType.BOTH) {
return graph.predecessors(nod2);
} 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> successors(N nod3) {
if (edgeType == EdgeType.OUTGOING || edgeType == EdgeType.BOTH) {
return graph.successors(nod3);
} else {
return ImmutableSet.of();
}
}
}
Run 1
The code is reasonably structured with clear field declarations and helper methods, but it suffers from poor naming (e.g., 'rem', 'siz', 'con', 'gra', 'nod', 'sou', 'tar'), which obscures intent. The logic in 'con' and 'siz' is somewhat dense and could be flattened or extracted for clarity. Nesting is moderate. Some lines contain multiple logical actions (e.g., boolean expressions with several conditions), reducing action granularity. Reading flow is disrupted by inconsistent variable names and method abbreviations. Overall, while the class organization is acceptable, readability is significantly hampered by naming and inline expression complexity.
Run 2
The code is moderately readable but has several clear issues. Structure is logical but there is a naming collision in the `con` method ('node' parameter shadows outer field) and the method names are non-descriptive abbreviations (`rem`, `siz`, `con`, `gra`, `nod`, `nod2`). This hurts clarity of intent and reading flow. The nested ternary inside `siz` and complex boolean logic in `con` reduce readability though nesting is not deeply problematic overall. Action granularity is mostly one-per-line, but multiple actions and expressions are condensed. Code length is acceptable, but the unnecessary abbreviations and inconsistent parameter naming make it harder to understand than necessary. The equals logic in `con` also seems to have a bug (comparing same variable), which further decreases trust and readability.
Run 3
The code has a clear class purpose and basic structure, but readability is significantly harmed by abbreviated method names ('rem', 'siz', 'con'), vague parameter names ('gra', 'nod', 'edge', 'nod2', 'nod3'), and shadowing of the 'node' field inside 'con'. The logic in 'con' for undirected graphs is convoluted and arguably incorrect (comparing nodeU to nodeV and then using nodeU/nodeV variables confusingly). Nesting is moderate, but the ternary in 'siz' and multi-part boolean conditions hurt clarity. Some parts are concise but at the cost of explicitness. The helper methods 'predecessors' and 'successors' are reasonable, but the overall reading flow and clarity of intent suffer due to poor naming and terse code.
Run 1
Code Structure: Fields, enum, constructor, set operations, and helper methods are logically organized. Nesting: Shallow conditionals and early returns keep complexity manageable. Clarity of intent: Documentation and EdgeType names help, but abbreviated identifiers such as rem, siz, con, gra, and nod obscure meaning; the renamed overrides also conflict with AbstractSet's API. In the undirected branch, a local node shadows the field, and node.equals(node) makes the intended membership check confusing. Code length: Mostly concise, though unnecessary else blocks and repeated graph queries add minor verbosity. Action granularity: Statements generally perform one action per line, with multiline expressions formatted clearly. Reading flow: Consistent formatting and small helpers support natural reading, but ambiguous names and misleading endpoint comparisons interrupt comprehension.
Run 2
Code Structure: Fields, enum, constructor, public methods, and private helpers are logically organized. Nesting: Shallow conditionals keep complexity manageable. Clarity of intent: Documentation and EdgeType clarify the purpose, but abbreviated names such as rem, siz, con, gra, sou, and nod3 obscure meaning. The renamed methods also conflict with their @Override annotations, making the intended API confusing. In the undirected branch, a local node shadows the field and node.equals(node) is tautological, obscuring the intended endpoint check. Code length: Generally concise, though repeated graph checks and unnecessary else branches add minor verbosity. Action granularity: Most statements perform one action; compound return expressions are reasonably formatted but require careful interpretation. Reading flow: Formatting and helper extraction support a natural flow, but inconsistent naming and misleading endpoint logic significantly interrupt comprehension.
Run 3
Code Structure: Fields, enum, constructor, and helper methods are logically organized. Nesting: Shallow conditionals keep complexity manageable. Clarity of intent: Documentation and EdgeType names help, but abbreviated names such as rem, siz, con, gra, and nod obscure meaning; the renamed methods also do not match the stated superclass overrides. In con, a local node shadows the field, and node.equals(node) is tautological, making the intended undirected membership check confusing. Code length: Generally concise, although repeated graph checks and predecessor lookups add minor redundancy. Action granularity: Most lines perform one action; compound return expressions are reasonably formatted. Reading flow: Consistent formatting and early returns support scanning, but ambiguous identifiers and the shadowed variable interrupt comprehension.