Sample

int-bab354f321ed-I02

Shorten method, parameter, and local names without collisions

Matched original source

Lines80

Scores

MethodScoreScale
Posnett0.9950–1; higher is more readable
Scalabrino0.80–1; higher is more readable
Dorn0.660–1; higher is more readable
Mi0.2320–1; higher is more readable
LLOC5Logical lines; fewer is more readable
DeepSeek V4 Pro120–20; mean of three runs
GPT-6.1 Sol160–20; mean of three runs
BTTF0.550–1; higher is more readable

Views

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> get(@ParametricNullness K key); /** * {@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> remove(@Nullable Object key); /** * {@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> replace(@ParametricNullness K key, Iterable<? extends V> val); /** * {@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>> as(); /** * 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 equ(@Nullable Object obj); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Source linesThe number of non-empty source lines.80+32
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.859.051−28.349
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.4.838−7.257

Intercept 8.87 + feature contributions = 5.264 (log-odds).
Score = sigmoid(5.264) = 0.995.

Score0.8

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.79−1.761
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.93.827+0.709
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.79.752+0.705
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.028+0.673
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.99.988−0.57
Indentation frequencyHow rapidly indentation changes from line to line.34+0.439
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 0.663 (log-odds).
Score = sigmoid(0.663) = 0.66.

Score0.232
Score5
Run 1

The code is generally well-structured with clear Javadoc comments and logical organization, typical of Guava library interfaces. However, there are several readability issues that lower the score. The method names appear intentionally altered or obfuscated (e.g., 'remove' instead of 'removeAll', 'replace' instead of 'replaceValues', 'as' instead of 'asMap', 'equ' instead of 'equals'), which significantly hurts clarity of intent - these don't match standard Java collection naming conventions and would confuse readers. The nesting is flat which is good for an interface, and each action is on a single line. The Javadoc is thorough and helpful, maintaining good reading flow. Code length is appropriate and not unnecessarily verbose. The type parameters and nullness annotations are clear. Overall, the structure is sound, but the non-standard method names create a major disconnect between what the code appears to do and what readers would expect, reducing clarity.

Run 2

The code is well-structured and readable overall. It follows standard Java interface conventions, with clear Javadoc documentation explaining the contract and behavior. The class-level documentation is thorough, and each method includes meaningful comments. Nesting is non-existent as this is an interface. The intent is clear: define a ListMultimap contract with list-valued methods. However, reduced readability comes from the method names being truncated (e.g., 'remove', 'replace', 'as', 'equ' instead of 'removeAll', 'replaceValues', 'asMap', 'equals'), which obscures intent and deviates from the actual Guava API. This ambiguity harms clarity and reading flow, despite the otherwise clean organization and concise length.

Run 3

The code structure is odd and inconsistent: the interface declares it extends Multimap, but several method names are truncated (e.g., 'remove' instead of 'removeAll', 'replace' instead of 'replaceValues', 'as' instead of 'asMap', 'equ' instead of 'equals'), which obscures intent and breaks contract conventions. Nesting is minimal and formatting is generally clear, but the pervasive documentation references methods that do not match the actual signatures, creating confusion. Action granularity is fine, but reading flow suffers due to mismatch between Javadoc descriptions and actual code. Some imports are unused (List, Collection) which further reduces clarity. Overall, the code appears deliberately obfuscated, making it difficult to understand and use correctly.

Run 1

Code Structure: Clean interface organization, with imports, class documentation, and consistently formatted method declarations. Nesting: Essentially flat, with no nested control flow. Clarity of intent: Documentation clearly explains ordering, duplicates, and return types, but abbreviated names such as as() and equ() obscure purpose. References to removeAll, replaceValues, and asMap conflict with the declared remove, replace, and as methods, creating confusion. Code length: Declarations are concise, although identical documentation repeated across three methods adds unnecessary length. Action granularity: Each method declaration occupies its own line, and annotations are separated clearly; there are no compound actions. Reading flow: Consistent spacing and documentation placement make scanning straightforward, but naming and documentation inconsistencies interrupt otherwise natural reading.

Run 2

Code Structure: The interface is logically organized, with imports, type documentation, and individually documented methods. Nesting: Flat declarations and no nested control flow make scanning easy. Clarity of intent: The overall list-valued multimap purpose is clear, but abbreviated names such as as() and equ(), and the parameter val, obscure meaning. Documentation references removeAll, replaceValues, and asMap while declarations use remove, replace, and as, creating confusion. Code length: Declarations are concise, but repeated documentation adds avoidable length. Action granularity: Each method declaration occupies its own line, and annotations are cleanly separated. Reading flow: Consistent formatting and method-level documentation support a natural progression, though naming inconsistencies interrupt comprehension.

Run 3

Code Structure: The interface is logically organized, with imports, interface documentation, and individually documented methods. Nesting: Flat declarations with no nested control flow make scanning easy. Clarity of intent: Types and documentation clearly describe ordered, duplicate-preserving values, but abbreviated names such as as and equ obscure intent. Documentation references get, removeAll, replaceValues, and asMap, while declarations use different names, creating confusion. Code length: Declarations are concise, although repeated method documentation adds unnecessary length. Action granularity: Each method declaration stands alone, with annotations on separate lines; there are no compound actions. Reading flow: Consistent formatting and method-level documentation support natural reading, but mismatches between documented and declared names interrupt comprehension.