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> a();
Set<N> b();
Set<N> c();
Set<E> d();
Set<E> e();
Set<E> f();
/**
* 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> g(N a);
/**
* 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 h(E b);
/**
* 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 i(E c, boolean d);
/** Remove {@code edge} from the set of outgoing edges. Returns the former successor node. */
@CanIgnoreReturnValue
N j(E e);
/**
* Add {@code edge} to the set of incoming edges. Implicitly adds {@code node} as a predecessor.
*/
void k(E f, N g, boolean h);
/** Add {@code edge} to the set of outgoing edges. Implicitly adds {@code node} as a successor. */
void l(E i, N j);
}
Run 1
The code is technically valid Java but extremely unreadable due to obfuscated naming. Methods have single-letter names (a, b, c, ..., l) and parameters are equally meaningless (N a, E b, boolean d, etc.). This obscures the intent of every method despite the Javadoc. The structure and nesting are fine, and the code is concise, but clarity of intent, action granularity, and reading flow are severely compromised. A reader cannot understand what the code does without constantly referring to documentation or hunting for the implementations. This is the opposite of self-documenting code and would be nearly impossible to maintain or review in a real codebase.
Run 2
The code is extremely difficult to read because all method names are meaningless single letters (a, b, c, g, h, i, j, k, l) and parameters are equally opaque. While the Javadoc comments describe some methods, many core methods lack any explanation at all. The structure is logical and formatting is clean, with flat nesting and one action per line, but clarity of intent is severely compromised. Reading flow is unnatural since readers must constantly cross-reference comments to understand purpose. The code violates fundamental readability principles by prioritizing brevity over descriptiveness. Even with comments, internal calls to these methods would be incomprehensible. This appears to be deliberately obfuscated code.
Run 3
The code structure is severely undermined by meaningless method and parameter names like a(), b(), c(), g(N a), h(E b), etc. This makes it impossible for a reader to understand the intent without referring to external documentation or the original source. The nesting is flat and each method performs one action, which is good, but the clarity of intent is extremely poor. Reading flow is disjointed because the semantics of each method are unclear. While the code is concise and not deeply nested, the cryptic naming overwhelms any structural benefits, making this effectively unreadable as presented.
Run 1
Code Structure: The interface is logically organized, separating node/edge queries from connection mutations. Nesting: There is no nested control flow, making the layout easy to scan. Clarity of intent: Single-letter method and parameter names severely obscure purpose, especially for the six undocumented query methods. Existing documentation helps explain later methods, but its descriptive parameter references do not match the actual names. Code length: The interface is concise, with little unnecessary content. Action granularity: Each declaration occupies its own line or small documentation block; there are no compound actions. Reading flow: Consistent formatting and query-before-mutation ordering support natural reading, but readers must repeatedly consult comments to infer operations. Overall, clean structure is undermined by opaque naming.
Run 2
Code Structure: Clean interface organization with consistent signatures and annotations. Nesting: Completely flat, making the declarations easy to scan. Clarity of intent: The interface documentation establishes its purpose, but single-letter method and parameter names severely obscure individual operations. Methods a–f have no explanatory documentation, and later comments reference descriptive parameter names that do not match the declarations. Code length: Concise, with useful documentation rather than unnecessary implementation detail. Action granularity: Each declaration occupies its own line, with no combined actions. Reading flow: Consistent spacing and sequential declarations support scanning, but opaque naming prevents readers from understanding relationships between operations without additional context.
Run 3
Code Structure: Well-organized interface with imports, documentation, and consistently formatted method declarations. Nesting: Entirely flat, making the structure easy to scan. Clarity of intent: Severely weakened by single-letter method and parameter names; the first six methods have no explanatory documentation, and later comments reference descriptive parameter names absent from the signatures. Code length: Concise, with useful documentation rather than unnecessary implementation detail. Action granularity: Each declaration occupies its own line or small annotation block, with no combined actions. Reading flow: Visually natural and consistent, but understanding the API requires repeatedly consulting comments and inferring distinctions between similarly typed methods.