Source code
package com.google.common.collect;
import com.google.common.annotations.GwtCompatible;
import com.google.errorprone.annotations.CanIgnoreReturnValue;
import java.util.Collection;
import java.util.List;
import java.util.Map;
import org.jspecify.annotations.Nullable;
/**
* A {@code Multimap} that can hold duplicate key-value pairs and that maintains the insertion
* ordering of values for a given key. See the {@link Multimap} documentation for information common
* to all multimaps.
*
* <p>The {@link #get}, {@link #removeAll}, and {@link #replaceValues} methods each return a {@link
* List} of values. Though the method signature doesn't say so explicitly, the map returned by
* {@link #asMap} has {@code List} values.
*
* <p>See the Guava User Guide article on <a href=
* "https://github.com/google/guava/wiki/NewCollectionTypesExplained#multimap">{@code Multimap}</a>.
*
* @author Jared Levy
* @since 2.0
*/
@GwtCompatible
public interface ListMultimap<K extends @Nullable Object, V extends @Nullable Object>
extends Multimap<K, V> {
/**
* {@inheritDoc}
*
* <p>Because the values for a given key may have duplicates and follow the insertion ordering,
* this method returns a {@link List}, instead of the {@link java.util.Collection} specified in
* the {@link Multimap} interface.
*/
@Override
List<V> a(@ParametricNullness K a);
/**
* {@inheritDoc}
*
* <p>Because the values for a given key may have duplicates and follow the insertion ordering,
* this method returns a {@link List}, instead of the {@link java.util.Collection} specified in
* the {@link Multimap} interface.
*/
@CanIgnoreReturnValue
@Override
List<V> b(@Nullable Object b);
/**
* {@inheritDoc}
*
* <p>Because the values for a given key may have duplicates and follow the insertion ordering,
* this method returns a {@link List}, instead of the {@link java.util.Collection} specified in
* the {@link Multimap} interface.
*/
@CanIgnoreReturnValue
@Override
List<V> c(@ParametricNullness K c, Iterable<? extends V> d);
/**
* {@inheritDoc}
*
* <p><b>Note:</b> The returned map's values are guaranteed to be of type {@link List}. To obtain
* this map with the more specific generic type {@code Map<K, List<V>>}, call {@link
* Multimaps#asMap(ListMultimap)} instead.
*/
@Override
Map<K, Collection<V>> d();
/**
* Compares the specified object to this multimap for equality.
*
* <p>Two {@code ListMultimap} instances are equal if, for each key, they contain the same values
* in the same order. If the value orderings disagree, the multimaps will not be considered equal.
*
* <p>An empty {@code ListMultimap} is equal to any other empty {@code Multimap}, including an
* empty {@code SetMultimap}.
*/
@Override
boolean e(@Nullable Object e);
}
Run 1
The code is heavily obfuscated, making it unreadable despite otherwise clear structure and formatting. While the class-level Javadoc is detailed and helpful, all method names (`a`, `b`, `c`, `d`, `e`) and parameter names (`a`, `b`, `c`, `d`, `e`) are meaningless single letters. This destroys clarity of intent and reading flow. The structure and nesting are flat, and action granularity is fine, but the semantic content is absent. The Javadoc refers to methods like `get`, `removeAll`, `replaceValues`, `asMap`, and `equals`, but these are not the actual identifiers used. This appears to be intentionally obfuscated source code, which makes it unsuitable for maintenance or understanding. The code length and formatting follow standard Java conventions, but the lack of descriptive naming is a fatal readability flaw.
Run 2
The code has clear structure with proper imports, Javadoc, and interface declaration, but method names are obfuscated (a, b, c, d, e) and parameter names are single letters, severely hurting clarity of intent. Though the structure is logical and nesting is flat, the reading flow is disrupted by ambiguous naming. Javadoc comments are thorough but reference methods that don't match their actual names, creating confusion. Action granularity is fine, and code length is appropriate for an interface. The obfuscation appears intentional but makes the code unreadable in practice.
Run 3
The code has severe readability problems due to obfuscation. While the structure is relatively flat and follows a logical interface pattern, the method names (a, b, c, d, e) and parameter names (a, b, c, d, e) are meaningless and make it impossible to understand intent without reading the documentation. This turns reading into a puzzle rather than clear comprehension. The Javadoc provides good context but cannot compensate for deliberately unhelpful identifiers. Formatting is consistent, but the naming destroys clarity of intent and reading flow. Multiple annotations and generics add some noise, though they are necessary. Overall, the code's structural organization is acceptable, but the opaque naming renders it effectively unreadable to any developer unfamiliar with the original source.
Run 1
Code Structure: The interface is logically organized, with consistent annotations and documentation preceding each declaration. Nesting: Flat method declarations and no control-flow nesting make scanning easy. Clarity of intent: The interface description and generic types explain the overall purpose, but single-letter method and parameter names obscure individual operations. Documentation references descriptive method names that do not match the declarations, further weakening clarity. Code length: Declarations are concise, though repeated documentation adds unnecessary length. Action granularity: Each declaration occupies its own line, with annotations clearly separated; there are no combined actions. Reading flow: Consistent formatting supports a natural top-to-bottom flow, but repetitive comments and the mismatch between documented names and actual identifiers interrupt comprehension.
Run 2
1. Code Structure: Well-organized interface with consistent annotations and documentation preceding each declaration. 2. Nesting: Flat structure with no nested control flow, making it easy to scan. 3. Clarity of intent: Descriptive interface documentation and explicit types help, but single-letter method and parameter names obscure operations. Documentation references descriptive methods that do not match the declarations, further reducing clarity. 4. Code length: Declarations are concise, but repeated documentation makes the interface unnecessarily lengthy. 5. Action granularity: Each method declaration occupies its own line, with annotations clearly separated; no statements combine multiple actions. 6. Reading flow: Consistent formatting provides a natural top-to-bottom flow, although repetitive comments and ambiguous names interrupt understanding.
Run 3
Code Structure: The interface is logically organized, with consistent imports, annotations, and documentation preceding each declaration. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: The interface-level documentation clearly explains list-valued multimap behavior, but single-letter method and parameter names obscure individual operations. References to get, removeAll, replaceValues, and asMap do not match the declared names, creating confusion; the equality method is similarly renamed. Code length: Declarations are concise, but repeated documentation adds unnecessary length. Action granularity: Each declaration occupies its own line, with annotations clearly separated; there are no compound executable statements. Reading flow: Consistent formatting and documentation provide a natural top-to-bottom flow, although ambiguous naming and mismatched documentation interrupt comprehension.