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 suffers from significant readability issues. The package declaration, imports, and class Javadoc are all on one physical line despite being logically separate. Several methods and enum constants are formatted with opening braces, statements, and closing braces on the same line, disrupting the visual hierarchy. The `size()` method contains a complex ternary expression that combines multiple operations on one line, violating the 'one action per line' principle. The `contains` method has long boolean expressions that are difficult to parse. While the class has a clear overall purpose and the helper methods (`predecessorsOrEmpty`, `successorsOrEmpty`) are reasonable, the inconsistent formatting obscures the logical structure. Proper indentation, line breaks, and brace placement would significantly improve readability, as the underlying logic itself is not inherently tangled.
Run 2
The code is poorly formatted and hard to read. It arranges multiple statements on one line, overuses braces on the same line, and mixes imports with class documentation, disrupting logical structure. The nesting in methods like contains() and size() is moderate but made worse by inconsistent indentation. While intent is understandable, the compressed formatting obscures method boundaries and action granularity. For example, multiple actions and declarations appear on single lines, violating the 'one action per line' principle. Long boolean expressions in contains() and size() add cognitive load. The reading flow is disorganized due to erratic line breaks and brace placement. Although the code is relatively concise, clarity severely suffers from the lack of consistent formatting and whitespace. Overall, it is functionally structured but visually tangled and hard to follow.
Run 3
The code suffers from severe formatting issues that hurt readability. Imports are compressed onto one line, and multiple class members are placed on the same line, violating standard Java conventions. The size() and contains() methods contain long, dense conditional expressions that require careful reading to understand. Nesting depth is moderate (2-3 levels), but the compressed formatting makes it feel deeper than it actually is. Action granularity is poor — multiple statements and expressions are crammed onto single lines. While the class structure itself is reasonably logical (abstract base class with edge type enum), the intent is obscured by the formatting. The helper methods predecessorsOrEmpty and successorsOrEmpty are well-named, but their implementations are compressed. Overall, this appears to be the result of an aggressive code formatter/minifier rather than hand-written code, which significantly degrades readability despite having sound underlying logic.
Run 1
Code Structure: Fields, enum, constructor, public methods, and helpers are logically organized, but compressed formatting obscures their boundaries. Nesting: Control flow is shallow, with simple conditionals and early returns. Clarity of intent: Descriptive names, enum values, and helper documentation explain the purpose; the size calculation and long containment expressions require extra attention. Code length: The implementation is reasonably concise without substantial unnecessary code. Action granularity: Several imports, declarations, assignments, and control-flow statements share lines, making individual operations harder to distinguish. Reading flow: Inconsistent line breaks, inline braces, and comments attached to preceding code repeatedly interrupt scanning. Overall, the underlying design is readable, but poor formatting significantly reduces accessibility.
Run 2
Code Structure: The class is logically divided into fields, an enum, and focused methods, but compressed formatting obscures boundaries. Nesting: Mostly shallow conditionals and early returns keep complexity manageable. Clarity of intent: Descriptive names and documentation explain incident-edge behavior, although compound membership checks and self-loop counting require careful reading. Code length: The implementation is reasonably concise without substantial unnecessary code. Action granularity: Several lines combine imports, declarations, assignments, or control-flow transitions, making individual actions harder to distinguish. Reading flow: Inconsistent indentation, inline braces, long expressions, and comments attached to preceding code interrupt otherwise logical progression. Overall, the underlying design is readable, but presentation significantly reduces scanability.
Run 3
Code Structure: Fields, an edge-type enum, overrides, and helper methods provide logical organization, but cramped formatting obscures boundaries. Nesting: Conditional nesting is shallow, and early returns simplify contains(). Clarity of intent: Descriptive names and helper documentation explain edge handling; the size calculation and self-loop adjustment require closer inspection. Code length: The implementation is reasonably concise without major unnecessary code. Action granularity: Several imports, declarations, assignments, and control-flow statements share lines, making individual actions harder to distinguish. Reading flow: Inconsistent line breaks, inline braces, and long Boolean expressions interrupt scanning, although method order and helper extraction retain a coherent overall flow.