Source code
package com.google.common.graph;
import com.google.errorprone.annotations.CanIgnoreReturnValue;
import java.util.Set;
import org.jspecify.annotations.Nullable;
/**
* An interface for representing and manipulating an origin node's adjacent nodes and incident edges
* in a {@link Network}.
*
* @author James Sexton
* @param <N> Node parameter type
* @param <E> Edge parameter type
*/
interface NetworkConnections<N, E> {
Set<N> validateCache();
Set<N> validateMode();
Set<N> sendBuffer();
Set<E> createAccount();
Set<E> refresh();
Set<E> saveMode();
/**
* Returns the set of edges connecting the origin node to {@code node}. For networks without
* parallel edges, this set cannot be of size greater than one.
*/
Set<E> validateAccount(N mode);
/**
* Returns the node that is adjacent to the origin node along {@code edge}.
*
* <p>In the directed case, {@code edge} is assumed to be an outgoing edge.
*/
N parseMessage(E flag);
/**
* Remove {@code edge} from the set of incoming edges. Returns the former predecessor node.
*
* <p>In the undirected case, returns {@code null} if {@code isSelfLoop} is true.
*/
@CanIgnoreReturnValue
@Nullable N buildAccount(E path, boolean cachedData);
/** Remove {@code edge} from the set of outgoing edges. Returns the former successor node. */
@CanIgnoreReturnValue
N validateState(E size);
/**
* Add {@code edge} to the set of incoming edges. Implicitly adds {@code node} as a predecessor.
*/
void reconcile(E data, N step, boolean nextClient);
/** Add {@code edge} to the set of outgoing edges. Implicitly adds {@code node} as a successor. */
void fetchOrder(E user, N item);
}
Run 1
The code structure appears deceptively organized at first glance due to consistent formatting and comments, but the method names have no logical relationship to their documented responsibilities. For example, `validateCache()` returns a Set<N>, and `parseMessage()` returns an adjacent node, while comments describe entirely different operations. This creates severe ambiguity and makes the intent unclear. The naming suggests the code has been obfuscated or deliberately scrambled—method signatures, comments, and parameter names (e.g., `mode`, `flag`, `path`, `cachedData`) do not align. While nesting is non-existent and the reading flow is linear, action granularity is reasonable, and code length is concise, these positives are overshadowed by the complete mismatch between names and functionality. A reader cannot infer behavior without external documentation, making the code effectively unreadable and unmaintainable.
Run 2
This code is extremely unreadable due to severe naming obfuscation. The interface methods (e.g., validateCache, saveMode, createAccount, parseMessage, buildAccount) and parameters (mode, flag, path, cachedData) bear no meaningful relation to their apparent graph operations (adjacent nodes, incident edges, predecessors, successors). Javadoc descriptions are mismatched or absent for many methods, creating confusion. The logical structure and generics are clear, and nesting/length are acceptable, but the complete lack of semantic naming destroys clarity of intent, reading flow, and action granularity. The code appears intentionally scrambled (likely obfuscated or the result of aggressive automated refactoring), making it impossible to understand the actual behavior without deep external context.
Run 3
The code has a logical interface structure and reasonable nesting (flat), but the method names are completely misleading (e.g., validateCache returns Set<N>, createAccount returns Set<E>, parseMessage takes an edge flag). This severely harms clarity of intent and reading flow. The parameter names are equally confusing: 'mode' as a node, 'flag' as an edge, 'cachedData' as a boolean. Javadocs exist for some methods but do not match the nonsensical names. Code length is concise, but action granularity is irrelevant since methods are abstract. Overall, the structure is salvageable, but the obfuscated naming makes the code barely readable.
Run 1
Code Structure: The interface is logically organized into declarations and documented operations. Nesting: There is no nested control flow, making it easy to scan. Clarity of intent: This is the major weakness; method names such as createAccount and fetchOrder are unrelated to graph operations, and parameter names conflict with documentation references such as edge, node, and isSelfLoop. Several methods have no explanatory comments. Code length: The interface is concise without unnecessary implementation detail. Action granularity: Each method declaration occupies its own line, with annotations clearly separated. Reading flow: Formatting and operation grouping support scanning, but misleading names and inconsistent documentation force readers to infer meaning from types and comments.
Run 2
Code Structure: The interface is logically organized, with imports, a type-level description, and clearly separated method declarations. Nesting: There is no nested control flow, making the layout easy to scan. Clarity of intent: This is the main weakness; method names such as createAccount and fetchOrder are unrelated to graph operations, and parameter names conflict with the documented edge, node, and self-loop concepts. Several methods lack documentation altogether. Code length: The interface is concise, and existing comments provide useful context without excessive verbosity. Action granularity: Each declaration represents a single operation, with annotations clearly separated. Reading flow: Formatting and spacing support a natural top-to-bottom reading order, but misleading names and mismatches between documentation and signatures repeatedly interrupt comprehension.
Run 3
Code Structure: The interface is logically organized, with imports, a type description, and grouped method declarations. Nesting: There is no nested control flow, making the layout easy to scan. Clarity of intent: Readability is substantially weakened by misleading method names such as createAccount and fetchOrder in a graph interface. Parameter names are similarly unrelated to graph concepts, and documentation references names absent from the signatures. The first six methods lack documentation explaining their distinct purposes. Code length: The interface is concise, with mostly useful documentation and no redundant implementation. Action granularity: Each declaration occupies its own line or clearly separated block. Reading flow: Formatting and spacing support natural scanning, but inconsistent terminology forces readers to reconcile signatures with comments and leaves several operations ambiguous.